White Paper

NGOSS Management
Solution
Jerome Simms,
August 2004
Abstract
This document will provide a brief introduction to the
TeleManagement Forum’s NGOSS (New Generation
Operations Software and Systems) program and explain
how CA’s Network Fault Management (SPECTRUM®)
solution maps to NGOSS. It is intended to be a guide for
anyone tasked with making technology decisions for
network and service management within the service
provider marketplace.
Introduction
What is the TeleManagement Forum?
The TeleManagement Forum (TM Forum) is a non-profit
global organization that provides leadership, strategic
guidance, and practical solutions to improve the
management and operation of information and
communications services. Its open membership of more
than 350 companies comprises incumbent and new-
entrant service providers, computing and network
equipment suppliers, software solution suppliers, and
customers of communications services.
Since 1988, the TM Forum has provided successful real-
world solutions to many business and technology
challenges born from the global telecom deregulation and
the growth of IP-related services. Dedicated to overall
excellence in communications and information services
management and to solving pressing Operations Support
Systems/Business Support Systems (OSS/BSS)
integration issues, the TM Forum and its member
companies collaboratively identify, create, develop, and
implement real-world solutions that automate and
streamline information and communication operations.
Within the TM Forum, industry leaders tackle issues of
interoperation and process automation that they could not
address as cost-effectively or comprehensively on their
own.
All of the TM Forum’s activities are geared to facilitate the
search for common solutions to the information and
communications services industry’s most pressing
operational needs.
The TM Forum’s vision is “to be universally recognized as
the leader and enabler for automating operational
management and business process within the global
communications industry and related supply chains by
advancing the available technologies and solutions.”
2
What is NGOSS?
NGOSS is a work program governed by the TM Forum.
NGOSS is the industry’s only true standard for
development and deployment of easy-to-integrate,
flexible, easy-to-manage OSS/BSS components. NGOSS
defines for service providers and their suppliers a
comprehensive, integrated framework for developing,
procuring and deploying operational and business support
systems and software. NGOSS is provided as a set of
documents that make up a toolkit of industry-accepted
specifications and guidelines that cover key business and
technical areas, and a defined methodology for use of the
tools. NGOSS uses a “lifecycle” approach to development
of management systems, based on clear definition of
business processes, specification and architecting
software and systems to automate those processes, and
compliance of those systems against NGOSS test criteria.
The aim of the NGOSS program is two-fold: to deliver a
framework that will help produce New Generation
OSS/BSS solutions, and to be a repository of
documentation, patterns, models, and code in support of
these developments. In this context, “framework” means
an architecture and methodology which can support
business, system, and implementation views of OSS and
BSS component-based solutions. The goal of NGOSS is to
facilitate the rapid development of flexible, low-cost-of-
ownership OSS/BSS solutions to meet the business needs
of the Internet-enabled economy.
NGOSS targets the use of commercial off-the-shelf
information technologies, instead of technologies unique
to the telecommunications industry, as many legacy
management systems have done in the past. This
approach significantly reduces costs and improves
software reuse and operational flexibility, enabling
NGOSS-based systems to support a range of new services
and new technology environments more easily. NGOSS
emphasizes a service-oriented approach based on
integration of well-defined collaboration contracts.
The NGOSS architecture is described using technology-
neutral constructs. These include concepts taken from the
Reference Model for Open Distributed Processing (RM-
ODP) as well as extensions to the basic Unified Modeling
Language (UML) metamodel to represent fundamental
NGOSS concepts and principles. It does not prescribe a
single new technology—rather, it allows for a federation of
different technological approaches, each of which offers
particular advantages at the business and system levels.
An NGOSS solution design specification may be
implemented using currently available distributed systems
information technologies or technologies that are yet to
be defined. Critical to this process is the defining, sharing,
and reusing of common information and data, as this
provides a common vocabulary and understanding of both
business and system concepts used for analyzing the
structure and behavior of a desired OSS/BSS solution.
This is done using the Shared Information and Data (SID)
model, which is designed as a set of UML models that
cover various views of domain information.
What are the Components of NGOSS?
The elements of NGOSS fit together to provide an end-to-
end system for OSS/BSS development, integration, and
operations. The elements of NGOSS may be used as an
end-to-end system to undertake large-scale development
and integration projects, or may be used separately to
solve specific problems. The elements of NGOSS are as
follows:
Enhanced Telecom Operations Map® (eTOM)
The eTOM provides the map and common language of
business processes that are used in Telecom Operations.
In addition, process flows are provided for an ever
expanding list of key processes. The eTOM can be used to
inventory existing processes at a service provider, act as a
framework for defining scope of a software-based
solution, or simply enable better lines of communication
between a service provider and their system integrator.
Shared Information/Data Model (SID)
The shared information and data model provides a
“common language” for software providers and
integrators to use in describing management information,
which will in turn allow easier and more effective
integration across OSS/BSS software applications
provided by multiple vendors. The SID provides the
concepts and principles needed to define a shared
information model, the elements or entities of the model,
the business-oriented UML class models, as well as
design-oriented UML models and sequence diagrams to
provide a system view of the information and data.
Technology-Neutral Architecture and Contract
Interface
These two components make up the heart of the NGOSS
integration framework. In order to successfully integrate
applications provided by multiple software vendors, the
“plumbing” of the system must be common. The
Technology-Neutral Architecture defines architectural
principles to guide OSS/BSS developers to create
OSS/BSS components that operate successfully in a
distributed environment; and the Contract Interface
defines the “API” for interfacing those elements to each
other across the architecture. This architecture is
3
specifically called “Technology-Neutral,” as it does not
define how to implement the architecture, but rather what
principles must be applied for a particular technology-
specific architecture to be NGOSS-compliant.
NGOSS Compliance
In order to improve the probability that OSS/BSS
components will truly integrate with each other, NGOSS
provides a suite of tests for compliance to the eTOM, SID,
architecture, and contract interface components. NGOSS
compliance can be achieved by any or all of these
components either singly, or in combination with other
components.
Who Needs NGOSS?
Across the telecommunications supply chain, OSS/BSS has
solved many problems, but is presenting many challenges
looking ahead to the future. Each of the major players in the
supply chain is seeking a new approach to OSS/BSS, and in
each case, there are compelling reasons to do so.
Service Providers
In the financially sensitive markets of today, service
providers need cost-effective OSS/BSS implementations.
OSS/BSS systems must automate complex business
processes to solve operational issues in the short-term,
and show rapid returns for the investment. In addition,
service providers require a long-term strategy for their IT
systems. The OSS/BSS systems in many carriers today
were put together without a long-term view, and are now
proving difficult to expand to handle the challenge of
managing more complex networks, services, and
automated processes.
OSS/BSS Software Vendors
The OSS/BSS vendor marketplace has blossomed to over
400 companies. This expansion means that in each
market sub-segment, numerous companies are competing
for the same business within the service provider
community. This competition, along with price pressure
from the service providers, is driving software vendors to
reduce development costs to be profitable. In addition, the
OSS/BSS marketplace has become a conglomeration of
companies who solve niche problems for the service
provider. As a result, software vendors must be prepared
to fit into the OSS/BSS puzzle presented to them by each
service provider customer they engage.
System Integrators
While custom integration projects are typically the boon of
telecom system integrators, mounting pressure from the
service providers to cut costs puts the system integrators into
a position where they must make their projects more
predictable and repeatable—less custom—to retain margins.
System integrators are looking to reuse elements across
projects and use fewer staff members to accomplish their end
results. In addition, with the large number of software suppliers
in the industry and service providers using an ever-increasing
variety of software components, system integrators are forced
to continually learn how to integrate new elements into the
service providers’ IT environments.
Network Equipment Vendors
Equipment vendors are extremely influential in the world of
OSS/BSS. Often, service providers rely on the management
systems from their preferred vendors to do much more than
manage their own network elements. And often, equipment
vendors see the value in becoming a one-stop shop for their
customers, offering a broad range of OSS/BSS solutions. In
addition, network equipment vendors are often faced with
bidding situations where they are putting their equipment into
a pre-existing multivendor environment with established
OSS/BSS. In all these cases, providing NGOSS-based solutions
enables the ability to integrate their hardware and systems
with third-party NGOSS-enabled systems quickly and easily,
deriving substantial business benefits.
What are the Business Benefits of NGOSS?
Process automation is the cornerstone of NGOSS. Many of
the business benefits revolve around the direct and indirect
stages in automating telecom operations. But service
providers are not the only beneficiaries of the standard
language and specifications that NGOSS defines.
NGOSS offers service providers tangible business
benefits that positively impact the bottom line:
• Having a well-defined long-term direction for business
processes and OSS/BSS implementation reduces
investment risk. When new systems and services are
purchased, if they fit in with a well-defined strategy and
detailed set of requirements, their longevity is more
assured than in an environment with looser definition.
• Being first to market is important in competitive
environments. Being first to market and not spending a
lot of money to be there is a recipe for success. Being
nimble is key to preparing for the combined broadband
and wireless services onslaught that is approaching.
4
• Moving to an environment where process definitions,
interfaces, and architecture are all standard allows for a
truly competitive bidding environment.
NGOSS delivers measurable improvements in
development and software integration environments:
• With NGOSS, big chunks of process language,
requirements, data models, interfaces and tests are
already defined, significantly reducing development costs.
• Using standard building blocks, software modules and
even whole products can be built once and sold many
times, increasing return on investment with every sale.
• Integration cycles for software with standard interfaces
are significantly shorter, reducing the cost of bringing a
new software system into an existing environment. In
addition, integration using NGOSS interfaces becomes
a repeatable process, saving time and money on each
project and improving success rates.
• Definition of use cases and requirements becomes
easier across service providers/supplier and
supplier/supplier partnership relationships when a
common language as provided by the eTOM and the
SID is used to communicate.
On-going savings appear in the operational environment
with the daily churn of tasks, to keep networks running and
customers satisfied:
• Automation enables lower operational expenditure.
With NGOSS, tackling the task of introducing
additional automation to an operational environment
comes with a blueprint to follow and guidelines to step
through the changes. The task may still be large, but
much of the work has been done within the NGOSS
elements.
• Once automated systems are in place, making
changes in a well-designed, well-understood
environment is straight-forward. Reacting to a need to
change a service offering, a billing option, or a quality
of service requirement becomes an easy-to-follow
process rather than significant changes that require
weeks of testing.
The NGOSS Framework — How
CA’s Network Fault Management
(SPECTRUM®) Solution Fits
The NGOSS program consists of a set of business and
technical activities that are aimed at defining a New
Generation OSS/BSS, and showing how it can be
implemented. Figure 1 shows conceptually how different
parts of the NGOSS Framework fit together.
Figure 1: Conceptual Overview of the NGOSS Framework
others within the telecommunications industry. The TM
Forum eTOM describes all the enterprise processes required
by a service provider and analyzes them to different levels of
detail according to their significance and priority for the
business. For such companies, it serves as the blueprint for
process direction and provides a neutral reference point for
internal process re-engineering needs, partnerships,
alliances, and general working agreements with other
providers. For suppliers, eTOM outlines potential boundaries
of software components to align with the customers’ needs,
and highlights the required functions, inputs, and outputs
that must be supported by products.
The eTOM Business Process Framework represents the whole
of a service provider’s enterprise environment. The Business
Process Framework begins at the enterprise level and defines
business processes in a series of groupings. The framework is
defined as generically as possible so that it is organization-,
technology- and service-independent, and supports the
global community. At the overall conceptual level (see Figure
2), eTOM can be viewed as having the following three major
process areas:

