|
Archive
Flanagan
Consulting
Network Analysts and Consultants
"We Have
the Experience"
--------------------------------------------------------------------------
ViewsLetter on Provisioning
July 2002
#2
Lead Analysis
MORE THAN HINTS ABOUT A SOLUTION:
PROVISIONING AND WORKFLOW SOFTWARE
Last time we posed the problem: it is impossible to meet the demand for
new data services using today's manual provisioning. By comparison
to
voice switching, it was clear that we believe automation is the solution.
This edition takes a high-level look at what's happening in network
operations software.
Quite a lot is happening, in two fundamentally different ways:
1) Incremental software added to existing equipment and inserted
around
older software applications to bridge the gaps among formerly separate
systems.
2) Totally new operations systems that replace legacy Operations
and
Support Systems (OSS) applications designed for "flow through
provisioning."
Most announced products fall in the first category, though they will
migrate with the developing standards for managing networks.
Both approaches have the same goal, which is to automate the transfer
of
information from a customer's request for service, all the way to the
input of the required configuration parameters into every affected Network
Element (NE). Traditionally, telephone companies maintained
many sets of
records, one associated with each functional department such as order
entry, voice switching, data services, billing, and transmission
operations. Between departments, information traveled on paper,
often a
form prepared by the recipient of the information.
Each department kept its own copy of the information used there.
In this
system, a change request from a customer results in many updates of the
same information, once in each department, offering multiple opportunities
for data entry errors. No one place held all information about a
customer, making it difficult to answer some questions, either from the
customer ("How many lines do I have?") or from regulators ("What quantity
of each service is used by each type of customer?").
The situation for coordinating a circuit or service between carriers
reflects the same problems, with the addition of another variable--the
level of desire a carrier has toward success of the business interface.
In some cases, between LECs and Interexchange Carriers (IXCs), automation
provides a fairly smooth process because both parties need it to work
in
order for their businesses to succeed. By contrast, the provisioning
relationships between Digital Subscriber Line (DSL) providers and
LECs--for whatever reasons--didn't perform well when first set up.
They
started with fax transmission of orders from the DSL company to the ILEC,
where people processed them manually. As volume grew, and processing
predictably created a backlog, the Federal Communications Commission (FCC)
required ILECs to open their order entry systems for electronic input
from
Competitive LECs (including the DSL companies). That proved to be
a large
task, and still only a small step toward fully automated provisioning.
Every Incumbent Local Exchange Carrier (ILEC) has customized an OSS to
its
own tastes. Over time, choices in hardware often led to additional
network management applications entering the operations center.
Seldom
have these systems integrated easily, if at all. The upshot is today's
array of terminals and servers needed to manage a multi-vendor,
multi-protocol network (and they are all multi-vendor/multi-protocol).
Theoretical work over the last 10-15 years by academic researchers created
a new way to look at the hardware and software in a network.
A
scientific approach to classification succeeded in grouping similar
functions into classes of managed objects, defining the inputs and outputs
those objects accept and deliver. Others created algorithms for
management functions such as circuit setup or fault isolation. In
the
last few years those ideas have appeared in products aimed at network
operators.
High-level network management systems (NMSs) have been with us for more
than a decade. H-P's Openview and IBM's Tivoli (descendent of NetView)
set out to govern all the pieces in a large enterprise network.
But they
are not always well integrated beyond gathering and displaying alarms--it
depends on what functions each NE vendor's add-in software performs.
For
example, the top-level workstation may receive all Simple Network
Management Protocol (SNMP) "trap" messages (alarms), and display them.
But configuration of NEs (that is, provisioning of services or maintenance
functions) still may depend on a command line interface (CLI) in a
terminal emulation window. Carriers need much more integration to
advance
toward automated service provisioning.
The Telecommunications Management Network (TMN) architecture provides
a
framework for standardizing interfaces among components of a network.
TMN
specifically addresses the problems of a public network and the carrier
that operates it. Like an NMS for an enterprise, the TMN approach
defines
network elements and specialized Element Managers (EMs) for each type
of
NE. What's different is that TMN's five layers go "higher in the
protocol
stack" than the Open Systems Interconnect (OSI) seven-layer model to
include business issues. For example, TMN considers the need to
define
services that earn profits to keep a carrier in business, as illustrated
in these brief descriptions of the TMN model.
TMN Model
-- Business Management Layer: sets policy for types of services
offered,
profit goals, etc.
-- Service Management Layer: defines "products" or carrier services
in
high-level terms ("Internet access," "leased line," etc.)
-- Network Management Level: operations system for overall control,
configuration, and error management
-- Element Management Level: where specialized software platforms
control
specific types of equipment (NEs), usually based on vendor
-- Network Element Level: the hardware--nodes, switches, routers,
transmission gear--that make up the network
TeleManagement Forum (TMF) works within the TMN framework to define very
specific interfaces at each level of a network, procedures to communicate
across those interfaces, and even business agreements between carriers
and
their customers. The International Telecommunications Union, Telecom
Sector (ITU-T) has operated in this area at the international level for
about 15 years.
What they are defining is a New Generation Operations Systems and Software
(NGOSS), as TMF calls it. Under this name, they are defining how
things
should be, what vendors are working to build, and probably what carriers
will be using in the future. Don't forget, however, that very thorough
and complex specifications can sometimes be overtaken by the market, never
to be implemented widely. Consider, for example, Local Area Networks
(LANs) based on ATM to the desktop.
What's happening immediately is that a relatively large number of
companies are offering software systems to bridge specific gaps in the
road from order entry to working service. Some examples of product
areas
are:
--Billing; sorts and filters information from an IP network, optical
backbone, or other "new generation" equipment to generate call detail
records (CDRs) suitable for a legacy billing system that was designed
for
circuit-switched voice.
--Alarms; correlates alarms from multiple element managers to find
the
"root cause" failure.
--Configuration; translates carrier policy and customer order into
final
configuration commands to all the participating network elements.
These products deal with legacy NMSs--those that lack a standard interface
(such as TMN). The "bridge product" may add a standard interface,
allowing the older product or system to continue working in a standardized
environment. Or the bridge may be built directly between legacy
interfaces, in a single product, rather than building the standard
interface separately on two legacy systems. For example, a configuration
product can interpret older provisioning instructions into command line
instructions for specific router models.
In coming editions we'll examine these areas in more detail, including
short reviews of specific products. Speaking of plans for the content
of
ViewsLetter on Provisioning, we couldn't ignore the hardware side.
If
there's something in particular that interests you, follow the link below
to make a suggestion or request.
LINKS
-- The previous ViewsLetter(SM) available at www.flanagan-consulting.com;
click on "Publications" in the site map.
-- The next issue will be posted in the same location shortly after its
publication.
-- Visit our web site for information about our consulting and analyst
services, speaking engagements, and updates on other activities, or
contact us by email at info@flanagan-consulting.com.
-- Special thanks to www.webtorials.com for hosting our web site and
ViewsLetters.
-- For sponsorship information, email us at
mailto:info@flanagan-consulting.com or phone.
-- Sites related to this issue:
TeleManagement Forum (http://www.tmforum.com)
ITU (www.itu.org)
Introduction to TMN (www.simpleweb.org/tutorials/tmn/)
"Flanagan Consulting" and "ViewsLetter" are
Service Marks of W. A. Flanagan, Inc.
Updated: 11 June 2003
|
