How Important Are Your Transactions
A sanity check in evaluating available OSS/BSS solutions

By: Bruce Bahlmann - Contributing Author (your feedback is important to us!)

Created: June 19, 2000

The hour is late and you find yourself at a customer’s home installing a cable modem. But it’s been one of those days where everything just seems to go wrong and to top it all off you just heard over the radio that something else is down. You say to yourself, “if I could just get this cable modem registered I’d be on my way home.” Well, the vendor community has been listening and products are on their way to the marketplace to provide you with software to ensure that important transactions reach their final destination. But how can this software help speed your installations so you don’t have installers working late hours? What problems does this software solve that is worth the additional cost of this upgrade component? Lastly, what long-term benefit are you likely to see from investing in such software? This article will attempt to answer these questions and provide you with an introduction to some of the challenges of systems integration.

The MSO Need

The need to integrate various billing systems with various provisioning systems has created a challenging task for systems integration. That is to enable divergent systems to communicate with one another. MSOs face this challenge with nearly every product or service they offer. Thus MSOs seek to integrate the new service applications they want to provide with applications that support their existing services. Products that serve the purpose of systems integration fall into a category known as Operational Support Systems (OSS). OSS software products form the glue that binds a mixture of vendor products together to form a working system.

The OSS Landscape

The OSS product area is riddled with acronyms such as Application Programming Interfaces (API), Remote Procedure Calls (RPC) and strange terms such as hooks, triggers, script layers, and scripting points. These acronyms and terms represent traditional OSS practices that have become hardened through rigorous commercial and industrial use. Although these traditional OSS products are still in production behind the scenes at many MSOs, new OSS products are challenging the foothold of these long standing products. With features such as persistence and the ability to retry, new OSS products take a stab at addressing key MSO selling points regarding the importance of their transactions. However, a lesser-known fact is that these features only apply to a minority of the overall types of transactions.

As an example, take a look at the following types of transactions associated with a cable modem found in Table 1.

Table 1 Cable Modem Transactions

Each of these transactions can be associated with a priority along with a possible means of communication (see Table 2). Here the priority identifies the importance of each transaction. Transactions with a ‘HIGH’ priority typically require immediate execution while transactions with a ‘LOW’ priority can be executed at the next available opportunity. The other two columns in Table 2 represent the types of communications that can be associated with each type of transaction. Ideally, one would like ALL transactions be executed immediately. Transactions executed immediately provide instant gratification to installers & customer service representatives and eliminate confusion (either it works or it doesn’t). Thus, traditional OSS products are only designed for immediate execution. If something prevents immediate execution (such as a server or network going down) the transaction is halted and an error condition prevents the completion of the transaction. In these cases, all service modifications are down until such time as the problem (i.e. the server or network being down) is corrected.

Table 2 Transaction Breakdown

New OSS products provide the capability to retry which can benefit some transactions when something prevents immediate execution. These products boast the ability to queue service requests during outages and then execute them at the next available opportunity once the problem is resolved. However, the nature of many HIGH priority transactions prevents most (if not all) from being properly executed at the next available opportunity.

The Nemesis of Retry Technology

The single largest factor that prevents most transactions from being executed at the next available opportunity is duplication (the nemesis of retry technology). Duplication is an error that can result when a transaction must create or modify a field that is supposed to be unique. Unique fields include such things as customer ids, cable modem Ethernet addresses, customer phone numbers, etc. Adding or modifying these fields require previous checks to ensure the changes yet-to-be-made are valid (pass the uniqueness checks). Thus, any error condition that prevents uniqueness checks prior to execution will prevent those transactions that must be unique from being able to execute at the next available opportunity. In the cable modem case above, only 25% of the transactions may be successfully handled using the next available opportunity method of execution.