• Strategy, Infrastructure, and Product — covering

planning and lifecycle management

• Operations — covering the core of operational

management

• Enterprise Management — covering corporate or

business support management

Business Process Automation

TM Forum Description Figure 2: eTOM Business Process Framework

An NGOSS system is characterized by

the separation of the hard-coded
behavior of components from the software that automates
business processes across the components — e.g., an
NGOSS system should be composed of defined services
that can be orchestrated using scripting/process
management technologies. An NGOSS system is further
characterized by external descriptions of behavior
expressed in a technology-neutral manner.

Process management is the application of modern

business management techniques to business processes.
This includes techniques for defining, measuring,
analyzing, testing, and deploying business processes as
well as executing them. All of these activities form a part
of business management, and so must contribute to the
goal of improving business results for telecommunications
service providers.

The Enhanced Telecom Operations Map® (eTOM) is the

ongoing TM Forum initiative to deliver a business process
model or framework for use by service providers and

5
How CA’s Solution Supports
Business Process Automation
With services and SLAs being direct sources of revenue for
service providers and the basis of business processes in
enterprises, they must be managed effectively to ensure
quality services are delivered and SLAs are met. It is no
longer acceptable to provide component-level management
of the network, applications, systems, or security in
separate silos. In order to do this, the IT staff needs real-
time alarms on services as well as SLAs that are in danger of
violation. These alarms must provide the root cause and the
impact analysis to allow them to be addressed quickly and
in order of priority. Finally, they must have the ability to
report on both service performance and SLA compliance.
Figure 3: The Operations End-to-End Process Breakdown
CA’s Network Service Manager application manages
services, customers, and SLAs in order to provide the
required quality of service and ensure success.
The Network Service Manager application focuses on the
Assurance Processes within eTOM, as this eTOM process
grouping is responsible for the execution of proactive and
reactive maintenance activities to ensure that services
provided to customers are continuously available to SLA or
QoS performance levels. It performs continuous resource
status and performance monitoring to proactively detect
possible failures. It collects performance data and analyzes
it to identify potential problems and resolve it without
impact to the customer. This process manages the SLAs and
reports service performance to the customer. It receives
trouble reports from the customer, informs the customer of
the trouble status, and ensures restoration and repair, as
well as a delighted customer.
6
Customer QoS/SLA
Management
Customer QoS/SLA Management
processes encompass monitoring,
managing and reporting of delivered vs. contractual
quality of service (QoS), as defined in the enterprise’s
service descriptions, customer contracts or product
catalogue. They are also concerned with the performance
of the enterprise and its products and services in relation
to its SLAs for specific product instances, and other
service-related documents.
Retention and Loyalty
Retention and Loyalty processes deal with all functions
related to the retention of acquired customers, and the
use of loyalty schemes in the potential acquisition of
customers. They establish a complete understanding of
the needs of the customer, a determination of the value of
the customer to the enterprise, determination of
opportunities and risks for specific customers, etc. These
processes collect and analyze data from all enterprise and
customer contacts.
The management server delivers fault detection,
diagnosis, and root cause analysis to pinpoint a variety of
IT infrastructure problems that can affect customer
services. The Network Service Manager works
cooperatively with the management server, with a specific
emphasis on service and SLA management. The Network
Response Time Manager application provides QoS
monitoring, and finally the Network Asset and Availability
Reporting, and Network Data Manager applications both
collect and report on a variety of IT operational metrics
including, but not limited to, service performance and SLA
violations. This knowledge also allows for the validation of
customer satisfaction.
Service Problem Management
The purpose of the Service Problem
Management processes is to respond
immediately to customer-affecting
service problems or failures in order to minimize their effects
on customers, and to restore the service, or provide an
alternate service as soon as possible. They encompass the
reporting of problems, making a temporary fix or work-around,
isolating the root cause, and finally recovering the complete
functionality of the service and providing information for future
enhancements.
Service Quality Management Resource Trouble Management
The purpose of the Service Quality Management processes Resource Trouble Management
encompass monitoring, analyzing and controlling the processes are responsible for the
performance of the service perceived by customers. These management of troubles with allocated
processes are responsible for restoring the service performance resources. The objectives of these processes are to report
for customers to a level specified in the SLA or other service key resource failures, isolate the root causes and act to resolve
quality indicator (KQI) descriptions as soon as possible. them.

