|
Consumer Electronics and the Realities of
Retail Broadband Equipment
Where compliance with standards has limited vendors ability to be
unique & competitive
By: Bruce Bahlmann - Contributing Author (your
feedback
is important to us!)
Created: May 2, 2004
This paper is the product of
Broadband Market Research which is available from Birds-Eye Network
Services.
Perhaps as early as 1999, and even more so today, broadband service
providers have been looking more and more to this notion of shifting the
responsibility of purchasing various DSL/Cable modems, set-top-boxes (STBs),
etc. to their subscribers. These “retail initiatives” have significant
backing up and down their respective service provider organizations due to
the multi-faceted cost savings they invoke. While one would like to think
that what is good for the goose (broadband service providers) is good for
the gander (consumer electronics industry), the reality is that these
initiatives have yet to flourish. In this article we will discuss the forces
working against retail initiatives and why offering up this nut to the
consumer electronics industry has a long way to go before it can deliver a
new profitable market for hungry consumer electronics companies.
The promise of prosperity yet to materialize
One does not have to look hard to find struggling retail initiatives. One
such example is the Data Over Cable Service Interface Specification (DOCSIS)
cable modem. In the year 1999, there were more than 200 DOCSIS cable modem
products actively perusing certification from CableLabs. Many of these
products were being developed by startup companies looking to go well beyond
the “minimum specification” to create unique, innovative features that would
differentiate them from the competition and entice consumers and service
providers to buy them. At that time, with the emerging worldwide cable modem
market around 100 million units and the current pricing of legacy modems in
the $200-300 range, any piece of that market would appear to be a gold mine.
This was perhaps one of the most exciting times to have ever been associated
with the Cable industry as nearly anything seemed possible and in looking
through these lenses, the competition didn’t stand a chance.
  Startups
