OSS/BSS: The Greenfield Myth

In the Telecom world, there is a myth which states that you can build a brand
new, state-of-the-art network from scratch without using any no legacy hardware.
Just go right to the new DWDM fiber optic, wireless local loop (WLL), or 3G and
jump over the luckless competition, who has to deal with legacy systems that
will need to be upgraded or replaced. From the hardware point of view, a
greenfield network implementation like this can happen, but in the operations
support systems (OSS) world, it's not so simple.

At tradeshows or conferences, presentations about greenfield OSS usually
display a cultivated field growing a single, crop. When I started selling OSS
(rather than using it) a few years ago, the going greenfield visual was the one
you see in the first photograph.

Visualising a greenfield as a cultivated field implies one vendor and one technology, and a simple network management system or OSS offered by the hardware vendor to support all of the network's management needs. The greenfield in this photograph is far more realistic. It is bordered by hedges and has a few trees in the middle. You can visualize the optical layer running between the backbone trees in the upper right and the green, yellow, and red of the different services in the foreground. The access is shown by the taller shrubs, which are not uniform because you could have different access methods for the same services (such as xDSL and WLL).

I was never comfortable with this image. It seemed too simplistic, too much
like getting something for free, and I firmly believe in TANSTAAFL (there ain't
no such thing as a free lunch). Robert Anson Heinlein threw up this term in the
book The Moon Is a Harsh Mistress and added that anything free costs twice as
much in the long run or turns out worthless. The simplistic picture suggests
that all of your network elements are of one type and vendor, but that is not
the case. It doesn't matter if you are building a cellular UMTS network, or
even a CLEC; your network will have many different elements-and that means
complexity in integration and management.

These include the backbone elements (optical switches, core routers, class 4
or 5 switches, etc.), access elements (routers, switches, base stations, WLL/LMDS/microwave
transmitters, Metro or Gigabit Ethernet, DSLAM, etc.), and those related to the
offered services (gateways, service servers, firewalls, voicemail, IP centrex,
etc.)-a much less uniform network than the one represented by a cultivated
field.

If all you have only one vendor and single technology, then an element
manager will probably be enough. It knows its own hardware and can show failures
and handle basic provisioning. If you need a more management, then you can go
for the custom-integrated solution where you use off-the-shelf products and
handle the small customizations and integration yourselves.

For a more complex network, where there are multiple vendors providing
multiple technologies, you need a fully integrated OSS. Managing all of the
fulfillment and assurance parts of the network requires tight integration
between the configuration and topology information, and the fault and
performance information. This can speed the root-cause analysis, or make
end-to-end performance measurements possible.

A good plan can reduce your initial outlay for the OSS systems and spread out
your capital expenditures over several years, rather than paying for the whole
system up front and then not using it until later. Based on my experience of
working with two different telecommunications carriers and at TTI Telecom, I
offer the following suggestions, which will help you sequence your investments
in time and money to maximize results and minimize pain.

To quote Daniel Klein and Camille Mendler of the Yankee Group: "Don't
leave OSS until last." To reap the benefits of a converged packet
infrastructure, operators need to launch a rational OSS strategy in parallel
with any planned migration and service launch. Converged services are reliant on
flexible management systems to adapt to changing customer needs. In addition,
without a parallel OSS migration strategy, operators stand to negate the
substantial operational savings that packet infrastructures can offer.

Phase I

• A strong mediation layer: This will enable your OSS to
  communicate with all of the EMS and the actual elements directly. This
  requires that the mediation has knowledge of the hardware and an EMS with
  documented APIs. It is also recommended that you make sure that there is a
  significant library of hardware that is already supported and can
  plug-and-play with the mediation layer.

• A fault management system. Once you have the mediation
  layer, you can add above it the needed OSS functions, either all at once or
  in a phased approach as your network grows. I find that fault management is
  usually the first system that service providers install, because knowing the
  status of the network hardware is important to them at the beginning, as the
  network and services are being rolled out.

• Performance management allows you to see who is using how
  much of the service, and to predict when you will need to analyze special
  sales offers or add new network capacity. The reports generated can also be
  used to show customers when it is time to upgrade their services and to
  justify the current billing.

• A trouble-ticket system for network management. I know of
  several large companies who delayed the decision to install one, only to
  realize that when each department uses its own EMS, one group can actually
  make a problem worse by not coordinating the repair process with the others.
  It should be integrated with the fault system so that faults are linked to
  related tickets and over time, your staff can reuse successful solutions
  based on the same or similar problems.

• A billing system, although not part of the actual OSS, is
  also an important component at the start. You may offer a short trial period
  where you do not charge customers as they act as beta testers, but you will
  want to start billing and realizing revenue as soon as possible. This should
  be integrated with the mediation layer to enable uniform performance
  reporting and system consistency with the trouble ticket system.

Phase II

• Wait on the provisioning system. Customers often request
  provisioning as one of their initial systems, although they hardly use it in
  the first six to 12 months while they are learning: how their network works,
  what business processes they need to implement the services, and what
  network performance level they can offer in their SLAs.

• A work-order management system. Initially, most customer
  services are installed at the rate of a few per week or even per day. Later
  on, this can grow to hundreds per hour, and that is when you need a
  work-order management system, complete with: workforce management, planning,
  provisioning, and an activation system. This is where the benefits of
  reduced errors in implementation will translate to cost savings and improved
  sales.

Phase III

• A service management system. As the network grows, your
  need for a service management system also grows-a system that can sit
  above the fault, performance, and trouble-ticket systems and report on the
  end-to-end service as the customer perceives it. A system that can provide
  SLA reports and warn operations of pending SLA violations before they happen
  can pay for itself quite rapidly, making this a potentially
  revenue-generating addition to the OSS.

Eric Klein
NGN Solution Manager at TTI Telecom