There are other challenges as well for retry technology. This includes race conditions where two transactions are trying add or modify the same record. For example, one person attempts to provision a new customer cable modem at the same time as another person is incorrectly provisioning another cable modem. Because the cable modem Ethernet address is long and typically hand entered it is extremely common that it is initially entered wrong. This creates problems for retry technology. Even if it was able to somehow ensure a transaction was unique, it is unlikely to accommodate a race such as two “unique” Ethernet addresses being provisioned at the same time. As a result, both transactions would confirm being accepted and processed. However, a scary result occurs when one fails. In this case, the retry technology must go back and change the state of one of the accounts to un-registered as the transaction which was previously indicated as successful has now failed. If this happened to be the account with the correctly entered Ethernet address, confusion arises as to why or how this could happen. It could also mean that the cable modem you thought you registered did not get registered after all. Correcting a race may mean a re-write of the OSS software or worse, setting different transactions in immediate execution mode.

Retry technology hardwired for immediate execution is no better than traditional OSS products. This is because the added complexity they bring to the overall system as well as the additional requirements they place on other necessary components of the system. Traditional OSS merely requires connectivity from the host application to the provisioning server. Although this seems pretty easy in theory its not in reality as there may be several different types of networking gear between the two (e.g. hubs, routers, switches, and/or firewalls). Each of these components must operate correctly in order for the system (and the OSS) to work correctly. New OSS products often add additional components to the mix (e.g. clients, server applications, additional hardware, etc.). The more components they add to the system the more complex the overall system becomes. Once more, any new additional hardware becomes even more dependent on the network to operate correctly. If this was a source of problems for the previous OSS it will also be a problem for the new OSS.

Lastly, as new OSS products claim to support interfaces to multiple provisioning services (i.e. email, DHCP, telephony, digital video, etc.) one should think about problems that can arise from this consolidation. Certainly from purely an integration standpoint, one stop shopping for a complete OSS solution looks attractive on the outside. However, consolidation is not always a good thing as a single OSS solution can cost you in other ways. Consider the following when selecting an new OSS vendor:

Single point of failure – Having a consolidated OSS means placing all your service interfaces under one roof. If that roof caves in all your services are effected. Exposure in this case could be extremely costly – especially if the cause of the cave-in requires code fixes or worse, it requires the failure condition to be repeated so the error condition can be understood. Traditional OSS products are typically NOT consolidated and as a result they are not inter-dependent and allow new services to be developed in parallel without any service interruption.

Unproven – Many new OSS vendors cannot match the track record of traditional OSS products. Thus for them to break in to this market, they need to establish a foothold with a reputable company, for example, some business that they have helped which has made a name for itself. Since historically products developed in a lab do not perform well in production this journey of going from conception to a proven product is very difficult and riddled with road kill. Thus being one of the first customers could place your business at unknown risks.

Longevity – Many of these new OSS vendors have only been around for a few years. Consider how long your existing vendors have been around. Once more, consider where you want to go with your business, where the technology is going, as well as the problems you face with your existing OSS. If the services your considering for a new OSS are in their infancy you should also consider what impact this will have on the maintenance cost of the new OSS.

Somewhere among these thoughts lies an OSS comfort level (or threshold of pain) in which your business can thrive in concert with your ability to add new technology to your system.

Summary

Check out these other Birds-Eye.Net papers/products regarding OSS/BSS:

• OSS Vendor Listing - Comprehensive listing of OSS/BSS vendors for Telecommunications
• Broadband OSS Vendor Comparison - Analysis of select broadband OSS vendors
• Reverse Auto-Provisioning - Getting your arms around viruses

Can Birds-Eye.Net help you or your Company?
Receive your Birds-Eye.Net articles and white papers hot off the presses by adding our RSS feed to your reader.

 

(C) Copyright Birds-Eye.Net, All rights reserved.
It is against the law to reproduce this content or any portion of it in any form without the explicit written permission of Birds-Eye Network Services, LLC. Federal copyright law (17 USC 504) makes it illegal, punishable with fines up to $100,000 per violation plus attorney's fees.