Once a problem has been detected and diagnosed to a root The management server delivers resource fault identification
cause, this information is presented to the operations team using and detection, and root cause analysis by leveraging a variety
a variety of integrated mechanisms. The Network Alarm of 100 patents. Event and alarm correlation are core
Notification Manager application and Network OneClick user components, as well as integrated impact analysis. The
interface provide real-time notification and assignment of management server also enables the tracking and
problems based on a variety of alarm metrics. The Alarm Notifier management of resource problems and alarms through its
or Network Alarm Notification Manager application can be used Desktop and Web-based Alarm Management Consoles, which
to forward or escalate this knowledge (problem cause, impact provide both real-time resource alarms and historical reports.
assessment, and recommended corrective actions) to
operational personnel or systems responsible for service
restoration. Both applications are policy-based to ensure that
Figure 4: SPECTRUM® Patent Timeline
information is assigned or forwarded to the appropriate person
or system in the timeliest manner. These applications also allow
problems to be closed and reports to run to view historical
problem chronology.
1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003

Resource Provisioning
Resource Provisioning processes
encompass allocation and configuration of
resources to individual customer service
instances in order to meet the service requirements. This
includes activation as well as testing to ensure the expected
performance of the service.

The Network Configuration Manager application addresses

configuration management by enabling infrastructure, network,
and device change management, and supports the process of
identifying, controlling, and monitoring all managed resources
that comprise a communication network (where a managed
object is any element modeled by CA’s software). Network
Configuration Manager allows for configuration activation of
physical and/or logical resources by enabling resource
configurations to be captured, edited, updated, and restored.
Resource configurations can be automatically compared and
validated to ensure the resource is working correctly. The
resulting benefits include:
• Increased infrastructure and service uptime by
reducing the time to resolve problems and restore
service
• Lowered support costs by reducing the occurrence of
service-affecting issues that require reactive
troubleshooting and fixes
• Lowered operational costs by reducing the time to
administer and implement system-wide changes
Resource Performance Management
Resource Performance Management processes encompass
monitoring, analyzing, controlling and reporting on the
performance of resources. They work with basic information
received from the Resource Data Collection and Processing
processes.
Resource Data Collection and Processing
Resource Data Collection and Processing processes interact with
the resources to collect usage, network and information
technology events, and performance information for distribution
to other processes within the enterprise. The responsibilities also
include processing the data through activities such as filtering,
aggregation, formatting, and correlation of the collected
information before presentation to other processes.
The management server, along with the Network Service
Manager, Network Response Time Manager, Network Asset and
Availability Reporting, and Network Data Manager applications
are the foundation of resource performance management, as

