Tutorial: How to Provision a Data Service

By Dan Baker Comments
Print
From the outset, provisioning a data service is a complex, multi-step process that involves figuring out your end-to-end topology and all of the network devices that need to communicate with each other.

This can require some pretty sophisticated software. Remember, a data service is not like voice where you simply tell one access switch that you want service, and the job’s done. Provisioning data services includes dozens of discrete processes—everything from receiving of the customer order to creating a network workflow to activating the device to informing all the systems what you’ve done. With a data service you may need to configure dozens of network devices along the connection path.

For starters, data provisioning includes things like CPE management, which involves knowing whether a CPE needs to be installed, handling truck rolls, and keeping track of any rules on how the CPE needs to be configured.

It also includes network augmentation, which deals with any build-out of the network that’s needed to fulfill the order, such as installing a new card.

Yet another data services function is physical and logical design and assign. This entails figuring out the path the service should follow through the network across multiple technology and vendor domains.

There is also network inventory, which keep tabs on all physical and logical resources, plans their deployment and periodically discovers all the devices out in the network.

A crucial complement to inventory is field technician and facilities management, because your inventory system can’t keep track of your network’s passive equipment. People are still needed to manually configure devices, lay fiber and configure a distribution frame in the central office.

OK, we’ve reviewed several essential OSS functions. And we’ve deliberately saved the most difficult function for last—activation.

In simple terms, activation involves taking service orders and translating them into the specific APIs of all the devices you’ll use to turn up service in the network.

In billing jargon, activation is mediation in reverse. Instead of taking data from the switch and feeding it to billing, you’re taking a service order and feeding instructions to the switches and routers.

At face value, activation expertise sounds like a skill that’s easily acquired. But in truth, relatively few OSS vendors have it. Sure, in-house teams and consultants can develop one-off network element interfaces when they need to, but it’s often an expensive, time-consuming chore.

Companies like MetaSolv, Syndesis and Telcordia that specialize in activation have spent years understanding the quirks of network devices. And along the way they’ve developed libraries of activation code for many families of network elements.

Typically the northbound APIs or element management systems aren’t that well documented. So to get around that, an activation software vendor also needs to cultivate working relationships with engineers at Cisco, Alcatel and other network equipment vendors.

Likewise, activation vendors have had to refine their techniques for revising the interfaces to network devices that are constantly being upgraded. Engineering time is too precious to update the interfaces for every network device on the planet. So upgrades must be carefully scheduled to meet say SBC’s deployment of a new Siemens switch-based service in November.

With all the provisioning functions and processes we’ve talked about, you’d think that instant activation would be hard to achieve. Surprisingly though, it’s done all the time. The secret is to pre-provision the data service ahead of time.

For a straightforward DSL service, the common practice is to pre-populate the network with the DSL cards so your network is pre-configured for instant activation. (The same principle applies in the wireless world where handsets are pre-set to activate out of the box.)

As desirable as instant activation is, there are times when it’s not appropriate. Take an optical service where each network card costs $10,000. With budgets the way they are these days, a telco may not have the luxury of pre-populating cards, so you can’t activate on the spot. Instead you need to need to dip into your spares inventory, find the card, install it, then activate it.

Yet another factor that lengthens the time between provisioning and activation is waiting for “off-net” connectivity. This happens anytime you’re handing off your traffic to another operator via the so-called interconnect gateway. In this case, your own provisioning flow is on hold until the other carrier fulfills its leg of the journey.

Off-net provisioning is quite common these days—even with ILECs. As soon as an ILEC service crosses a LATA boundary, it’s sent to another network owner. Now, if you’re SBC, you’re passing it off to Williams because Williams handles SBC’s InterLATA traffic under a closed deal. But Williams still needs to provision SBC’s data services across its own network using its own OSS systems—and that handoff inevitably slows down your provisioning flow.

The gap between the time a service is requested to the time a data service is provisioned is becoming shorter and shorter. However, for the most advanced services automation doesn’t necessarily make sense, so don’t hold your breath.



Dan Baker, research director of Technology Research Institute (TRI), has been tracking the OSS market since 1995. He authors multi-client studies and writes value

proposition papers for software and consulting firms. He can be reached at danb@technology-research.com.

Comments
HELLO
comments powered by Disqus