|
Broadband Provisioning: The need for a
standardized framework
Putting an end to reinventing the OSS wheel once and for all
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: February 12, 2002
Note: For help designing, building, and implementing your provisioning system or developing tools to help you improve or implement such a program contact Birds-Eye.Net.
Building any broadband service offering
(e.g. data, voice, video) requires many different components (hardware, software, and
people) that all must work in harmony for any business offering this service to be
successful. As these service offerings diversify (e.g. data service divides into tiers to
address the needs of varied business sectors in residential, institutional, schools,
telecommuting, and commercial) there is a need to build upon an existing framework.
Broadband provisioning is an area that is crucial to the success of building &
expanding broadband service offerings yet void of an all-encompassing standard. I believe
this lack of broadband OSS standardization to one of the anchors left still attached to
the broadband vessel that has yet to set sail.
The sum of
all its parts is less than the whole
When broadband operators and engineers
alike rallied to conceive data over cable service interface specification (DOCSIS), a
tremendous milestone in the broadband industry was reached. The result was a complete
system of components that together would compose the building blocks of a myriad of
service offerings to come. Among these components a number of them loosely composed
something called an operational support system (OSS). OSS components consisted of simple
network management protocol (SNMP) server, dynamic host configuration protocol (DHCP)
server, trivial file transfer protocol (TFTP) server, and time of day (TOD) server. These
components (servers) were defined within the DOCSIS specification relative to how each
contributed to the activation, continued operation, and support of a service offering
based on DOCSIS. The word provisioning became associated with this suite of
servers/applications that together performed the function of DOCSIS OSS.
Interestingly, there really is no
provisioning specification that describes these applications collectively. In part, the
reasoning for this was when DOCSIS was written each OSS application functioned
independently elsewhere out on the Internet and was described in infinite detail in
Internet engineering task force (IETF) request for comments (RFCs). Perhaps the authors of
the DOCSIS OSS never envisioned what they were doing in specifying the required
interaction of these IETF standards-based applications to facilitate their evolving DOCSIS
specification. In fact, early DOCSIS OSS merely consisted of a collection of these
well-configured applications running independently. However, as automation and operational
efficiencies have played out, the days of these applications all running independently in
a kind of component-based approach to provisioning have all but died out.
Today, all major vendors in the
provisioning application space bundle all their OSS applications together. They do this
out of the need to offer full-functionality and a tightly integrated solution. Vendors
still offering a component-based approach fail to match the functionality of the major
vendors, as the best they are able to offer is mean functionality – only that
functionality that works across all disparate components.
Broadband operators who do not seek a
single vendor solution to their DOCSIS provisioning needs face a dieing breed of vendors
offering full-featured component-based systems and also find they must take on outside
consultants or develop unique integration experience among their employees to manage this
complex blend of vendors required to offer such a system. Even with the help of this
acquired expertise, these solutions will always lack the functionality of competing
against tightly integrated solutions and in the end these operators will find the road to
new broadband service offerings slow and cumbersome. That is, unless they become
full-fledged development houses creating their own software. For most broadband operators,
they would like to keep customer and service focused so the distraction of designing,
developing, and supporting their own software goes beyond their desired core
competency.
The advent of the second service offering
based on DOCSIS has begun to reverse the course that component-based provisioning
approaches previously established. The implementation of Voice over Internet Protocol
(VoIP) using DOCSIS has began to treat its OSS as a system rather than a set of individual
components. Unfortunately much of this implementation (which is also known as PacketCable)
was developed around the same time as DOCSIS so the idea of treating the entire OSS as one
system evades even this service offering. The result of not treating all these
applications as one becomes obvious when deploying an OSS that supports both data and
voice – you pretty much need two separate systems (one OSS for data and another for
voice).
If you want to expand your number of
service offerings but don’t want to keep purchasing entirely new
applications/equipment for each service offering somewhere you need to lay down a
framework on which you can build. This framework should not be an individual component of
the system that you can add other components to and then continually re-glue them all
together to create new service offerings. Rather, a fully functioning framework that
supports all the basic aspects of OSS as described in DOCSIS along with others that are
just as important but not sufficiently mentioned in DOCSIS – like billing,
troubleshooting & trouble ticketing, administration and management, etc. Upon this
framework you can continue to grow and expand your service offerings by merely reusing
and/or expanding your existing OSS system. Treating OSS as a system also buys you a lower
incremental cost to enter new service offerings as opposed to fork lifting entirely new
systems into place that require months of preparation, testing, integration, and field
trials before they are ready for prime time – not to mention risk assessment!
Opps, there is something we forgot to test
Unfortunately the fear of a single vendor
solution remains an obstacle for many broadband operators in purchasing a complete
provisioning system. Few of the major provisioning vendors are stable companies with
unwavering support and loads of reserve funds. However, and perhaps more importantly,
there are no specifications that really describe the OSS as entire system so many of the
major provisioning vendors have taken matters into their own hands defining what they
believe their customers will want. As a result, any OSS system that is purchased by a
broadband operator ends up being unique. If vendor who provided it goes out of business or
changes its focus, the operator is left with something they must replace to grow their
business. No simple task if the OSS system supports multiple service offerings!
I propose OSS be approached as a system or better yet a black box. If
the OSS system were a black box with everything both north and south of the black box
defined, a single vendor solution to OSS would seem less risky as the entire system could
become plug-n-play. A black box OSS would also invite certification by multiple broadband
industries including telephone, cable, satellite, and wireless expanding the markets for
OSS vendors while standardizing products for each of these industries to deliver services
to compete for each other’s customers. I do not believe that OSS should become part
of larger entities like customer care systems, network management systems, or even billing
systems. While there is certainly overlap between OSS and these larger entities, OSS is
clearly not a function (or for that matter a core competency) of these larger entities.
Regardless, these larger entities are pushing forward with plans to incorporate some OSS
capability within them. However like billing systems attempting provision set top boxes
(something that still works today but has never come close to doing much more than very
basic service video service activation) these attempts are all doomed to failure as they
attempt to position a feature rich capability such as device or even service provisioning
within the paradigm of customer care, network management, or billing. Provisioning will
always be the oddball requiring its own unique system – at least if you want to
exploit the advanced features of devices being built today.
Treating the OSS as a system is not a new idea. It has been around
for quite a while, but lacks the support of public opinion to establish a beachhead within
the standards body as well as broadband operator demand. A number of attempts have
surfaced to start some kind of qualification or standardization program for OSS but
require vendor participation and more importantly broadband operator need before they can
be successful. If broadband operators are not asking for this, its much more difficult to
get provisioning vendors interested in standardizing their products. Only out of an
established need from the broadband industry will standardization come to this
all-important area of broadband OSS. Perhaps then, with standardization in place will this
broadband vessel finally set sail and we all start enjoying some of these things
we’ve been hearing about!
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.
|