7
well as resource data collection and processing capabilities.
They collect and monitor, process and analyze, and then report
and forecast performance problems. These applications deliver
real-time notification of threshold violations, and they can
perform continuous monitoring of the resources using
scheduled performance tests. They maintain performance
baselines to deliver real-time threshold alarms as well as
leverage baseline information for capacity planning, trend
analysis and forecasting. The applications also have built-in
error-handling and fault tolerance to ensure the integrity of the
data being collected.
Shared Information and Data
Model (SID)
TM Forum Description
An NGOSS system is characterized by the
usage of a common information model for enabling
communication, integration and interoperability. The SID is
designed to be more than just a standard representation of data—
it also defines semantics and behavior of, and interaction between,
managed entities. This set of information models, all provided in a
standard representation using standard data types, is used to
describe domain information (i.e., customers, orders, network,
service and configuration definitions) in an NGOSS system. The
SID, expressed in UML, additionally represents information that
can be shared and/or reused by NGOSS components. It thus fully
represents the information viewpoint of NGOSS. The SID supports
business, system, and implementation views, thereby enabling
different constituencies taking on different roles to concentrate on
the set of related information entities of particular interest or
concern. Complementing the eTOM’s process framework, the SID
focuses on the things that are involved in business processes,
people, assets, products and services.
Figure 5: SID Information Modeling (NGOSS Release 4.0)
8
CA’s Semantic Data Model and NGOSS’ SID
CA’s Network Fault Management Semantic Data Model
(SDM) is our mature definition of information infrastructure
for the software management knowledge-base. This model has
been improved and enhanced to its current form over the past
10 years to allow flexibility and commonality with other
information infrastructures. All managed entities (e.g.,
resources, services, SLAs, customers…) exist as a model within
the software’s modeling system. This is enabled by the use of
the Semantic Data Model. The SDM is one of the main
components of the Network Fault Management solution’s core
service, and is referred to as the knowledge-base. The
knowledge-base is comprised of both the data and the
procedural information necessary to manage the IT
infrastructure. The knowledge-base has a component that
stores model types, relations, models, and event and statistical
information. The knowledge-base uses a sophisticated system
of models and relationships between models to represent and
store information about the elements of the managed
infrastructure. In essence, this system of models and the
relationships between them, when viewed as a single logical
entity, describes the infrastructure’s physical and logical
topology.
The Network Fault Management solution builds its root cause
analysis capabilities on this foundation. All models in the
knowledge-base are based on templates known as model
types. Model types define the properties and behavior that
make up an instantiated model. All model types are stored in
the knowledge-base’s modeling catalog. The knowledge-base
also contains processes that provide model types with
intelligence. These processes are known as “inference handlers
and actions.” Data generated from or used to support these
processes is stored in memory while the management server is
running, and is also part of the knowledge-base. Both SDM and
SID share remarkably similar concepts of information
organization. CA believes the SID model is similar enough to
our SDM that should the need arise to share data between
applications that use the two information models, using the
available toolkits, such an integration could be achieved.
Additional information about the Semantic Data Model can be
found in the SPECTRUM Concepts Guide.
Security Model
TM Forum Description
An NGOSS system should be designed
according to an overarching security
model. An implementation of an NGOSS system will require
the setup and operation of one or more security mechanisms
and policies in order to operate the NGOSS system in a
secure manner. To this end, NGOSS uses the security
provisions defined by the ISO 17799 Information Security
Management standards. This provides a framework to
manage and operate an NGOSS system to meet the
security objectives of an operating company. Additionally,
the Common Criteria are used as an additional security
reference framework.
CA’s Network Fault Management Security Model
The Network Fault Management solution employs a
comprehensive security model to prevent unauthorized
access and editing of the various management views and
managed elements in its knowledge-base. Using these
security measures and additional applications, the
solution can also prevent unauthorized changes to the
real-world network devices under its managed control.
CA’s Network Fault Management security does not replace
the current network security system, but rather
complements and will “cooperate” with an overall network
or NGOSS security system. It provides security
mechanisms that extend the security provided by the
UNIX or Windows platforms. These machines establish:
• Areas in the network model that users may examine or
view
• Existing attribute values that users may update
• Existing models and views that users may edit
The following terms describe concepts that are the
foundation of the Network Fault Management security.
Security Community
In this solution, security communities provide a
mechanism for grouping views and network models to
control access. Access to a security community is
determined by comparing a model’s Security String to a
user’s Community String.
Security String
Defines the requirements for access to managed elements
that each user can have. Security strings are assigned to
models. Each security string consists of one or more
security community entries.
Community String
Defines security communities to which a user is permitted
access and establishes edit privileges within them.
Community strings are assigned to users. Each entry
defines one or more specific security communities and the
access privilege level (i.e., view-only, or view and edit)
associated with each.
9
Additional details on the Network Fault Management
security model can be found in the Security and User
Maintenance Guide.
Policy Model
TM Forum Description
The NGOSS architecture
recommends the use of policy
mechanisms for defining and managing the behavior of
NGOSS elements. Policy-based management is defined as
the usage of policy rules to control the state of the system,
and managed objects within that system. NGOSS uses the
Directory Enabled Networks New Generation (DEN-ng)
policy model. DEN-ng was specifically constructed to bind
information and data models to management
architectures. As networks become larger and more
complex, creating policies for them has become a crucial
step in the management of network systems.
Policy-based Management with CA’s Solution
CA’s Network Fault Management solution is a multi-faceted
application that makes use of various configuration options to
control the behavior of the application and how it manages the
IT infrastructure and the services that run over it. Customers
use these configuration options to implement pre-defined
management policies. Out-of-the-box, the solution comes pre-
configured with various configuration settings of attributes,
thresholds and policies that represent our domain knowledge
in infrastructure management “best practices.” Using various
applications, these configuration settings, thresholds and
policies can be changed by the administrator such as to affect
an individual managed element, entire classes of managed
elements, arbitrary user-defined groups or the entire managed
system.
For purposes of an example, a “management policy” is defined
as a set of configuration settings and a set of models on which
to apply those settings. Today our Search Manager and Global
Attribute Editor are commonly used to implement
management policies.
Example of Policy-based management
Goal
• The user first needs to find all of the models on which
to apply the policy.
Methodology
• This can be achieved by using one of the
aforementioned out-of-the-box/pre-defined search
criteria, or by defining a custom search criterion. This
can be referred to as the “policy criteria”. Once the set
of device models matching the policy criteria is found,
the user can then use the Global Attribute Editor to
 apply a set of configuration settings to the group of
