Fujitsu Operations Automation Using NETSMART 1500 Element Manager Paper19
User Manual: Fujitsu Operations Automation Using NETSMART 1500 Element Manager FNC Industries - Telecom Service Providers - Fujitsu United States
Open the PDF directly: View PDF 
.
Page Count: 9
422 FUJITSU Sci. Tech. J., Vol. 45, No. 4, pp. 422–430 (October 2009)
Operations Automation Using NETSMART
1500 Element Manager
Denise Provencher
(Manuscript received March 26, 2009)
This paper will describe methods of automating operations processes such
as network monitoring, service activation, and data collection using external
interfaces available in the NETSMART 1500 Element Management System (EMS).
It will describe the functions of each interface and describe the specific customer
applications of these interfaces to automate manual processes. Observations
regarding our experience with operations automation, particularly using standard
interfaces, will be described. Finally, this paper will examine whether use of an
element manager with standard or well-defined interfaces reduces the time and cost
of introducing new network technologies and services.
1. Introduction
Network and service providers maximize
prots by reducing network operations costs
and by decreasing the time required to offer
new services. Expense reduction and revenue
maximization can be achieved by investing in
process automation. In the past, automation
involved developing monolithic software systems
that communicated directly with network
equipment to collect alarms and provision
services. Over time, the cost of developing
specialized interfaces for each technology and
vendor providing network equipment became
prohibitive. The introduction of standardized
equipment interfaces such as Simple Network
Management Protocol (SNMP) and Transaction
Language One (TL1) simplied alarm monitoring
operations, but often had little impact on the time
and cost required to support service provisioning
and activation. Beginning in the late 1990s, a
standard interface was dened between Element
Management Systems (EMSs) and Network
Management Systems (NMSs) or Operations
Support Systems (OSSs). The intent of this
interface was to abstract network and service
resources for presentation to the OSS/NMS,
and to allow vendor- and technology-specic
information to be managed solely by vendor-
supplied EMSs (Figure 1). The EMS-NMS
interface model and specication belongs to a
suite of Multi-technology OSS Program (mTOP)
standard interfaces from the TeleManagement
Forum (TMF).
The purpose of this paper is to describe
how process automation is supported by the
NETSMART 1500 element management
system using various external interfaces; how
those interfaces have been applied; and how
well standard interfaces between element
management layer (EML) and network
management layer (NML) achieve the twin goals
of reducing the time and cost of deploying new
technologies and services.
423
FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
2. NETSMART 1500 overview
The NETSMART 1500 element management
system was developed by Fujitsu Network
Communications in response to customer
requirements for a highly scalable and highly
reliable SONET network manager. When
NETSMART 1500 was introduced, carriers
adopted vendor-supplied management systems
to supplement their OSSs. Aside from providing
better tools for fault location and analysis,
vendor-supplied management systems allowed
new services to be offered quickly, well in
advance of comparable support provided by the
OSS/NMSs.
The NETSMART 1500 product has evolved
over the last decade to become a world-class
management system for Fujitsu access and
transport equipment. It provides a robust set
of network management features including
graphical network surveillance, end-to-end
service provisioning, inventory and capacity
management reporting, performance data
reports, remote NE software upgrades, automated
remote NE conguration backups, and a variety
of “northbound” interfaces (NBIs) for integration
with OSS and NMS systems.
In the last few years, customers have
started integrating NETSMART 1500 into their
operations architecture using the TMF standard
and other interfaces.
3. Northbound interface options
NETSMART 1500 offers a variety of
northbound interfaces (Figure 2), each of which
is described below.
3.1 TL1
The TL1 northbound interface supports all
management functional areas by allowing an OSS
or NMS to send/receive TL1 messages to/from the
network elements via NETSMART 1500. TL1 is
a (primarily North American) standard ASCII
message set commonly supported by transmission
NEs. The NETSMART 1500 interface effectively
serves as a TL1 conduit, supporting the message
set over TCP/IP.
The TL1 interface does not provide any
abstraction to the OSS/NMS, nor does it simplify
the requirements at that layer. It does, however,
allow OSS/NMSs access to NEs without having
to congure separate userids in each NE or use
separate NE login sessions.
The primary application of the TL1
interface is alarm forwarding. However, the
Network management layer (NML)
Element management layer (EML)
Element layer (EL)
Network
Monitoring
OSS
Service
Activation
OSS
Network
Monitoring
OSS
Service
Activation
OSS
Proprietary
interfaces
Standard
interfaces
Element
Manager
NE NE
NE
NE
NE NE
NE
NE
Figure 1
Non-layered and layered OSS architectures.
424 FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
interface is bidirectional, and may also be used
to send provisioning commands or to retrieve
performance data.
3.2 SNMP
The NETSMART 1500 SNMP northbound
interface sends alarms to the OSS/NMS in an
SNMP format using UDP/IP. NETSMART 1500
encapsulates TL1 alarm messages in SNMP traps
and sends them to one or more destinations.
The SNMP interface is used exclusively for
fault management, and allows popular SNMP-
based OSS/NMS network surveillance products
to easily monitor TL1-based transmission
equipment.
3.3 MTNM CORBA
The CORBA northbound interface provides
the greatest functionality and the greatest
complexity. Based upon the Multi-Technology
Management Network (MTMN) TMF 814
interface version 2.1, it supports fault monitoring,
service provisioning, inventory reporting, and
performance monitoring. This interface is one of
the aforementioned suite of mTOP interfaces.
The CORBA interface provides an abstract
model for OSS/NMS applications that is
particularly well suited to provisioning and
service activation applications. It is based upon
a simplied model of network resources, and is
designed to take advantage of intelligence at the
EMS and NE layers. As mentioned earlier, the
intent of the MTNM interface specication is to
relieve the OSS/NMS of modeling vendor-specic
implementation details, and to standardize
operations between the OSS/NMS layer and the
EMS layer.
In the MTNM interface, network equipment
is modeled as a set of hierarchically named objects
representing resources such as racks, shelves,
slots, sub-slots, circuit packs, and SFP/XFPs.
Physical connections between network elements
(e.g., bers) are modeled as Topological Links that
originate and terminate on ports referred to as
physical termination points (PTPs). Transmission
paths, or circuits, are modeled as subnetwork
Fault
Management
Service
Activation
Inventory
Management
PM&Trend
Analysis
SONET WDM Carrier
Ethernet
Multiservice
Packet
Transport
CORBA, XML, SNMP, TL1, FTP
NETSMART 1500
Data
Communications
Network
Network management layer
Element management layer
Network element layer
Figure 2
NETSMART 1500 northbound interfaces.
425
FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
connections (SNCs) that originate and terminate
on connection termination points (CTPs). There
is a containment-naming relationship among
termination points to model transmission layers
(e.g., VT1.5 paths contained in STS1 paths). Note
that this brief description is a simplication of
the underlying model, but describes the essential
components.1)
As implemented by NETSMART 1500,
the CORBA interface supports the following
functions: fault event reporting, inventory
retrieval, provisioning and service activation, and
current and historical performance monitoring
reporting.
3.4 FTP
The NETSMART 1500 FTP interface
provides an efcient way to collect and transfer
large amounts of performance monitoring data on
a periodic basis. It has been implemented in a
standard fashion, as part of the TMF MTNM
interface, and in a slightly simpler proprietary
fashion. The standard interface allows historic
PM data to be requested by an OSS/NMS using
the CORBA interface. Upon receiving such
request, the EMS generates a formatted le of PM
data and transfers it to a location specied by the
OSS/NMS using the File Transfer Protocol (FTP).
The proprietary version of this interface works
essentially the same way. However, the request
for PM data collection and transfer is made by
a human from the NETSMART 1500 GUI, and
the resulting le format uses native NE naming
conventions (i.e. TL1 naming conventions) rather
than TMF standard names.
3.5 MTOSI XML
The latest addition to the NETSMART 1500
set of northbound interfaces is an Extensible
Markup Language (XML) interface based on
the TMF Multi-Technology Operations System
Interface (MTOSI). MTOSI, like MTNM, is part
of the mTOP suite of interface specications. The
MTOSI interface uses the same network model
as MTNM, but offers interfaces using Simple
Object Access Protocol (SOAP) encapsulated
XML documents over JMS or HTTPS.
NETSMART 1500 supports two functional
areas using XML: fault event reporting and
inventory query and reporting. We expect to
expand the functions supported by this interface
as XML/SOAP has become a preferred interface
for business applications, owing to its simplicity
and platform independence.
4. OSS integration applications
This section describes some of the key
customer applications currently using one or
more of the NETSMART 1500 northbound
interfaces.
4.1 Carrier #1
This carrier utilizes an EMS layer in its
operations architecture and has long been a
proponent of TMF standard interfaces. Using
the NETSMART 1500 MTNM CORBA interface,
the carrier has automated fault management
reporting, network discovery, and service
activation operations. It also uses the FTP
interface to collect PM data for all network
elements on a daily basis. The carrier does not
deploy new network equipment or releases until
they are fully supported by the vendor’s EMS
northbound interfaces.
While this carrier makes extensive use of the
MTNM interface, the complexity of the interface
is mitigated by the following:
• NETSMART 1500 EMS, the northbound
interfaces, and the network equipment were
introduced into the carrier’s network at the
same time.
• The network is limited to a single network
element type.
• The services provided over the network are
limited in scope.
On the other hand, this carrier introduced
some modeling and operational concepts that
previously had not been supported by NETSMART
426 FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
1500. Based upon the way the carrier modeled the
network and circuit inventory, NETSMART 1500
was required to manage facilities and services in
a hierarchical manner, with dependencies among
the layers. Further, the carrier required that
NETSMART 1500 discover Optical Multiplex
Sections (OMS) and report them over the MTNM
interface rather than report topological links. By
mutual agreement, each OMS was modeled as
a subnetwork connection (SNC). Once reported
to the OSS, the OMS was renamed by the OSS
to serve as the fundamental SNC layer in the
hierarchy of SNCs. The next layer modeled was
the Optical Channel (OCH) layer, representing
the end-to-end wavelength. SONET and
Ethernet services were modeled as SNCs carried
by the OCH layer. See Figure 3 for an example
of SNC modeling implemented by this carrier.2)
In this application of MTNM, the carrier’s
OSS selected the route for all OCH SNCs and
provided an explicit route to the NETSMART
1500 EMS as part of the SNC createAndActivate
request. Routes were specied as a set of
OMSs.2)
The carrier also preferred non-standard
naming conventions. The MTNM standard denes
a fully qualied name for each object. This name
is typically set by the EMS using well-dened
conventions, and is guaranteed to be unique. Each
object also contains the attributes “userLabel”
and “nativeEMSName.” The intent is to use
the standard name for all interface operations,
and to use userLabel or nativeEMSName when
interface information must be mapped to vendor
identiers or presented to a human user. A
subnetwork connection is named relative to
the EMS and subnetwork in which it exists
(the containment relationship), with the SNC
identier being a unique name for the connection
or circuit. Often the userLabel for an SNC is set
by the OSS/NMS and contains a circuit identier
known to the OSS/NMS inventory system using
naming conventions dened by the carrier. In
the case of this customer, however, the OSS set
both the SNC name and the userLabel, using the
same identier for each. Similarly, the carrier
requested that equipment names not follow strict
MTNM naming, but rather use a vendor-specic
equipment name as the last portion (i.e. slot or
sub-slot) of a fully qualied name. In this case,
the vendor equipment name was the TL1 Access
Identier (AID). Thus, rather than following the
MTNM convention of naming slots from right to
left, numbered 1…n, we used an alphanumeric
TL1 slot AID.2)
The rationale for use of non-standard naming
was to allow human users to easily identify objects
managed by the interface, particularly when
there were interface failures requiring analysis
of log les. In practice, it does appear that this
WDM
OMS
WDM
OMS
ILA ILA ILA
ROADM REGEN ROADM
OMS SNC OMS SNC
PTP CTP
OCH107
WCH
OCH SNC
WDM
OMS
WDM
OMS
ODU1
OCH107
WCH
ODU1
OC48 SNC
Physical link
ODU1 ODU1
FTP
OC48
MUX OC48
MUX
Figure 3
SNC layers in DWDM network.
427
FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
convention simplies interface operations but
it requires the OSS/NMS systems to maintain
vendor-specic equipment models.
4.2 Carrier #2
A second carrier deploys a multi-vendor
transport network for which Fujitsu supplies
a variety of equipment. This carrier had been
using the NETSMART 1500 EMS for several
years before initiating a multi-vendor operations
automation project using the MTNM interfaces.
As with Carrier #1, this carrier automated
fault management reporting and service
activation using the MTNM interface and it uses
the FTP interface for PM data collection.
Carrier #2 had a signicantly more
complicated network in terms of the variety
of services and deployed network elements. In
addition, the network had been provisioned
manually for several years, necessitating a
lengthy multi-phase conversion of pre-existing
circuit records into MTNM subnetwork
connections.
This carrier maintained a hierarchical
inventory of circuits and facilities, and preferred
that these relationships be modeled over the
interface. Since the carrier had a deployed
network, several months were spent identifying
the existing network congurations and circuit
designs to ensure correct modeling. The following
SNC layers were supported over the interface:
• OMS (Optical Multiplex Section)
• OCH (Optical Channel)
• Line (OC192LINE, OC48LINE, etc.)
• STS (STS1 or concatenated STSs)
• VCAT (virtual concatenation of STSs for
carrying Ethernet services)
Unlike the previous carrier, this carrier’s
OSS dened the route for all SNCs, including
OMS layer SNCs. SNC routes other than those
at the OMS layer were specied to NETSMART
1500 by listing the SNCs they were supported by.
See Figure 4 for an example of how SNCs are
referenced in an SNC creation request.3)
The SNC hierarchy modeled in the cases of
both carriers creates a dependency among SNCs.
In other words, an OMS SNC must exist prior to
the creation of an OCH SNC that is carried by
it; an OCH SNC must exist prior to the creation
of an OC48 SNC; and so forth. While there are
advantages to modeling and maintaining these
relationships in the EMS, it makes it difcult
to migrate pre-existing circuit data. Prior to
deployment of this interface, the NETSMART
1500 EMS and the carrier OSS underwent a
process to convert pre-existing circuit data into
SNCs. In order to properly create the layered
model, SNCs at the lowest layer (i.e. OMS) were
migrated rst and higher layer SNCs were built
on top of them. Although the carrier used well-
dened conventions for designing and naming
circuits, the pre-existing circuits were manually
created in the OSS and contained inconsistencies
that made data conversion difcult and time
consuming. However, once the data was
successfully converted, automated provisioning
of new circuits worked well.3)
Unlike Carrier #1, this carrier used the
standard naming convention for managed
objects. However, there were other complexities
arising from the variety of circuits in the network
and the way they were modeled by the OSS. The
model for each of these circuit types was agreed
upon between NETSMART 1500 and the OSS
provider. Examples of circuit variations included
non-contiguous circuits (i.e. circuits that
originated and terminated on Fujitsu equipment
with non-Fujitsu equipment in the middle); direct
connect circuits (i.e. circuits that were supported
over a logical or physical ber connection
between two NEs); and partial circuit protection.
This carrier also chose to create topological links
using the NBI rather than have them manually
or automatically created in the EMS and reported
to the OSS.
Although the automation of service
activation required careful planning and a
number of pair-wise agreements, automation
428 FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
of fault reporting and PM data collection was
relatively straightforward to implement and
deploy.
4.3 Carrier #3
A smaller carrier with a number of regional
networks has invested little in automating
inventory management, service provisioning or
service activation. This is probably because it has
traditionally operated each region as a separate
network. As this carrier centralizes decision
making and strategies at the corporate level, it is
beginning to focus on operations automation. The
rst area of automation has been fault reporting.
This carrier integrated fault reporting using the
NETSMART 1500 SNMP northbound interface.
SNMP is the most commonly used protocol in this
customer segment, and easily integrates with
commercially available OSS/NMS applications.
In addition, it is simple to utilize and can be
implemented by the customer with little or no
assistance from Fujitsu.
Strategically, this customer is interested
in automating network inventory reconciliation
using the XML-based MTOSI interface. In the
near term, however, it is performing this function
by exporting inventory data periodically from
NETSMART 1500 and comparing it with its
inventory data using simple tools.
5. Observations
In general, it is easier to develop and deploy
interfaces to support fault reporting and PM
data collection than it is to develop and deploy
OC192LINE
OC192LINE SNC OC192LINE
OCH OCH
OCH SNC
OMS SNC
OMS OMS
SONET
neA
Transponder
neB
DWDM
neC
DWDM
neD
Transponder
neE
SONET
neF
Figure 4
SNC Create Data for OC192LINE SNC.
SNCCreateData_T Structure
Attribute Name Value
userLabel DWDM/OCH/neA/neF/circuit1
forceUniqueness FALSE
owner
direction CD_BI
ProtectionLevel UNPROTECTED
protectionEffort
rerouteAllowed RR_NO
networkRouted NR_NO
sncType ST_SIMPLE
layerRate 28
ccInclusions <aEnd and zEnd cross connects>
neTpInclusions EMS=FujitsuFederation;multiLayerSubnetwork=NETSMART1500;subnetworkConnection=ne
B-to-neE-OCH
fullRoute TRUE
neTpSncExclusions
zEnd EMS=FujitsuFederation;ManagedElement=neA;PTP=/Shelf=1/slot=1/port=OC192-1;CTP=/line192
ms64=1
aEnd EMS=FujitsuFederation;ManagedElement=neF;PTP=/Shelf=1/slot=1/port=OC192-1;CTP=/line192
ms64=1
additionalCreationInfo
429
FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
interfaces to support service activation. This is
true whether TMF standard interfaces are used
or not. Although service activation automation
provides signicant benets in terms of reducing
the time and cost of offering new services, it
can require systems engineering and pair-
wise agreements between EMS and OSS/NMS
providers. Below are specic areas of service
activation automation that required particular
attention in our implementation.
5.1 Network resource naming
One of the benets of the MTNM standard is
that it denes a standard naming hierarchy that
is descriptive without being vendor-specic. It is
designed to allow OSS/NMS systems to recognize
and manage network resources (e.g., slots, ports,
bandwidth) and to identify them unambiguously
without having to understand vendor-specic
conventions. Unfortunately, it does not appear
that existing OSS/NMS systems are able to take
advantage of this abstraction. Our experience has
been that carriers rely heavily on circuit design
systems that model vendor equipment in detail.
It is not clear whether this is an artifact of older
operations architectures, or whether there is a
need for vendor-specic information at the OSS/
NMS layer. In either case, the MTNM standard
naming is not as useful as it could be, and in fact,
necessitates mapping to vendor-specic models
at each layer.
In the case of Carrier #1, the naming was
modied to better align with vendor-specic
equipment names. In practice, this made it
easier for users of the interface, especially when
troubleshooting provisioning errors. In contrast,
Carrier #2 used standard names in its inventory
OSS, its service activation OSS, and over the
interface. This reduced the need for mapping
among systems, but made it more difcult for
operations personnel to analyze error logs and
resolve provisioning errors.
5.2 Circuit and facility modeling
The MTNM standard allows SNC creation
and activation requests to be specied in a
number of ways. The options include specifying
the circuit termination points (i.e. circuit source
and sink) so that the EMS or the network can
determine the route, or specifying each of the
termination points and cross connects (used
when the NMS determines the route). While it
is possible to use the MTNM standard IDL to
specify a circuit route by reference to one or more
SNCs, as was done in our implementations, this
usage was not envisioned when the standard was
developed. The layered approach necessitates
SNC creation dependencies, but allows the EMS
to model circuits and facilities in the same way
the OSS/NMS system does and allows the EMS
user to see relationships among circuits.
5.3 Brownfield networks
If service activation automation is
introduced in a network that has been deployed
for a period of time and is carrying a service (a
“browneld” network), then a data migration step
may be required prior to interface activation. Data
migration is necessary when the EMS is required
to have a record of all existing circuits; when the
SNC model differs from, or is incompatible with,
other circuit models; or when the circuit model is
hierarchical. The data migration phase requires
that each existing circuit or facility be modeled
as an SNC, imported into the EMS, and matched
to existing network resources (termination points
and cross connects).
6. Conclusions
There is no doubt that standard interfaces
are preferred over proprietary interfaces, simply
because they provide a framework for interface
denition and facilitate software reuse.
In addition, it appears that an OSS
architecture utilizing the EMS layer does reduce
cost and improve efciency when offering new
services. Not only does the EMS layer insulate
430 FUJITSU Sci. Tech. J., Vol. 45, No. 4, (October 2009)
D. Provencher: Operations Automation Using NETSMART 1500 Element Manager
the OSS/NMS layer from vendor-specic
interface variations, it also provides an effective
means of distributing software analysis and
development tasks between the carrier and the
vendor. The carrier can focus on identifying new
services to be offered while the vendor can focus
on the requisite provisioning details. Jointly
they can determine how the services are best
modeled over the interface. In our experience,
NETSMART 1500 support for a new NE release
was commercially available at the same time the
NE was available. The corresponding OSS/NMS
was available slightly later and the carrier was
able to deploy new services within six months of
NE availability.
A nal advantage of utilizing an EMS
layer with standard interfaces is the additional
exibility it provides to the carrier. We have
seen cases where OSSs are limited in their ability
to model new services cost effectively due to the
age or architecture of the system. By relying on
service abstraction as provided by the MTNM
and MTOSI interfaces, and pushing complexity
to the EMS layer, these services can be offered
with the same level of automation as existing
services.
The TMF standard interfaces have proved
they can support the technologies and services
used by our customers. Based on our experience,
however, the following warrant future
consideration:
• Use of a at rather than layered SNC
model—Use of a at model would eliminate
dependencies among SNCs that complicates
both provisioning and data migration.
While provisioning dependencies will exist
in the network, removal of the relationship
among SNCs would allow certain layers to
be provisioned manually (e.g., OCH layer)
so that automation can be focused on layers
with the greatest volume. In addition, it
has the potential to simplify or obviate data
migration requirements.
• Use of EMS-directed or network-directed
routing—While not discussed directly
in this paper, a great deal of pair-wise
agreements arise when the OSS/NMS
provides an explicit circuit route composed
of termination points and cross connects.
Reliance on vendor components, whether
EMS or NE, to determine circuit route and
details, could simplify the interface and lead
to further efciencies.
In summary, the NETSMART 1500 EMS
has successfully automated operations tasks
using a variety of NBIs. Fault management
and performance management applications are
supported easily with standard or well-dened
interfaces. Service provisioning and activation
applications require more effort from both carrier
and vendor, but have resulted in improved
operations efciency.
References
1) TMF814 MTNM IDL Solution Set. Version 3.5;
IDL and Supporting Documents, August 2008.
2) J. Liu: NETSMART 1500 TMF MTNM V2.1 NMI
Specication. Revision 01.02, Document No.
PCA-11360-DOC.
3) V. Sethi: NETSMART 1500 TMF MTNM V2.1
NMI Specication. Revision 01.01, Document
No. PCA-11359-DOC.
Denise Provencher
Fujitsu Network Communications Inc.
Ms. Provencher received a B.S. degree
in Finance from Syracuse University
and worked for AT&T and Telcordia
designing and developing operations
support systems for North American
carriers. She joined the Product
Planning organization of Fujitsu
Network Communications in 1996 and
is currently the Director of Element
Management Products, responsible for the NETSMART 1500
network management system.