were purchasing nascent DOCSIS frameworks (also called reference platforms)
from chip vendors such as Broadcom and hardware vendors such as Cisco that
could be used to jump-start their product development activities. However,
the realities were that these reference platforms were only a framework for
DOCSIS development and that quite a number of things would still need to be
developed including additional firmware and even some hardware had to be
designed and added in order to produce a product that would certify. One of
first burnouts in the pursuit of DOCSIS certification was not a startup but
perhaps the largest consumer electronics company in the world, Sony. Sony
easily had the sleekest most promising looking cable modem among vendors
pursuing their first DOCSIS certification. Sony even had sales people
pounding the pavement trying to line up large orders for these gorgeous
looking devices. The problem was that perhaps they spent more time on the
design of the case than ever making the product compliant and ended up
dropping out of the cable modem business early. Unfortunately for other
startups and cable modem companies still diligently working towards
certification, they looked at this event as a positive sign rather than an
omen.
The original intent of DOCSIS was to create a standards-based
architecture where vendors interested in supplying hardware to the Cable
industry must certify. Although vendors participated in the development of
this standard, the preferences and directives given by cable operators
placed restrictions on how cable modems must operate, get provisioned, etc.
thus limiting the scope of creativity and innovation possible by any one
vendor. For example, the initial DOCSIS specification only briefly covers an
area called “vendor extensions” which by in large never got the attention it
deserved. As a result, all the cable modem vendors with wide aspirations of
being unique were forced to comply with very strict and narrowly defined
specifications that only allowed these modems to be used for one purpose –
data services. The only differentials were that some cable modem vendors
offered multiple connection options to the subscriber personal computer such
as Universal Serial Bus (USB) along with 10bT Ethernet while others offered
varied enclosures.
Today, only a small fraction of the original 200+ cable modem products
remain on the market. Interestingly, while these products have noticeably
improved, the core functionality remains the same. The specification for
DOCSIS cable modems essentially prohibits these devices from being much more
than greatly simplified connectivity mechanisms for cable’s data service.
This functionality is a far cry from the expectations and promises vendors
originally sought in obtaining DOCSIS certification. From a retail and
competitive perspective, why would a hardware vendor want to build a device
that must comply with such strict operational guidelines that it becomes
severely limited to the point where it cannot do much more than that? What
happened to the innovation and creativity of the late 90s along with the
promise of the dominating future? The answer lies within two key
deficiencies of the DOCSIS offering: vendor extensions and OSS.
Vendor extensions as and afterthought
Unlike vendor driven open specifications submitted to the Internet
Engineering Task Force (IETF), the DOCSIS specification was developed
“in-house” by cable companies with the “assistance” of interested vendors at
CableLabs. CableLabs is nearly 100% funded by cable companies and represents
it privately controlled standards body. While the initial goal of DOCSIS was
to develop a specification that would allow cable operators to mix and match
cable modem products that they deploy, the retail implications of this
approach were “considered” a side-benefit rather than anything the cable
operators or the participating vendors specifically were tasked to engineer
into the original specification. This fact exposes the major difference
between the IETF and CableLabs. Clearly, had the broadband modem been
designed primarily by the consumer electronics industry under cooperation of
the IETF and CableLabs, there would have been very little operational
difference between the DSL modem or the cable modem – if not from an
electronics perspective than from at least a provisioning and OSS
perspective.
From a consumer perspective, my personal preference would have been that
I could obtain a broadband modem capable of receiving service from either
DSL, Cable, etc. or any combination of providers and that the only thing I
would need from a service provider(s) was a smart card, a username/password,
or something similar to enable my service. Today, so much time and effort
has gone into over engineering the electronics, security, etc. of broadband
modems that the resulting device is too expensive for the broadband service
providers to deploy, the margins on the devices are too low to justify the
added functionality, or there just is no room within the specification for
vendors to innovate or be unique. That is one of the major limitations
between “in house” developed specifications and those developed more openly.
There is something to be said about the speed at which more open
specifications evolved. More open specifications tend to evolve much more
slowly than those being championed by stakeholders, however through this
kind of collaboration more diverse functionality would be possible that goes
above and beyond the minimum requirements. Again, the consumer electronics
industry is all about innovation, customer convenience, and volume sales.
OSS that only speaks common language
In development of hardware that must be activated out in the field, one
of the top priorities is that it first be compliant with the standards and
specifications. However beyond this requirement, remote software activation
ranks closely behind followed by support for automatic provisioning (or
autoprovisioning). Having a product that complies with standards is useless
if the service provider (or consumer) looking to purchase this equipment
cannot easily provision it. Provisioning dissimilar Customer Premise
Equipment (CPE) has generally followed a “least common denominator”
approach. Using the Least Common Denominator (LCD) approach, OSS vendors
survey the list of CPEs used by service providers and determine the minimum
required communication set (provisioning commands, functions, capabilities,
etc.) that would enable all CPEs to be activated. It would then build a
generic command set from this minimized LCD communications set. Note that in
using this method an OSS vendor builds a knowledge based of the CPEs it has
integrated with so any new deployment generally only has to worry about new
CPEs. Another way of saying this is that OSS seeks to simplify the task of
provisioning all the different types of CPEs, and to do this it only uses
the command set common to all CPEs rather than treating each CPE separately.
If OSS could treat each CPE uniquely, it would allow the service provider,
consumer electronics industry, as well as the consumer to exploit the
complete functionality set of the CPE. While this is what the consumer
electronics industry has been waiting for, a number of factors stand in the
way of any OSS vendor achieving this anytime soon.
Service provider must push standards bodies
One of the most common methods of achieving multi-vendor CPE
interoperability among OSS companies is the use of an adapter (also called
“a wrapper” or “an abstraction layer”). An adapter allows the OSS vendor to
mask their minimized LCD communications set by exposing only those functions
required to interface with a specific type of CPE. Within the adapter at
least two things happen. First, each required CPE specific command is mapped
to its associated OSS minimized LCD communications set. Second, the
communications with the CPE are programmed so whether the CPE uses SSH,
SNMP, Telnet, etc. the adapter can perform the necessary communications to
facilitate the required commands. This technology has been around for quite
a number of years so it is proven, reliable, and well accepted. So what is
wrong with using an adapter you ask? The answer lies within the use of a
minimized LCD communications set.
The minimized LCD communications set only contains the minimal commands
needed to accomplish provisioning of the specific services that the OSS is
geared to support. Meaning, that if the OSS did not support the setup of VPN
the minimized LCD communications set would not contain those features and
neither would the adapter. When OSS is designed around using a minimized LCD
communications set it is pretty much limited from the start and from a
retail or consumer electronics industry perspective, this is the last nail
in the coffin.
Reversing this direction is a mammoth task for the OSS vendor as the
minimized LCD communications set forms the basis that the software is built
around. If you change this to allow each CPE to be defined uniquely or
better yet discovered and built dynamically. The resulting minimized LCD
communications set must be completely abandoned in favor of a massive hybrid
communications set. Such a hybrid communications set must be capable of
permitting service providers to exploit all CPE uniqueness without manually
building, testing, and deploying new adapters each time a new CPE becomes
available retail. This goes against the grain of how today’s OSS products
have been developed. OSS only supports the services currently being offered
by service providers so unless a service provider has thought of it and
express a need for such functionality, it pretty much will not exist within
the OSS feature set. It is pretty tough for a CPE vendor to not play inside
this sand box and still keep their products selling into service providers.
Clearly the way this model works is, service providers define the services,
CPE vendors support the functionality, and OSS does its best to make it all
work. In reality, all three parties should be free to innovate independently
with the necessary assumption that OSS must still make everything
plug-n-play once it all comes together. The key here is that the OSS vendor
must not be the gating factor to support new services. While they may be the
platform that drives these services, development should not be required in
all cases. The need to always go back to development to support new
equipment, features, or business lines is the key design flaw in any OSS
vendor’s product today.
Next generation OSS vendor products must/will rise above these
limitations and promote unencumbered service creation. Not the lame service
creation we see today where you can change different speeds or combine
existing components of various services into new packages or offerings, but
rather new services comprising of new components that were not part of the
original feature set of the OSS system at the time of the purchase. Service
providers not achieving this level of OSS capability must champion the drive
for better, more open, and more flexible OSS as well as involve an
organization outside of privately funded standards organizations to ensure
the greatest possible interoperability is achieved. Only then will you see
consumer electronics industry companies start to re-engage with this market
and innovative products start to be created that will once again capture the
imagination of public demand that just wants to be dazzled. I don’t know
about you, but after 8 years, wouldn’t you think we would have more than
these simplistic broadband data services?
Check out these other Birds--Eye.Net papers/products related to Retail
Broadband Equipment:
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.
|