Figure 6: NGOSS Contract Using Shared Information
models. Each tab in the Global Attribute Editor can be
considered a “policy setting” (e.g., the attribute values
to set on the group of models).

• The user can use the view to set all attribute values,
and apply the changes to all models selected.

• User-defined “policy criteria” and “policy settings” can

be saved using the Search Manager. The user can
enforce these management policies by automating
periodic updates of these same steps to find new
models (or models whose attributes have changed)
upon which to apply the policy.

It is our practice to continually introduce new applications

and enhance the existing applications so that it remains
easy and intuitive to configure how our Network Fault
Management solution behaves on a broad scale, thereby
greatly decreasing the administrative burden of NGOSS Contract
maintaining network management policies.
In addition to the above frameworks and architecture artifacts,
the NGOSS contract is the fundamental unit of interoperability.
Basic Mechanisms
TM Forum Description A contract specifies three things:

These mechanisms provide the • A technology-neutral representation of an interface

baseline functionality which must be
implemented in any NGOSS deployment to provide for the
interworking between independently deployed
components and to support the “plug-and-work”
paradigm at the most fundamental level.
• The interaction of entities participating in the contract
• Constrained behavior of the entities participating in the
specified interaction

Communication Mechanisms Thus, the functionality of a service is made available through

An NGOSS system is characterized by the existence of a
communication mechanism (e.g., a messaging bus) or
some other form of common communication. All software
entities will use one or more communication mechanisms
to communicate with each other. Each communication
mechanism offers one or more different transport
mechanisms. There may be more than one such
communication mechanism within a given system
implementation, and these mechanisms may represent
different technology-specific mappings. The common
communication mechanism must provide transport
mechanisms consistent with the basic interaction styles
defined in the architecture, and support any security
policies that a service provider has defined for his/her
network. Most importantly, the use of a common
communication mechanism enables the standardization of
system-wide operations, messages, or events that can be
distributed to interested components. This is an important
point, as a transport just carries information, and by itself
doesn’t provide the required interoperability to support
New Generation OSS/BSS solutions.
a contract-defined interface, and when one or more services
engage in an interaction governed by the behavioral
constraints specified in the interaction contract. NGOSS
defines an interface as a named set of operations that
characterize the functionality offered by a service. The
arguments of an interface, as well as its behavior, are defined
using shared information entities to ensure interoperability.
From the graphic, it can be seen that at a minimum, a
contract is the specification of the interface to a service.
However, in order for a contract to be the fundamental
unit of interoperability it must specify more than simply an
interface, it must also define interaction semantics.
Communication with Other OSS/BSS
Applications and Systems
The Network Fault Management solution’s CORBA
Interface exists to provide a flexible standards-based
interface to:
• Quickly export data to third-party external systems
such as reporting, capacity planning, billing and
customer care

