Speed up SONET/SDH Provisioning with an Integrated Inventory Model, Part I

An inventory model is the essential foundation for faster provisioning in SONET/SDH networks. Part II of this feature will deal with integrated inventory solution.

Provisioning services across SONET networks is no easy task. Lead times are long, and the process is expensive. This article explores one of the fundamental obstacles to improving the process, and highlights the essential aspects of a real solution.

Provisioning is the process of adding new customers and services onto the network. This sounds simple enough—network engineers do it all the time. The problem for many network operators is that with a transmission network of any size, provisioning is a painstaking process, one that relies heavily on the experience and network knowledge of skilled engineers. The result is that provisioning becomes a high cost bottleneck in the end-to-end service delivery process, delaying revenue generation from the delivery of new services (see Figure 1).

Symptoms of a provisioning problem include long service delivery timescales, round-the-clock staffing, and a proliferation of spreadsheets, desktop databases, and other tactical solutions.

One of the side-effects of the provisioning bottleneck is that increasingly exclusive attention is paid to delivering the service, at the expense of, say, efficient use of network resources, or post-delivery management of the service. By having to focus on provisioning, engineers don't have time to think about these other matters. The consequence of engineer resources being locked up with provisioning is an increasingly under-efficient network, with lots of bespoke build, done in an effort to avoid late-delivery penalties.

The end-to-end process of delivering new services has to span the gap between commercially-oriented processes, such as capturing a customer's service order, and network-oriented processes, such as configuring equipment using management systems. Somewhere, somebody, or something must interpret the service request and ultimately configure the underlying network resources required to deliver the service. Most often this resource is the provisioning engineer (see Figure 2).

In a typical scenario, a telco receives an order from a bank for a secure network link between Boston and Chicago on which electronic funds can be transferred. A call center handles the call, assigns a salesperson, and generates letters to the bank's telecom manager. In the telco's network operations center, an e-mail arrives from the call center, re-stating the bank's requirements, but with little more information than a bandwidth and two endpoints. The engineer's job is to identify, reserve, and assign the link, and then implement connections through a range of switching equipment, routers, and other circuits and cables. Many such services rely on the provision of leased lines from third parties (typically incumbent or local exchange carriers). If the link is intercontinental, then negotiations with an international carriers' carrier may also be involved.

As a service is designed, engineers typically reference independently-maintained sets of information. Physical data (such as inventory lists of synchronous digital hierarchy [SDH] equipment)—what types of cards and ports are available? Configuration databases—can we cross-connect at VC12 in a given add/drop multiplexer? Logical capacity spreadsheets—can we connect a VC4 between two given SDH rings? Leased line databases—do we already lease capacity between the two points? The result is often a lengthy "one step forwards, two steps back" process of navigating through the network to find and assign resources for the required service. Keeping the physical and logical data in step is particularly difficult.