10
• Integrate with existing OSS/BBS solutions such as
Summary
provisioning systems NGOSS is the industry’s only true standard for
development and deployment of easy-to-integrate,
• Provide communication to gateways and proprietary flexible, easy-to-manage OSS/BSS components.
network resources elements
As an active member of the TM Forum, CA continues to
The CORBA interface provides language neutrality, monitor the development of the NGOSS framework.
allowing native Java or C++ applications to be developed Additionally, it is our intention to actively participate in
for and integrated with the Network Fault Management TM Forum technical programs and offer our expertise to
solution with similar ease. In CORBA, the component that the forum and to the industry.
supports interoperability between remote applications is
the Interface Definition Language (IDL). The IDL is used to
define an API. As an example, the Network Fault To Learn More
Management CORBA API consists of several IDL files, one To learn more about…
for each type of object. The IDL files define the interfaces
to discrete services with the management solution’s • TeleManagement Forum, NGOSS, and related work
knowledge-base. In addition to the IDL files, the CORBA programs, visit tmforum.org.
API consists of helper classes, examples, and
documentation. • Directory Enabled Networks New Generation (DEN-ng)
policy model, read the book “Policy-based Network
Finally, the CORBA interface is standards-based, highly Management: Solutions for the Next Generation”
refined and well documented; it is designed to make it written by John C. Strassner, ISBN/SKU 1558608591.
easier and faster to integrate with other systems. It is The book, published by Morgan Kaufmann, is available
essentially the integration “glue” that enables other at the publisher’s website, mkp.com, and
systems to exchange information with the knowledge- amazon.com.
base.

About the Author

Jerome Simms is a Development Architect for CA’s Enterprise Systems Management business unit.

Copyright © 2006 CA. All rights reserved. All trademarks, trade names, service marks and logos referenced herein belong to their respective companies. This document is for your informational
purposes only. To the extent permitted by applicable law, CA provides this document “AS IS” without warranty of any kind, including, without limitation, any implied warranties of merchantability,
fitness for a particular purpose, or non-infringement. In no event will CA be liable for any loss or damage, direct or indirect, from the use of this document, including, without limitation, lost profits,
business interruption, goodwill or lost data, even if CA is expressly advised of such damages. MP28911