The NGOSS Technology-

Neutral Architecture

TMF053

Version 5.7 November, 2006

TeleManagement Forum 2006
The NGOSS Technology-Neutral Architecture

Notice

No recipient of this document shall in any way interpret this document

as representing a position or agreement of TM Forum or its members.
This document is a draft working document of TM Forum and is
provided solely for comments and evaluation. It is not a Forum
Approved Document and is solely circulated for the purposes of
assisting TM Forum in the preparation of a final document in
furtherance of the aims and mission of TM Forum.

Although it is a copyrighted document of TM Forum:

Members of TM Forum are only granted the limited copyright waiver to

distribute this document within their companies and may not make
paper or electronic copies for distribution outside of their companies.

Non-members of the TM Forum are not permitted to make copies

(paper or electronic) of this draft document other than for their internal
use for the sole purpose of making comments thereon directly to TM
Forum.

If this document forms part of a supply of information in support of an

Industry Group Liaison relationship, the document may only be used
as part of the work identified in the Liaison and may not be used or
further distributed for any other purposes

Any use of this document by the recipient, other than as set forth
specifically herein, is at its own risk, and under no circumstances will
TM Forum be liable for direct or indirect damages or any costs or
losses resulting from the use of this document by the recipient.

This document is governed by all of the terms and conditions of the

Agreement on Intellectual Property Rights between TMForum and its
members, and may involve a claim of patent rights by one or more
TMForum members or by non-members of TMForum.

Direct inquiries to the TM Forum office:

240 Headquarters Plaza,
East Tower – 10th Floor,
Morristown, NJ 07960 USA
Tel No. +1 973 944 5100
Fax No. +1 973 944 5110
TM Forum Web Page: www.tmforum.org

TMF053, Version 5.7 TeleManagement Forum 2006 Page 2 of 96

The NGOSS Technology-Neutral Architecture

Table of Contents
Notice ..................................................................................................................................................................2
Table of Contents ..............................................................................................................................................3
List of Figures ....................................................................................................................................................5
List of Tables......................................................................................................................................................5
1. Introduction ....................................................................................................................................................6
1.1. Background......................................................................................................................................6
1.2. Goals and Objectives ......................................................................................................................7
1.3. The Road to NGOSS ......................................................................................................................7
1.4. Program Implementation.................................................................................................................9
1.5. Phases of Delivery and Roadmap..................................................................................................9
1.6. Stakeholders in this Document.......................................................................................................9
1.6.1. Document Use by a Service Provider ..................................................................................10
1.6.2. Document Use by a Systems Integrator ..............................................................................10
1.7. Document Use by an Independent Software Vendor .................................................................11
1.7.1. Document Use by a Network Equipment Provider..............................................................11
1.8. Organization of this Document .....................................................................................................12
2. Architectural Requirements.......................................................................................................................14
2.1. Related Work.................................................................................................................................14
2.1.1. TMF Views.............................................................................................................................14
2.1.2. RM-ODP Views .....................................................................................................................15
2.1.3. TMF Views and RM-ODP Viewpoints..................................................................................16
2.2. Distributed Interface Oriented Architecture..................................................................................17
2.2.1. NGOSS DIOA and Architectural Approaches .....................................................................19
2.2.2. Components ..........................................................................................................................21
2.3. NGOSS Architecture Requirements ............................................................................................22
2.3.1. Interface Definition.................................................................................................................23
2.3.2. Technology-Neutral Component Model ...............................................................................24
2.3.3. Separation of Business Process and Policy from Component Implementation ................26
2.3.4. Security-Enabled Architecture ..............................................................................................27
2.3.5. Policy-Enabled Architecture..................................................................................................27
2.3.6. Models, Shared Information and Data .................................................................................28
2.3.7. Distribution Transparency .....................................................................................................30
2.3.8. Compliance and Certification................................................................................................31
2.4. Separation of Technology-Neutral and Technology-Specific Architectures...............................32
3. Architectural Concepts...............................................................................................................................33
3.1. General Concepts .........................................................................................................................34
3.2. TNA Computational Aspect ..........................................................................................................35
3.2.1. Contract..................................................................................................................................36
3.2.2. Component ............................................................................................................................37
3.2.3. Service ...................................................................................................................................38
3.2.4. Resource................................................................................................................................38
3.2.5. Policy......................................................................................................................................39
3.2.6. Operation ...............................................................................................................................39
3.3. TNA Engineering Aspects.............................................................................................................39
3.3.1. Engineering Aspects of an NGOSS Component.................................................................40
3.3.2. Object Communication and Binding.....................................................................................41
4. NGOSS Technology Neutral Architecture Specification.......................................................................42
4.1. Overview ........................................................................................................................................42

TMF053, Version 5.7 TeleManagement Forum 2006 Page 3 of 96

The NGOSS Technology-Neutral Architecture

4.2. NGOSS TNA Artifacts .................................................................................................................. 43

4.2.1. NGOSS Core Artifacts.......................................................................................................... 43
4.2.2. NGOSS Container Artifacts.................................................................................................. 46
4.3. NGOSS Domain ........................................................................................................................... 56
4.4. Interoperation of NGOSS Domains ............................................................................................. 57
4.5. Interoperation of an NGOSS Domain to non-NGOSS/Legacy Domains .................................. 58
4.6. Overview of NGOSS Communications ....................................................................................... 58
5. References ................................................................................................................................................... 60
6. Conventions in this Document................................................................................................................. 62
6.1. Keywords that indicate Requirement Levels............................................................................... 62
7. Appendix A: DIOA Defined........................................................................................................................ 63
7.1. Purpose and Areas of Concern of a DIOA.................................................................................. 63
7.1.1. Target Environments ............................................................................................................ 63
7.1.2. Defining Use, Operation, Control, Administration, and Maintenance ................................ 66
7.1.3. Areas of Concern.................................................................................................................. 66
7.2. Conceptual Framework of a DIOA .............................................................................................. 68
7.2.1. Objectives.............................................................................................................................. 68
7.2.2. Requirements........................................................................................................................ 69
7.2.3. Conceptual Model................................................................................................................. 70
7.3. Components of a DIOA ................................................................................................................ 73
7.3.1. Object Models ....................................................................................................................... 75
7.3.2. Repositories .......................................................................................................................... 78
7.3.3. Formal Notations................................................................................................................... 78
7.3.4. Communication Services, Protocols, and Formats............................................................. 80
7.3.5. Transparency Services......................................................................................................... 82
7.4. References for the Appendix ....................................................................................................... 86
Administrative Appendix............................................................................................................................... 91
About this document................................................................................................................................ 91
Document Life Cycle ............................................................................................................................... 91
Document History .................................................................................................................................... 91
Version History.................................................................................................................................... 91
Release History................................................................................................................................... 94
Acknowledgments ................................................................................................................................... 94
About TeleManagement Forum.............................................................................................................. 96

TMF053, Version 5.7 TeleManagement Forum 2006 Page 4 of 96

The NGOSS Technology-Neutral Architecture

List of Figures
Figure 1: NGOSS Views 14
Figure 2: Example Hierarchy of Runtime Entities conforming to a DIOA 19
Figure 3: Federation of heterogeneous Architectures for an End-to-end SOA 21
Figure 4: Contracts and Components 36
Figure 5: Engineering Representation of an NGOSS Component 40
Figure 6: Engineering Representation of an NGOSS Component 40
Figure 7: Object Communication and Binding 41
Figure 8: NGOSS Technology Neutral Architecture Detailed View 42
Figure 9: NGOSS Technology Neutral Architecture High Level View 43
Figure 10: NGOSS Application 47
Figure 11: NGOSS Component DIOA Perspective 52
Figure 12: NGOSS Component SOA Perspective 52
Figure 13: NGOSS Service 53
Figure 14: NGOSS Framework Services 54
Figure 15: NGOSS Technology Neutral Architecture Detailed View 57
Figure 16: Interoperation of two NGOSS Domains 58
Figure 17: Interoperation of an NGOSS Domain with a Legacy or non-NGOSS Domain58
Figure 18: High Level Interaction Diagram for NGOSS Communications 59
Figure 19: Service Platforms – Distribution of Intelligence [Campolargo99] 65
Figure 20: Use, Operation, Control, Administration, and Maintenance 66
Figure 21: Areas of Concern and Activities of Distributed Systems 67
Figure 22: Conceptual Framework - Conceptual Model 71
Figure 23: Components of a DIOA 74
Figure 24: Computational and Engineering Objects 76
Figure 25: Distributed Directory and Referrals [ITU-X501] 83

List of Tables
Table 1: ODP as Reference Model for NGOSS Architecture 17
Table 2: Distributed Architectural Styles [Thelin03] 20
Table 3: NGOSS Essential Concepts 35

TMF053, Version 5.7 TeleManagement Forum 2006 Page 5 of 96

The NGOSS Technology-Neutral Architecture

1. Introduction
1.1. Background
With the convergence of data communications, telecommunications, and other forms
of communication, the complexity, heterogeneity, and size of the networks supporting
the emerging information and communications industry is rapidly increasing. The
proliferation of multiple types of smart devices, each with many ways to connect to
different networks, complicates not just end-to-end service delivery, but also billing,
provisioning, and other aspects of creating the service. Existing OSS (Operation
Support System) solutions cannot easily manage information and communication
networks today; future networks will exacerbate this situation. Future OSSs must take
into account not just the growth of the networks, but manage the complexity of
applications in different context that are being run on multiple networks that appear as
a single converged network. Particular focus must be paid to the increasing number
of users of the network, as well as the sophistication of services run on the network. A
new generation of OSS is needed to manage the new generation of networks and
services.

The Operational and Administration Management system of today has become a

roadblock to innovation, instead of a business tool for competitive success. The pace
of change in the industry is such that incremental improvements will not work
effectively. Service providers must both increase their operational efficiency by an
order of magnitude and reduce the time to market of new services to compete, while
software developers and systems integrators need to find completely new ways of
quickly producing profitable solutions. More importantly, the services and resources
provided by a network must be able to be easily changed by appropriate business
policies and goals.

This calls for a re-thinking on the part of information and communications service
providers on how they manage their business. It also calls for software developers to
embrace a new way of developing management software. This is the impetus for the
TM Forum's New Generation Operations Systems and Software (NGOSS) initiative.
The NGOSS initiative aims to deliver a framework for rapid and flexible integration of
Operation and Business Support Systems in telecommunications and throughout the
wider communications industry. Key areas of the NGOSS initiative are:
¾Definition of the Next Generation Business Process Framework
¾Definition of a standard set of Business Processes for the Information and
Communications Services Industry
¾Definition of the Systems Framework upon which these business processes
may be built
¾Practical implementations and live demonstrations of these solutions
¾Development of an industry compliance program to certify solutions and
products for compliance to the NGOSS Specifications.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 6 of 96

The NGOSS Technology-Neutral Architecture

¾Creation of a resource base of documentation, models, code and training

materials to support the TM Forum members in their own development of
NGOSS-compliant components

1.2. Goals and Objectives

This document will describe the major concepts and architectural details of the
NGOSS architecture in a technologically neutral manner. This document does not
prescribe a single new technology – rather, it allows for a federation of different
technologies, each of which offers particular advantages at the business and system
levels. In particular, it enables business concepts and principles to drive system
design and architectures. This may be implemented using currently available
distributed systems information technologies. Critical to this process is the sharing
and reusing of common data and information.

The goal is to define a component-based, distributed systems architecture and an

associated critical set of system services that this architecture requires.

Stakeholders will make different implementation decisions about the use of specific
information technologies in the management products they build or procure.
Therefore, this document describes the principles and system services that should be
adopted in these new systems in a technology neutral form.

This document enables the mapping of specific information technologies onto the
NGOSS technology neutral architecture. The specification of a technology neutral
architecture enables different technologies to be used to build coordinated
management systems that control one or more OSS components. It also enables the
fast adoption of new information technologies as they emerge.

This initiative will provide an industry roadmap of common implementation principles

to be adopted by all stakeholders in the value chain. The end objective is for the
management systems integration of ‘off the shelf’ software to be accelerated, leading
to reduced time to market. It is equally important to provide the ability to change and
update installed NGOSS systems in accelerated timescales.

1.3. The Road to NGOSS

NGOSS is a set of guidelines and specifications for the industry to build software in a
more structured and complementary way, based on industry experience and previous
and ongoing TM Forum activities. The TM Forum projects, described below, have
established a good basis for the NGOSS architecture. This enables it to be well
defined and yet sufficiently flexible to cope with emerging and as yet undetermined
technologies:
¾The Application Component Team (ACT) project developed the concept of
OSS building blocks that communicate via well-defined contracts1. It identified
separate tiers for Human Interaction, Process Automation, and Enterprise

1
Contract as defined in [SZY99]: Specification attached to an interface that mutually binds the clients and providers
(implementers) of that interface. Contracts can cover functional and non-functional aspects. Functional aspects include the
syntax and semantics of the interface. Non-functional aspects include quality –of-service guarantees.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 7 of 96

The NGOSS Technology-Neutral Architecture

Information Building Blocks. The ACT project has completed its work, having
delivered TM Forum document GB909 Part 1, which defines a set of generic
requirements for information building blocks. Its findings are being
incorporated into the NGOSS architecture framework as appropriate. In
particular, the architectural requirements for building blocks (which
correspond to NGOSS Components) and contracts as well as requirements
specific to Process Automation and Enterprise Information building blocks are
being incorporated.
¾The Application, Specialization and Integration of System Technologies
(ASIST) team has been identifying candidate distributed systems
technologies to support the architectural concepts presented by the ACT
team in GB909. The ASIST work has been incorporated into the technology-
specific work of NGOSS (by adopting ASIST Project's XML Application Note
v2.0). [TMF-TMF057]
The following TM Forum projects are currently active, and are contributing to the
specification of the technology-neutral architecture.
¾The enhanced Telecom Operations Map™ [TMF-GB921] and addendum
present a high-level overview of Telecommunications OSS business
processes. This is described in TM Forum document [TMF-GB921], and
provides the analytical basis for business process integration across the OSS
space. The eTOM builds on, and supersedes, the popular TM Forum
Telecom Operations Map (TOM) document (GB910).
¾The Shared Information/Data (SID) model [TMF-GB922] can be viewed as a
companion model to the eTOM, in that it provides an object-oriented
information/data reference model and a common information/data vocabulary
from a business entity perspective. Teamed with the eTOM, the SID model
provides enterprises with not only a process view of their business but also an
entity view. That is to say, the SID provides the definition of the ‘things’ that
are to be affected by the business processes defined in the eTOM. The SID
and eTOM in combination offer a way to explain ‘how’ things are intended to
fit together to meet a given business need.
¾The SID team also is chartered to work on a systems view. This would extend
the current business definitions of the SID to include system and architectural
aspects of a solution. This view will form the basis for technology-specific
implementations. Viewed in this way, the SID provides an extensible
information model for representing the Business and System Views of an
NGOSS system, and provides a series of models from which application-
specific data models can be derived. Currently GB922 and its addendum
present the Business View model, while the System View model is defined in
GB926 at its addendum
¾The Catalyst programs produce working demonstrations of technology
integration using the NGOSS specification according to TM Forum principles.
These projects, based on leading OSS products, validate and demonstrate
existing TM Forum work, as well as identify areas of particular difficulty for
ongoing integration work. Previous Catalyst projects have developed practical
solutions to common OSS integration problems, most notably in the areas of
business process abstraction, the use of some common information models,

TMF053, Version 5.7 TeleManagement Forum 2006 Page 8 of 96

The NGOSS Technology-Neutral Architecture

and the use of common communications services. The Catalyst program is

complementary to, and migrating towards, NGOSS style development, with
the findings of one activity incorporated into the other on an ongoing basis.
¾The Red Team was chartered in May 2002 to further complete the overall
NGOSS concept. The goals for this activity are to make the technology-
neutral architecture consistent, coherent, complete, and implementable.
Through a number of sub-teams, the Red Team worked to achieve these
goals. The work of the Red Team was transferred to the TNA Architecture
Working Group of the Lifecycle Team in February of 2004.
¾The Lifecycle Team incorporates the work of four working groups: the
Lifecycle and Methodology Working Group, the TNA Architecture Working
Group, the Model Driven Design and Development (MD3) Working Group and
the Compliance Working Group. The Lifecycle and Methodology Working
Group is responsible for the specification and illustration of the NGOSS
Lifecycle and Methodology as presented in GB927, GB930, and GB937. The
MD3 is exploring the generation of NGOSS systems through a model driven
approach of iterative model specification and transformation. The NGOSS
Compliance working group is developing an overall approach for the
evaluation of NGOSS systems and environments. This document, a product
of the TNA Architecture Working Group, is an extension and clarification of
the architecture work done by the Red Team and presented in TMF053 v4.0.

1.4. Program Implementation

The NGOSS program is a significantly complex set of activities. It has consequently
been planned as a set of phased deliveries. The outputs of each phase are planned
to be implemented in Catalyst projects and fed into subsequent phases, to ensure
lessons learned from implementation are incorporated into future guidelines and
specifications.

As the program progresses, it is expected that an increasingly comprehensive library

of documentation, models, contracts and reference implementations will be built
within the TM Forum and made available to the industry for implementation and
incorporation into products. This will enable the faster delivery of NGOSS-compliant
products, thus enabling the stakeholders to gain the benefits of a more
homogeneous, yet flexible, OSS environment.

1.5. Phases of Delivery and Roadmap

NGOSS will be delivered to Industry through a number of Phased Releases. An
overview of what is to be contained in each Phase of Release will be maintained in
the NGOSS Roadmap. This is kept up to date as a living document on
www.tmforum.org.

1.6. Stakeholders in this Document

This document is intended for use by a number of stakeholders, within which there
are likely to be a number of different roles, or users of, the document. The

TMF053, Version 5.7 TeleManagement Forum 2006 Page 9 of 96

The NGOSS Technology-Neutral Architecture

stakeholders presented below are not intended to be all inclusive, and it is accepted
that other uses for this document will be found.

These usage scenarios are based on the individual stakeholders who may use
various parts of the NGOSS specification(s) for their own goals. These stakeholders
are as follows:
¾Service Providers (SP)
¾System Integrators (SI)
¾Independent Software Vendors (ISV)
¾Network Equipment Providers (NEP)
Note: a detailed analysis of the business case benefits for and the requirements of
each of the individual stakeholders shown above are contained in the following TM
Forum documents
¾TMF051 (Business Case) [TMF-TMF051]
¾TMF052 (Requirements) [TMF-TMF052]
A further discussion of the roles that workers within each of the NGOSS Stakeholders
may perform can be found in section 3.0 of this document. Workers within these roles
will find a number of different uses for this document, depending on the internal
organization and processes of a stakeholder.

1.6.1. Document Use by a Service Provider

The NGOSS architecture will provide service providers with the basis for a flexible
OSS solution that will be able to rapidly evolve to meet the future requirements and
be able to manage multi-vendor, multi-technology networks and related services. The
NGOSS architecture will enable service providers to choose the 'best fit' management
components for their business and enable management capability to grow along with
the business, while protecting its OSS investment.

With the emphasis moving towards managing the timeliness and quality of the
services which the network delivers rather than blindly managing the elements of the
network, the need to be able to aggregate information from across all of the
management functions will become paramount. The NGOSS architecture will enable
easier communication across multiple management components, thus enabling the
easier sharing of data from the multiple sources. This document will provide the
Service Provider with a fundamental understanding of the architecture upon which
their OSS needs to be built. By understanding that architecture, the Service Provider
can take full advantage of all the features and services that NGOSS based systems
can offer, ultimately reducing operational expenditure to run its business and capital
expenditure to enhance the offering to its customers.

1.6.2. Document Use by a Systems Integrator

This architecture document is of key interest to system integrators that want to build a
new generation of operational and business systems. Integrating applications from

TMF053, Version 5.7 TeleManagement Forum 2006 Page 10 of 96

The NGOSS Technology-Neutral Architecture

the existing and previous generations of support systems typically characterized by

closed, frequently monolithic architectures with multiple private copies of data and
differing (often proprietary) technologies, meant forcing inter-application
communications. The NGOSS architecture with its support of a Shared Information
and Data (SID) model, open interfaces, contracts and a common systems framework
will enable system integrators to concentrate on the delivery of a completely
integrated business solution rather than the narrower focus of trying to get a few
applications to communicate.

Additionally, the basic concepts of the NGOSS architecture will mean a change in the
methodology used for integration. Being able to assume that the management
components will share common data formats and framework services as defined in
this architecture means that the system integrator can concentrate on the flow of the
business process and the policies affecting the flow. This flow enables a better
utilization of the network to meet the business objectives of the organization using it.

This document will provide system integrators with information needed to plan for the
skills and knowledge needed to work with both ISVs and NEPs delivering NGOSS
based solutions.

1.7. Document Use by an Independent Software Vendor

The NGOSS Architecture document will be of critical importance to ISVs that are
interested in competing in the OSS marketplace of the new generation networks.
Regardless of whether the ISV is interested in providing an implementation of basic
platform or middleware services, operational management applications, or both - this
document will provide the blueprint for success. As the service providers move
towards the deployment of the new generation networks, their demand for
component-oriented management systems software, based on the principles and
architecture of the NGOSS, will be the rule not the exception.

In the case of an ISV focused on the basic platform or middleware services (termed
Framework Services in this document) the NGOSS Architecture document and the
NGOSS Requirements document will provide the information that is typically
developed over months, if not years. In the case of an ISV working in the
management applications market, this document will provide the key to
understanding and leveraging the systems services available to support them.

1.7.1. Document Use by a Network Equipment Provider

For the network equipment provider this document will provide insight and
understanding of the management environment into which their equipment will be
deployed. Having that insight will enable them to structure and build their own
equipment management systems in a way that more easily integrates with the other
stakeholders in the value chain. As ease of integration of operations management
systems is increasingly a significant network equipment procurement factor, meeting
the industry need in this area will become critical to equipment sales success.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 11 of 96

The NGOSS Technology-Neutral Architecture

It will also enable more ambitious NEPs to change the architecture of their network
elements to enable them to be more easily managed. Finally, it provides insight into
how a next generation network element can better provide next generation services2.

1.8. Organization of this Document

This document is organized into multiple sections. Each section is briefly described
below
¾Section 1, Introduction
This section provides an executive overview of NGOSS, the work leading up to this
document and the roadmap for progressing NGOSS. It also summarizes the utility of
the document to each of the four major stakeholders: service providers, system
integrators, independent software vendors and network equipment providers.
¾Section 2, Architectural Requirement
This section, besides a general introduction on distributed architecture concepts,
explains which architectural requirements guided and pushed the definition of the
NGOSS Architecture and principles. It is these principles that are supported and
realized by the architectural definitions described in later sections.
¾Section 3, Architectural Concepts
This section introduces the concepts that provide the basis for defining the TNA.
¾Section 4, NGOSS Technology Neutral Architecture Specification
This section defines in details the NGOSS Technology-Neutral Architecture.
¾Section 5, References
This section contains a list of references used in the formulation of this document.
¾Section 6, Conventions in this Document
This section defines the conventions used in this document, e.g. keywords that
indicate requirement levels.
¾Section 7, Appendix A: DIOA Defined
This section gives a definition on what a Distributed Interface Oriented Architecture is.

Additional information will be covered, relative to this document, through the creation
and issuance of addenda. The current addenda are:

TMF053b Contract Description: Business and System Views

TMF053c Behavior and Control Services

2
This document defines the environment in which these next generation network elements will be deployed, and therefore
indirectly serves as requirements for the design of next generation network elements.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 12 of 96

The NGOSS Technology-Neutral Architecture

TMF053d Metamodel

TMF053f Distribution and Transparency Framework Services

TMF053p Policy Architecture (to be published)

TMF053s The NGOSS Security Principles

TMF053u Manageability of NGOS Software Artifacts and Use Cases (to be published)

TMF053, Version 5.7 TeleManagement Forum 2006 Page 13 of 96

The NGOSS Technology-Neutral Architecture

2. Architectural Requirements
2.1. Related Work

2.1.1. TMF Views

The New Generation Operations Systems & Software (NGOSS) consists of a

framework of principles and procedures that can be used to guide the development of
distributed computing solutions. NGOSS solutions are based on NGOSS and
corporate artifacts, and use some or all of the through the creation and re-use of
artifacts retained in the Knowledge Base, as shown in Figure 1. The key, then, is for
this to be done in a way compliant with NGOSS principles. The NGOSS program
offers a number of individual artifacts. The NGOSS Lifecycle utilizes all these
artifacts.

Business System
Logical
View
Business Capabilities, System Capabilities,
Constraints & Context Constraints & Context
Corporate NGOSS
Knowledge Shared Knowledge
Base Base

Deployment Implementation
Physical
View
Implementation Capabilities,
Deployment Capabilities,
Constraints & Context
Constraints & Context

Service Providers Service Developers

View View

Figure 1: NGOSS Views

Moving in a clockwise direction, an operator’s deployment teams apply the

procedures defined in the selected method to identify the business need, model the
solution, validate the model and build the run-time system solution. Each team will be
staffed to fulfill the roles necessary to allow their understanding of the solution to be
properly documented. Each team’s view of the solution space will be rendered as a
set of specifications created by drawing on the artifacts available from the Knowledge
Base.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 14 of 96

The NGOSS Technology-Neutral Architecture

The artifacts retrieved from the Knowledge Base support building a model (problem,
constraints and answer) of the proposed solution. The model is used as the basis for
reconciling implementation and realization decisions once construction on the actual
distributed system solution is underway.

The types of artifacts available for use in constructing the solution model are varied,
but fall into four general categories: process, information, operational mechanisms3
and infrastructure:
¾Process Context – business process flows, system process plans and
process realization scripts
¾Information Context – business entities, shared data models, and realization
data models
¾Operational Context – contracts, policies, code, testing systems
¾Infrastructure – technology neutral and technology specific architectural
frameworks
The process and information contexts provide a way to focus on a particular
dimension of the solution space. As can be seen from the artifacts listed above, the
process context emphasizes the high-level behavioral aspects of the solution space
while the information context describes specific details regarding the factual aspects
(i.e., the static data and dynamic aspects, as well as behavior and interaction
between, components of the solution space.

Thus, the purpose of this NGOSS Lifecycle view is to relate the business, system,
implementation, and runtime views of systems and Components to each other. The
reader is encouraged to review [TMF-GB927] for a detailed introduction of the
NGOSS lifecycle, the NGOSS views, and the NGOSS methodology.

2.1.2. RM-ODP Views

The Reference Model for Open Distributed Processing (RM-ODP) [ITU-T X901]
consists of four parts: object modeling, viewpoints, distribution transparencies, and
framework. Together they form an architecture integrating support for distribution but
also for interworking (between ODP systems), interoperability, and portability
(independence from hardware and software platforms). Note that RM-ODP is used as
the basis for the NGOSS TNA reference model.

The major part of the reference model is the definition of five viewpoints enterprise,
information, computational, engineering and technology. Each of them makes
consideration of an ODP system from a different perspective. A viewpoint serves as
an abstraction to a particular set of concerns. The viewpoints are independent of
each other. However, key elements of one viewpoint may be related to items of other
viewpoints. [ITU-X901]

The architectural framework of the reference model is constructed by these five

viewpoints and transparencies. “A set of concepts, structures, and rules is given for
each of the viewpoints, providing a ‘language’ for specifying ODP systems in that

3
Noting that a Contract can be realized as software

TMF053, Version 5.7 TeleManagement Forum 2006 Page 15 of 96

The NGOSS Technology-Neutral Architecture

viewpoint. … The aim of transparencies is to shift of distributed systems from the

applications developers to the supporting infrastructure. RM-ODP defines a number
of commonly required distribution transparencies the computational refinements and
use of engineering functions needed to transparencies.” [Raymond95] RM-ODP
defines the five viewpoints to be both simple and complete, covering all the domains
of architectural design [ITU-X901] [ITU-X903].

The enterprise viewpoint is concerned with the purpose, scope, and policies
governing the activities within an organization. The information viewpoint deals with
the information handled by the system, as well as the constraints on its use, and
interpretation of that information. The computational viewpoint focuses on the
functional decomposition of the system into a set of objects. The engineering
viewpoint identifies the infrastructure required to support system distribution. The
technology viewpoint covers the choice of technology to support system distribution.

2.1.3. TMF Views and RM-ODP Viewpoints

The NGOSS architecture, as one part of NGOSS (besides eTOM, SID, and
Compliance), adopts concepts from RM-ODP for architectural modeling. In other
words, NGOSS is based on RM-ODP but defines a number of enhancements
(GB927) and differences (SID, policy, and contracts). The main NGOSS artifacts are
Use Cases, Process Descriptions, Policies, shared information, and Contracts. All of
these artifacts appear at all views of the NGOSS lifecycle; hence, a simple one-to-
one mapping from the ODP viewpoints towards the NGOSS views is not possible.
Effectively, any one NGOSS view is concerned with aspects of two or more of the
ODP viewpoints.

Table 1 provides an overview on how and where ODP concepts are used within the
NGOSS architecture. The ODP enterprise viewpoint is reflected by the NGOSS
business view. The ODP information viewpoint is represented by business and
information modeling of NGOSS artifacts, which constrain the NGOSS architecture.
The ODP computational and engineering viewpoint can be used as reference
methodology for computational and engineering aspects of the NGGOSS
architecture, mainly found in the system view. NGOSS implementation and
deployment view focus on aspects similar to ODP engineering and technology
viewpoint, providing mappings of computational concepts towards concrete
implementation and deployment environments.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 16 of 96

The NGOSS Technology-Neutral Architecture

Table 1: ODP as Reference Model for NGOSS Architecture

NGOSS NGOSS NGOSS NGOSS

Business View System View Implementation Deployment (Run-
View time) View

ODP 1) 2)
Enterprise Business Contract SID Policies SID Policies Business Contract
Viewpoint modeling, e.g. Assurance, e.g.
eTOM Business SLA monitoring or
Processes; SID Policy Monitoring,
Policies; etc.; associated
associated SID other SID entities
entities

ODP 3) 4) 5) 6)
Information Business Contract System Contract Implementation Deployment
Viewpoint modeling; SID modeling; SID Contract; definition Contract; SID
policies; associated policies; associated of information model policies; associated
SID entities SID entities to data model SID entities
mapping; SID
policies; associated
SID entities

ODP 7)
Computational definition of SID TNA-TSA mapping TNA-TSA mapping
Viewpoint entities, TNA of architectural of architectural
computational constructs constructs
aspects

ODP 8) 9) 10)
Engineering TNA engineering implementation deployment of
Viewpoint aspects; policies; environment; Contract instances;
SID entities policies; SID entities policies; SID
entities

ODP 12) 13)

Technology policies; SID entities Contract deployment
Viewpoint implementations; environment;
policies; SID entities contract instances;
policies; SID
entities

2.2. Distributed Interface Oriented Architecture

A requirement for Next Generation Networks (NGN) and their NGOSS is that the
architecture approach must address software and hardware heterogeneity both from
an end-to-end service delivery point of view as well as in Information,
Communications and Technology (ICT) system(s). A distributed, interface-oriented
architecture (DIOA) provides the technology-neutral architectural reference point to
satisfy this requirement.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 17 of 96

The NGOSS Technology-Neutral Architecture

A DIOA is defined as follows: a provider entity offers functionality across its interface that involves
coordinated behavior from both the consumer and the provider entities. The set of consumer and
provider behavior, invoked using an interface, is an architectural construct that can be distributed.

The NGOSS technology-neutral architecture is specified using DIOAs. Section 7

provides a more detailed definition of what DIOA is, including concepts, rules,
principles and target environments. In general, a DIOA is a technological neutral
architecture. Applications designed using this architectural style are not bound directly
to middleware and management technologies (not on abstract design level). A DIOA
should consist of a number of recommendations which form the basis to realize this
transparency:

The basis should be an abstract object model. A concrete object model is derived
from the abstract object model. The concrete object model defines the basic
specification elements of an application.

A language is a formal notation that is used to express the object model. This
language might combine characteristics from middleware interface definition
languages, languages for the definition of managed objects, and languages used to
specify data that is exchanged between applications.

(Business) Application objects are specified in the language. A DIOA should define a
model that is relevant for all applications and probably independent of domain specific
specifications. The basic part of the model is the identification of a reasonable set of
qualifiers providing meta information about application objects.

An Common Communication Vehicle responsible for the transport of information

among application objects including features that enable the construction of
management hierarchies like addressing of hierarchies, scoping and filtering, and
transactions.

An Application Programming Interface (API) or other means have to be introduced to

decouple application objects from middleware technology and enables the seamless
integration of management functionality into applications. The API should offer a
small and simple to use set of operations for the parameterization of the protocol.
Tools are responsible for the automatic generation of parts of the API code that is
needed for the exchange of information between applications.

Framework services realize the naming of objects; enable the mapping of language
specified information to i.e. directories, and the usage of type and data repositories for
applications and DIOA components. All application services can be accessed in a
unified way similar to the access to other applications. The API implements standard
jobs like lookup for available services and registration.

Figure 2 shows the topology of interfaces that is based on the fact that an entity can
itself offer one or more interfaces for other entities to bind to and exploit. This
hierarchical nesting can go ad infinitum. The figure shows a two-level example of
such a structure. Each circle represents an entity that supports one or more interface.
The interfaces are labeled 1 through 6. the client at Level 2 (A) uses interface 6,
which is provided by the client at Level 1 (B), which uses interfaces 1 through 5
provided by C, D, and E.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 18 of 96

The NGOSS Technology-Neutral Architecture

Level 2 A

Level 1 B

3
1 2 4 5
C D E

Figure 2: Example Hierarchy of Runtime Entities conforming to a DIOA

A DIOA entity that provides an interface must be programmable using some type of
programming language. Entities that support interfaces (such as C, D, and E) must
also be programmable using some type of programming language. In order for the
hierarchical structure shown in the figure to be achieved, entities like B must be
programmable in a language that not only permits binding to interfaces 1 through 5,
but must also permit the advertisement of interface 6 for consumption by other
entities. This advertisement is commonly described as a service in the SOA style,
even though it is still “just” an interface.

2.2.1. NGOSS DIOA and Architectural Approaches

The NGOSS architecture, as a DIOA, provides a technological-neutral architectural

reference point for design styles. This is an important architectural consideration; in
order to achieve optimum business agility and flexibility, services from the entire
enterprise need to be re-usable at all layers of the ICT system e.g., customer and
resource facing services (see GB922 Addendum 4SO [TMF-GB922-4SO] for their
definitions).

Basically, there are three architectural styles [Thelin03], which DIOA supports:
¾Object-oriented
¾Resource-oriented
¾Service-oriented
The object-oriented style (e.g. CORBA) involves communication between particular
object instances, which have state, behavior, and identity. Communication is implicitly
stateful. Using a resource-oriented style (e.g. REST4) involves the retrieval of
particular resource instances. Resources have a state and identity. The service-
oriented style (e.g. SOA) involves communication with a specific application service
by sending all messages/requests for that service to a specific endpoint.

4
REST - REpresentational State Transfer

TMF053, Version 5.7 TeleManagement Forum 2006 Page 19 of 96

The NGOSS Technology-Neutral Architecture

Communication is implicitly stateless. [Thelin03] Table 2 provides an overview of

several aspects of these architectural styles.

Table 2: Distributed Architectural Styles [Thelin03]

Attribute Object-oriented Resource-Oriented Service-oriented

Granularity Object instances Resource instances Service instances

Main Focus Marshalling parameter Request addressing Creation of request

values (usually URLs) payloads

Addressing / Request Routed to unique object Unique address per One endpoint address
Routing instance resource per service

Are replies No Yes No

cacheable?

Application Interface Specific to this object / class Generic to the request Specific to this service –
– description is middleware mechanism (e.g. HTTP description is protocol
specific (e.g. IDL) verbs) specific (e.g. WSDL)

Payload / data format Yes – usually middleware No – nothing directly Yes – part of service
description specific (e.g. IDL) linked to address / URL description (e.g. XML
Schema in WSDL)

Service Oriented Architecture

Understanding the Service Oriented Architectures (SOA). and how to differentiate this
from the DIOA is essential to ICT System development and NGN-Management
specifically. Gartner, which provided a first definition for SOA in [Gartner SPA-401-
068], states that “A service-oriented architecture is a style of application partitioning
and targeting (placement). It assumes multiple software tiers and usually has thin
clients and fat servers (i.e., little or no business logic on the client), but it is more than
that. It organizes software functions into modules in a way that maximizes sharing
application code and data.” [Gartner AV-19-6751] follows on this and says: “SOA
would be better-named interface-oriented architecture.”

The fundamental entity in any DIOA is an interface. Any services of the SOA style are
interfaces of the DIOA. A running system constructed using a DIOA consists of a
number of runtime entities that together offer the needed functionality as a coherent
set of interfaces (which in fact comes close to the original SOA definition from Gartner
stated above). Clients wishing to make use of this functionality bind to the required
interfaces and invoke operations over those bindings.

An SOA is a service specialization of a DIOA. All SOAs are by default DIOAs, but not
all DIOAs are SOAs. A DIOA allows architectural federation and service re-use
throughout the entire enterprise, irrespective of the technology basis for distributed
systems. Re-using the NGOSS DIOA specifications (defined in this document and its
annexes, along with [TMF-GB922] and [TMF-GB926]) allows more specific
architectural structure to be applied to support an SOA reference model, such as

TMF053, Version 5.7 TeleManagement Forum 2006 Page 20 of 96

The NGOSS Technology-Neutral Architecture

[OASIS RM]5. The NGOSS architecture provides the architectural concepts that can
be used to realize an SOA. Here, key features of an SOA are:
¾The fundamental entity in any SOA is still the interface, but published and
subscribed as a service (regardless of the employed repository model and
component implementation)
¾All SOA services are DIOA interfaces, but not all DIOA interfaces are SOA
services;
¾The DIOA is the common enabler for federation and distribution.

WS SOA
SOA End Point
WS SOA
SOA
End Point
Sub-DIOA

Non-DIOA
Distributed Software
Architecture Bus, CCV, messaging or fabric
Federation Service or Interface

Figure 3: Federation of heterogeneous Architectures for an End-to-end

SOA

Figure 3 is an example of the federation paradigm using a DIOA. This figure

illustrates two end points of an end-to-end service operated as an overarching SOA.
However, the infrastructure is made up of component architectures conformant to a
DIOA style (which in fact can be web services, other SOAs, and other architectures).
The truism that technology will always be heterogeneous in end-to-end solutions
means that in using SOA this DIOA federation and distribution paradigm is an
essential design requirement.

ETSI TSPAN Next Generation Networks

The NGOSS Architecture principles has been considered to be of fundamental importance for the
management of complex and heterogeneous networks such as NGNs (Next Generation Networks)
by the ETSI TISPAN Technical Committee, which adopted the NGOSS Architecture as one of the
cornerstones for the specification of a Management Architecture for the NGN [ETSI-TS188-001].

2.2.2. Components

Current best practice in the exploitation of DIOAs is to introduce a component model

for the modeling and implementation of run-time entities. Furthermore, DIOA is used
for component based software engineering techniques for design, implementation
and deployment of solutions constructed [SEI00]. This section introduces related
work from [SEI00] activities.
5
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm

TMF053, Version 5.7 TeleManagement Forum 2006 Page 21 of 96

The NGOSS Technology-Neutral Architecture

Component-based software engineering is concerned with the rapid assembly of

systems from components where
¾Components and frameworks have certified properties; and
¾These certified properties provide the basis for predicting the properties of
systems built from components.
¾A software component merges two distinct perspectives
¾Component as an architectural abstraction, which express design rules that
impose a standard coordination model on all components.
¾Component as an implementation, which can be deployed and assembled
into larger sub-systems or systems.
¾A component is:
¾an opaque implementation of functionality
¾a unit of deployment that is subject to third-party composition
¾conformant with a component model
The ability to integrate components and to develop a market of components depends
fundamentally on the notion of component interface. An interface is a coherent set of
functional capabilities (both attributes and operations) of a component that
users/clients of those capabilities can rely on.

The pattern of interaction among different roles, and the reciprocal obligations of
components that fill these roles, must be specified in some way. A role is an expected
behavior pattern of an actor in an interaction. Roles are quantified in many ways (for
instance, by constraints, associations, and state transition diagrams).

A component model specifies the design rules that must be obeyed by components.
These design rules improve composability by removing a variety of sources of
interface mismatch. The rules ensure that system-wide definitions of attributes and
behavior are met, and that components may be easily deployed into development
and runtime environments. These rules cover also how components can be
aggregated and/or composed into larger assemblies, and define the external visibility
of the component interfaces within an assembly. In order to enable the maximum
scope for use, the component model should enable the component composer to tune
the visibility of such (internal) interfaces.

A component framework provides the services and mechanisms to support and

enforce a component model; for NGOSS, this document specifies the technology-
neutral architecture to achieve this.

2.3. NGOSS Architecture Requirements

There are a number of requirements that have driven the conception of the NGOSS
architecture and represent industry best practice. The NGOSS integrates these
principles into a coherent architecture for the development of management systems.
This section of the document serves to introduce these fundamental architectural
drivers.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 22 of 96

The NGOSS Technology-Neutral Architecture

2.3.1. Interface Definition

An NGOSS system must be characterized by the fact that each software entity that
provide Services to other entities does so through an interface defined in a way that the
corresponding Service is specified with the following characteristics:
¾A description of the Service to be provided in terms of:
• The metadata used to describe the interface
• The metadata used to describe the operations that may be invoked
on the Service
• For each operation, the set of terminations6 that may be returned by
the Service after invocation of the operation
¾The behavior of the Service: some of the behavior that may be specified are:
• The pre-conditions under which an operation may be invoked (i.e., the
set of conditions that must be satisfied in order to invoke the
operation)
• The post-conditions, which define the state that the system is left in for
each termination that can be returned when an operation is invoked
¾The service must be independently manageable.
Within the NGOSS Architecture, services are considered to fall into one of two
general categories:
¾Framework Services
¾Business Aware Services
Framework services are those services that provide non-business oriented services
to the system. Framework services include, but are not limited to, such things as:
• Naming and directory services
• Messaging services
• Network time services
• Transaction management/monitoring services
• Policy distribution services
Business aware services provide the application level functionality that directly
supports the implementation of a business process. Business aware services include,
but are not limited to, such things as:
• Customer record management
• Customer SLA management
• Service quality management
• Billing mediation
• Rating and discounting
Business aware services and framework services work together in order to deliver the
functionality required by a particular NGOSS deployment; framework services have

6
An operation invocation can return one of a set of results (each potential result is called a termination).

TMF053, Version 5.7 TeleManagement Forum 2006 Page 23 of 96

The NGOSS Technology-Neutral Architecture

no value add in and of themselves, while business aware services can not
interoperate without the presence of framework services.

Both business aware services and framework services are contractually specified and
deployed via components. The differentiation is in the use of the services, not how the
services are integrated into the network.

Note that in the monolithic applications that make up the vast majority of
contemporary systems, framework services and business aware services exist; they
are simply so intertwined that external identification and separation is not an easy
task. Furthermore, in said contemporary systems, the framework services are often
proprietary to the applications of each ISV that has applications deployed in the
management system. This fact dramatically complicates the integration of the various
applications. Often the solution is to add another set of framework services into the
system and use those services to integrate the disparate applications, which simply
put, adds nothing but cost and complexity into the system.

2.3.2. Technology-Neutral Component Model7

The NGOSS architecture must be a component-based architecture. From the

minimalist point of view, components offer service capabilities. However, to fully
understand the implications of component-based systems, the minimalist point of
view is insufficient.

Using the work of [SZY99] and [SEI00], the NGOSS Technology Neutral Architecture
defines a component as follows.
¾A contractually specified,
¾Unit of independent deployment,
¾Subject to 3rd party composition,
¾And conformant to a component model
An NGOSS Component is one of the artifacts of the software development process.
In order to be useful, the services provided by a component must be clearly specified.

An NGOSS Component must:

¾have all of its external (contextual) dependencies explicitly defined;
¾be implemented in compliance to a technology-specific component model,
such that a technology-specific component execution environment is capable
of making the NGOSS Component services available at runtime to the
remainder of the system8.
¾either not have persistent state [SZY99] or must manage its persistency
according to the business requirements of the system (e.g. high availability

7
Throughout the remainder of the document, the term component (with lower-case ‘c’) is used for components consistent
with the SEI definition, while the term Component (with upper-case ‘C’) is used for an NGOSS technology-neutral
Component.
8
The issue of conformance to a component model is seen as being a technology-specific issue and will not be discussed
further within this document.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 24 of 96

The NGOSS Technology-Neutral Architecture

and/or hot failover). This applies to an NGOSS Component, not to an

interface or service that will of course create, manipulate, and rely upon
information that is stored in a persistent fashion within the system. The reason
for this requirement is that in a high availability environment, the possibility of
redundant Component installations must be accounted for. An NGOSS
Component instance is the installation of a particular Component within the
system in such a manner that this particular Component can be instantiated
by the component execution environment. If a Component instance has
persistent state associated with it that is required by service instances, and
that state information becomes unreachable, for whatever reason, the ability
to use a redundant Component instance is compromised. A Component
instance may have local configuration information, and information related to
the management of the Component instance (license key, local directory
server name, etc), but may not maintain information at the Component
instance level to be used by other external entities.
Given the defined services and the explicitly defined external (contextual)
dependencies, an NGOSS Component can be combined in a system with other
NGOSS Components to deliver an aggregated service that is then available to all
other NGOSS Components (and client applications) within the system.

For instance, in a Java™ based system, the component is embodied by the .JAR9
file. The .JAR file contains other files (e.g., .class files) that are the compiled (i.e.,
Java™ virtual machine byte-code) binary implementation of the technology-specific
components, each of which contain contractually specified functionality. The .JAR file
may be installed into a system and used, provided that any external contextual
dependencies are met. The Java™ 2 Standard Edition platform does not, in and of
itself, provide support for the specification of these external contextual dependencies,
other than as textual documentation. Installation-time support for the specification of
external context dependencies is provided through the chosen Java™ 2 Component
Model. One implementation of this is Enterprise Java™ Beans (EJB), specifically via
the EJB deployment descriptor.

The NGOSS Architecture makes the following presumptions in regards to NGOSS

Components:
¾The NGOSS architecture must not define which interfaces and services are
contained in a particular Component.
¾The NGOSS architecture, however, must define how Components operate in
general, as well as how a Component installs and makes its services
available.
The reason behind the choice of a Component-based development relies in the
advantages over the existing, traditional approach of monolithic system development.
These benefits include, but are not limited to:
1. Supply of components from multiple sources.

9
Java™ Archive File

TMF053, Version 5.7 TeleManagement Forum 2006 Page 25 of 96

The NGOSS Technology-Neutral Architecture

This supports best value for money in procurement of components and enables
financial considerations to be taken into account for make / buy decisions. It also
helps prevent vendor lockout as well as lock in.
2. Re-use of components.

Business components may be re-used across multiple business scenarios. In

addition, new business scenarios may be viewed as ‘delta’ changes to existing
solutions. The financial implications for this are centered upon the need for only
marginal additional costs when components have to be extended or replaced to
support the new business scenarios.
3. Legacy / heritage systems.

It may be necessary to bring legacy non-NGOSS systems to an NGOSS environment

for business/financial reasons. This can be achieved by creating mediation interfaces
between legacy systems and the NGOSS components.
4. Flexibility of the systems environment and associated speed to market for new service
products.

Since new service products will be delivered through linking together of components,
this more flexible environment will allow a much more diverse range of service
products to be provided to customers. In addition, the NGOSS approach shall enable
them to be provided in a much faster time.

2.3.3. Separation of Business Process and Policy from Component

Implementation

An NGOSS system must be characterized by the separation of the hard coded

behavior of Components from the software that automates business processes
across the Components – i.e. 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 externalized descriptions of behavior
expressed in a technology-neutral manner.

Examples of this are:

¾The external description of a Service is separated from one or more specific
implementations through a representation called a Contract. Contracts enable
different aspects of the business and system views of an application to be
integrated through the use of business and system models.
¾A business process is represented by an executable meta-language
description, which describes the flow of execution between Component
instances.
¾System behavior is controlled through the use of different types of
management paradigms
A business process model may invoke lower-level business process models. This
means that a business process step that a service provider desires to automate (e.g.,
verifying that the network can support the provisioning of a desired service) may be
made up of one or more lower-level interactions with different system runtime entities

TMF053, Version 5.7 TeleManagement Forum 2006 Page 26 of 96

The NGOSS Technology-Neutral Architecture

that provide the necessary services; lower-level business process models used in this
way must be able to provide one or more Contract instances to which the higher-level
business process model can bind. That means that multi-level process management
can be supported.

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.

In pre-NGOSS systems, parts of business process functionality are embedded in

separate business Components that lack the control interfaces to allow proper
management of the business processes. This fragmentation of the business process
renders many process management techniques impossible or impractical. The
separation of the business process from the Components allows process
management techniques to be applied; for example, most business process models
are in fact sequenced calls to business service Contracts.

2.3.4. Security-Enabled Architecture

The customers of telephony services (voice and data) are demanding innovative
solutions that can be deployed quickly, are highly configurable and provide
heterogeneous support for multiple vendors and multiple technologies. An NGOSS
system is required to manage these customer demands and the new generation of
networks. The TMF has taken up the challenge to design an infrastructure that will
meet the industry need. As part of that initiative, it is important that the solutions
provide a security infrastructure to meet the demands for security.

The heterogeneous nature of the current generation of telephony services means that
customers will have their service provided by a mix of companies and departments. In
this environment companies must automate the processes that provide those
services. Inadequate security in this environment could quickly escalate into major
revenue loss as vulnerabilities are exploited by automatic systems.

An NGOSS system must 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 we have structured the security provisions using the
structure of the ISO/IEC 15408 (also known as Common Criteria) security standards.
This provides a framework to manage and operate an NGOSS system to meet the
security objectives of an operating company.

2.3.5. Policy-Enabled Architecture

The NGOSS system architecture mandates the use of policy management. The term
policy-enabled is defined as a system that operates using policies to make present
and future decisions. In other words, if a system is policy-enabled, then the operation
and management of that system is dependent on the execution of policies. Stated
more generally, policies provide rules that govern behavior within a system. Policy

TMF053, Version 5.7 TeleManagement Forum 2006 Page 27 of 96

The NGOSS Technology-Neutral Architecture

rules are defined to meet business, system, or other objectives; consequently,

policies may link one or more of the business, system (operational), and
implementation views of the NGOSS system to each other. Please see [TMF-
TMF053C] for more information.

A Policy Service has three main uses. First, it may be called upon to validate
something using a specified policy (such as a user’s access privileges, as specified
by a security policy). Second, it may be used to determine what policies apply to a
given set of conditions. Finally, it may be called upon to determine if there is a conflict
between two or more policies that are to be executed.

The policy-enabled requirement mandates that the basic architecture indicate those
points in the execution stream at which policy information will be consulted if policy is
enabled in a particular OSS, and how those policies will be executed.

A solution built on theNGOSS Architecture must support Policy Based Management

and all implemented NGOSS Software Artifacts must be policy-enabled.

2.3.6. Models, Shared Information and Data

An NGOSS system must be characterized by the usage of a common information

model for enabling integration and interoperability. The information model 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, all
provided in a standard representation using standard data types, is used to describe
domain information (e.g., orders, network service and configuration definitions) in an
NGOSS system.

Models

The term “model” here refers to the external specification of the characteristics and
behavior of managed entities. Two types of models must be specified in an NGOSS
solution:
¾An information model that is an abstraction and representation of the entities
in a managed environment. This includes definition of their attributes,
operations and relationships. It is independent of any specific type of
repository, software usage, or access protocol.
¾A data model that is a concrete implementation of an information model in
terms appropriate to a specific type of repository that uses a specific access
protocol or protocols. It includes data structures, operations, and rules that
define how the data is stored, accessed and manipulated.
Models can take many forms, including the specification of class diagrams, metadata,
business objects, contracts, processes, deployment information, and policy
information. It is important to note that models are used to provide an extensible
system, rather than hard-coding information explicitly into a set of software modules.
The NGOSS architecture must be built around the principle of externalizing this
information, and expressing it in a technology-neutral fashion ([MDA] provides a
reference to Model Driven Architectures). Managed information defined in these

TMF053, Version 5.7 TeleManagement Forum 2006 Page 28 of 96

The NGOSS Technology-Neutral Architecture

models can be retrieved by using the browsing functionality provided by the

Registration Services.

For consistency across an NGOSS solution, the representation of information within

an NGOSS deployment will be accomplished using the NGOSS metamodel [TMF-
TMF053D] and SID [TMF-GB922].

UML will be used to model shared information and data. There are many different
ways to express behavior. However, since the SID is based on UML, OCL (the
Object Constraint Language) will be used for expressing computable expressions that
affect managed entities. Implementing the OCL expressions is outside the scope of
this document.

Information/Data Stewardship

An NGOSS system, to be distributed, must also be characterized by the stewardship

of distributed enterprise data. Stewarded data has two fundamental characteristics
that differentiate it from non-stewarded data.
¾There is a clearly identified “information steward”, that controls information in
the business and system viewpoints.
¾There is a clearly identified “data steward”, that is responsible for data
management in the implementation and runtime viewpoints. The “data
steward” is responsible for ensuring the integrity of data in an operational
system. A “data steward” may be a database management system, or it may
be a business aware services.
¾A steward also supports a control mechanism, so that a service can be
informed of changes to critical, shared data.
¾The architectural term for providing stewarded data is information provider.

Information/Data Adaptation and Mediation

While the NGOSS architecture describes a neutral and uniform framework of

Services, Components, and a Shared Information and Data model, real-world
deployments may not represent or be able to implement this ideal. For this reason,
the NGOSS architecture must include the concepts of “adaptation” and “mediation”.

Mediation is the process of translating from one level of representation and/or

abstraction to another level of representation and/or abstraction. Often, mediation of
two entities is achieved by translating the two entities to a common third form (e.g.,
the SID defined in GB922 [TMF-TMFGB922]). Mediation enables entities to
interoperate in a loosely coupled way.

Adaptation is a mechanism to convert one entity that has a particular syntactic

representation to another entity that has a different syntactic representation, in order
to enable interoperation of the two. Effective interoperation may still require the
application of a mediation layer, since adaptation only addresses syntactic
differences, not semantic differences.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 29 of 96

The NGOSS Technology-Neutral Architecture

2.3.7. Distribution Transparency

In the following sections 2.3.7.x requirements to support distribution transparency are

presented.

A Repository of Runtime Information

An NGOSS system must be characterized by the existence of a repository that

records information used during system execution, such as the following:
¾The Naming Service enables logical names and/or aliases to be assigned to
a manageable entity that renders a Service
¾The Naming Service then enables the subsequent access to that
manageable entity by its names and/or aliases
¾The Naming Service provides the ability to bind attributes to a named entity
¾The Contract Instance Location Services enables access, selection and
location without knowing the precise name of the object that provides the
service (i.e. the attributes are used as selection parameters)
¾The location and state of all management entities in the environment (e.g.,
people and/or processes that can manage certain devices and services)
¾The location and state of “models”, which are externalized descriptions of
content and/or behavior, as described below.
¾Information that supports the use of any service or policies, or the set of user
instance and role instance information that is used by any defined Policies.
¾The existence of a single logical repository is assumed, regardless of whether
it is physically implemented as a single or a distributed system.
Note that the repository must store technology-neutral artifacts as well as technology-
specific artifacts. This document is only concerned with its use of technology-neutral
concepts.

Common Communication Vehicle

An NGOSS system must be 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 any security policies that a service provider has
defined for his/her network.

More importantly, the use of a common communications mechanism enables the

standardization of system-wide operations, messages, or events that can be

TMF053, Version 5.7 TeleManagement Forum 2006 Page 30 of 96

The NGOSS Technology-Neutral Architecture

distributed to interested components. This is an important point, as a transport “just”

carries information, and by itself doesn’t provide interoperability.

Invocation Mechanism

There are several steps associated with invoking an operation on a service instance:
location of the instance providing the service, proper usage of the communication
mechanism, results handling, etc. Security and other policies must be applied at each
step in the process. For this reason, Invocation mechanisms must be defined as a
convenient way to perform all of these steps and ensure the integrity of the operation
in the context of the overall system and the client invoking the service. These
mechanisms are usually technology specific and therefore not covered in this
document.

2.3.8. Compliance and Certification

While not strictly core principles of the NGOSS architecture, compliance and certification
ensure that an application claiming compliance to NGOSS implements and complies with
the fundamental principles of NGOSS. For the NGOSS architecture to be ubiquitously
deployed, it must be possible to measure the degree of compliance that any given
implementation of the NGOSS architecture exhibits. The particular services that are
deployed within an NGOSS based system are not the measure of its compliance.
Instead, compliance is measured by verifying if an implementation has implemented the
core principles of an NGOSS architecture, as described in this document. The following is
a listing of the most important of these principles.
¾Architecture is inherently distributed (section 2.2)
¾Architecture uses interfaces to communicate (section 2.2)
¾Architecture is componentized (section 2.2.2)
¾Business processes are separated from Component Implementation (section
2.3.3)
¾Architecture is security-enabled (section 2.3.4)
¾Architecture must be policy-enabled (section 2.3.5)
¾Architecture uses shared information and data (section 2.3.6)
¾Architecture uses a common repository (section 0)
One of the most important mechanisms for realizing the above is the use of
Contracts, as defined in section 4 and in [TMF-TMF053B]. The specific details of this
are beyond the scope of this document, please refer to [TMF-TMF053B]. Briefly, a
given system’s compliance to NGOSS architectural principles is measured by its
compliance to the above eight bullet points, not of the system functionality as a whole.
Furthermore, information is accessed and exchanged using contracts.

A deployment of an NGOSS system need have only those components that contain
implementations of the Services that are required to meet the needs of the system
operator. Such a deployment represents a complete deployment of an NGOSS
system. However, it is important to note that what appears to be a complete

TMF053, Version 5.7 TeleManagement Forum 2006 Page 31 of 96

The NGOSS Technology-Neutral Architecture

deployment for one system operator may in fact be a partial deployment (relative to
needed Services) for a second system operator.

Certification requirements will be established by the TeleManagement Forum

“NGOSS-Powered™” industry-wide Compliance Program steering team. These
requirements are considered to be out of scope for this document; instead, they are
specified in the TMF 050 document series [TMF-TMF050].

2.4. Separation of Technology-Neutral and Technology-Specific

Architectures
One of the major guidelines in the definition of the NGOSS Architecture is the clear
separation between the concepts that are independent of any specific implementation
technology, namely “Technology-Neutral Architecture – TNA”, and the concepts
specific to one or more particular technologies, namely “Technology-Specific
Architecture(s) – TSA”.

Therefore, all functionalities provided in a TNA Architecture, whether they concern

Business Services or Framework Services, are documented in a specification that is
neutral with respect to any specific implementation technology.

Hence, the TNA must be mapped to one or more appropriate TSAs.10 These
technology-specific mappings will leverage industry standard frameworks (e.g.,
frameworks that support distributed computing, component-based architectures,
Service Oriented Architecture, etc.) as much as possible. Hence, NGOSS
deployments will benefit from the efforts to develop said frameworks.

10
Management data is inherently different – requiring different uses, query capabilities, persistence, and so forth. Hence, any
OSS will use multiple repositories. This is why multiple TNA-TSA mappings are required.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 32 of 96

The NGOSS Technology-Neutral Architecture

3. Architectural Concepts
The NGOSS metamodel [TMF-TMF053D] defines concepts that support the basic
architectural constructs defined in this document. It is an extension of the UML
metamodel, refined to support the modeling of telecommunication systems as well as
specific types of behavior (e.g., a contract) that is not present in the UML metamodel.

The NGOSS architecture provides concepts and rules for building NGOSS systems.
It is mainly focused on the NGOSS system view. As introduced in section 2.1.3, the
NGOSS architecture comprises elements from all of the RM-ODP viewpoints.

Each concept defined has a manifestation during different stages of system

development. These are as follows:
¾<concept> is the architectural element to be used in modeling, e.g. the
elements defined in the reminder of this section;
¾<concept specification> is the formal description of the <concept>, e.g. found
in the addendums of this document:
• TMF053B for Contract
• TMF053C for Behavior and Control Services
• TMF053D for Meta-Model
• TMF053F for Framework Services
• TMF053P for Policy
• TMF053S for Security;
¾<concept implementation> is a technology-specific realization of the
<concept>, e.g. using SOA;
¾<concept instance> is a runtime instance of the <concept> (if the <concept>
manifests itself at runtime), e.g. within a specific run-time environment such
as .NET, J2EE, or a CORBA ORB.
¾For example:
¾Architectural elements: each Contract (computational aspect) is associated
with exactly one Interface (engineering aspect). Each Component delivers
one or more functional Contracts.
¾Specification: each Contract specification (computational aspect) is
associated with exactly one Interface specification (engineering aspect). Each
Component specification is associated with one or more Contract
specifications.
• Implementations: each Contract implementation contains/associates
to exactly one Interface implementation. Each Component
implementation contains one or more Contract implementations,
having zero or more functional and at least one management
contract.
¾Instances: each Contract instance contains/associates to exactly one
Interface instance. Each Component instance contains one or more Contract

TMF053, Version 5.7 TeleManagement Forum 2006 Page 33 of 96

The NGOSS Technology-Neutral Architecture

instances, having zero or more non-management and at least one

management contract.

3.1. General Concepts

The following concepts collectively form the TNA. They are introduced here with their
basic definitions, and described in more detail in the following sections from a
computational aspect and from an engineering aspect.

NGOSS Contract The central concept of interoperability in the NGOSS architecture. [TMF-TMF053D]:
”An NGOSSContract provides a specification of NGOSSContractOperations and
behavior; it exposes functionality contained in an NGOSSComponent. The
NGOSSContract is of interest in all four NGOSS Views”.

NGOSS Contract
A technology specific realization (NGOSS Implementation View) of the NGOSS
Implementation
Contract requirements and specifications provided by NGOSS Business and
System View Contract parts.

NGOSS Contract This is a runtime manifestation of an NGOSS Contract Implementation that provides
Instance one or more functions to other runtime entities. It represents the unit of binding11. A
Contract Instance must be manageable.

Interface Interfaces represent functionality provided by managed software elements that

reside in a component.12

Operation This is an Interaction, through a contract Invocation, between a client Component

and a server Component that is either an Interrogation or an Announcement. These
terms are defined in ODP and [TMF-TMF053D].

Announcement This is an Interaction – the Invocation – initiated by a client Component instance,

resulting in the conveyance of information from that client Component instance to a
server Component instance, requesting a function to be performed by that server
Component instance. Announcements have similar semantics to Notifications in
other DIOAs. Reference for this definition?

Interrogation An Interrogation is similar to an Operation, except that it consists of two Interactions:

The initial Interaction – the Invocation – initiated by a client Component

instance, resulting in the conveyance of information from that client Component
instance to a server Component instance, requesting a function to be
performed by that server Component instance

A second Interaction – the Termination – initiated by the server Component

instance, resulting in the conveyance of information from the server Component
instance to the client Component instance in response to the Invocation.
11
Binding is the establishment and control of interactions between NGOSS Components.
12
Note: In reality there are intra- and inter-component interfaces

TMF053, Version 5.7 TeleManagement Forum 2006 Page 34 of 96

The NGOSS Technology-Neutral Architecture

Reference for this definition?

Interface signature This comprises a set of Announcement and Interrogation signatures, as appropriate,
one for each operation type in the interface.

Announcement This is a definition of the name of the invocation and the number, names and types
signature of its parameters.

NGOSS Component An NGOSS Component is defined as a software entity that is independently

deployable, built conforming to a component software model, and uses Contracts to
expose its functionality. An NGOSSComponent is the architectural element which is
the unit of packaging of function. NGOSSComponents must contain at least one
NGOSSExtensibleElement (Service) and also must be manageable. A Component
represents the unit of deployment in the technology-neutral architecture and offers
one or more services. (NGOSSComponent and NGOSSExtensibleElement are
defined in [TMF-TMF053D]).

NGOSS Application An NGOSS Application is a container artifact which provides an

encapsulation of the requirements, specification and implementations of
desined functionality, from the perspective of Service Providers, needed to
support a specific business goal within their operating environment.

NGOSS Service An NGOSS Service consists of one or more NGOSSExtensibleElements. An

NGOSS Service is created, deployed, managed, and torn down by one or more
NGOSSContractOperations. An NGOSS Service can either be a
CustomerFacingService or a ResourceFacingService, as defined in GB922
Addendum 4SO [TMF-GB922-4SO].

Table 3: NGOSS Essential Concepts

All five ODP viewpoints relate to NGOSS views (as explained in section 2.1.3).
However, for the NGOSS Architecture, mainly the computational viewpoint and the
engineering viewpoint are of interest. To avoid confusion, and due to the fact that the
NGOSS architecture is using and expanding the ODP views, we focus in the
following sections on the computational aspect and the engineering aspect of the
NGOSS Architecture.

3.2. TNA Computational Aspect

The TNA Computational Aspect of the NGOSS Architecture defines an NGOSS
Component as an architectural abstraction, probably best related to the concept of a
computational object within the ODP computational viewpoint. It provides design rules
that impose a standard coordination model on all Components. It defines NGOSS
Components, how NGOSS Components interact through bindings, how functionality
is exposed using Contracts, and how complex interaction behavior is modeled.
Interactions between NGOSS Components is defined by Contracts offered by
NGOSS Components and the semantic and operational relationships between
NGOSS Components specified within a Contract. Beside NGOSS Components, the
computational aspect introduces the artifacts Contract, as the fundamental concept
for offering functionality, Service, Resource, and Policy.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 35 of 96

The NGOSS Technology-Neutral Architecture

Contract
Component COM 13 COM 24 Binding
Group
Component
Contracts

Figure 4: Contracts and Components

Figure 4 shows the general concept of Contract and Components. A Component has
one or more Contracts. Each of these Contracts is used to expose functionality of the
Component. Components can be assembled into (sub) systems (or groups), whereas
in this case the (sub) system has internal (not visible to the outside) and external
(visible to the outside) Contracts. Two Components exchange information
semantically and syntactically described by one Contract. In other words,
Components are bound for the purpose of information exchange by a Contract. The
binding between Components can be implicit, e.g., realized by an underlying
framework, or explicit, e.g., realized by special Components. Policies, not seen in the
figure, are used to govern the behavior of a Component.

Note: Figure 4 shows two contracts for the communication between COM1 and
COM2. In fact, COM1is offering a function via a Contract and COM2 is using this
function, acknowledging the Contract and expecting COM1 to behave according to
the Contract specification. Similarly, COM1 expects COM2 to behave according to the
same Contract specification. This Contract Binding enables the functionality offered
by Contracts to be negotiated and agreed on. Communication between Components
is terminated when the Contract is fulfilled.

3.2.1. Contract

A cornerstone of the NGOSS architecture is its ability to define a collaborative

development and deployment environment, in which the needs of different
constituencies are seamlessly integrated. Using the NGOSS lifecycle and
methodology [TMF-GB927], the NGOSS supports all phases of the lifecycle of its
systems and components, connecting business, system, implementation, and
deployment concerns. The fundamental mechanism for doing this is the NGOSS
Contract; the methodology for doing this is to support the evolution and morphing of
NGOSS Contracts and the knowledge that they contain. In the reminder of this
section, the term Contract refers to NGOSS Contracts. Detailed definitions for an
NGOSS Contract from an architectural point of view can be found in [TMF-
TMF053B]. Detailed definitions of an NGOSS Contract from an information viewpoint
can be found in [TMF-GB922-1C].

The purpose of a Contract is to enable information to be shared between NGOSS

Components. This includes the definition of how all types of data and knowledge is
shared, including Services, Resources, and the behavior that is expected when one
Component participates in a Contract with another Component. This inter-
Component behavior is expressed by a set of obligations and benefits. Mechanically,
it includes the registering and invoking of functionality, using this functionality, and
exchanging of information between the components. It also includes how the
Components in the Contract communicate with other entities.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 36 of 96

The NGOSS Technology-Neutral Architecture

It is very important to note that a Contract is not a static entity. This would prevent the
system from flexibly changing its responsibilities. Furthermore, we never want to lose
contract information, since if we do, we lose insight and traceability.

Thus, an NGOSS solution is built on multiple Contracts (e.g., one Contract can have
multiple forms over time). This is an important design decision to support the different
constituencies with their individual needs, expressed by different grammars,
concepts, and design parameters. Therefore, one Contract alone cannot satisfy the
needs of different stakeholders.

A Contract is designed to morph into different forms, having different content, based
upon the particular set of stakeholders that are using the Contract at a particular time.
Note that this provides built-in traceability as well as documentation for how the
Contract evolves through the lifecycle of the solution.

The Contract, throughout each manifestation in the four NGOSS views, supports
information for that view, combined with information from other applicable phases, in
a structured yet extensible form. Each Contract supports information specific to an
NGOSS view, association with information from previous lifecycle phases, and
information and data that document its functionality, its dependencies, and the
environment in which it ‘lives’. A Contract is made up of five parts (regardless of the
NGOSS view in which it is being used):
¾The Header portion of the Contract identifies each contract instance in an
unambiguous way, and hosts a placeholder for a textual description of the
Contract.
¾The Functional Part of the Contract defines the capabilities provided by the
Contract, constraints placed upon the use of those capabilities, and the
context in which it can be used.
¾The Management Part of the Contract defines the management requirements
needed to operate the functional capabilities of the Contract, assesses its
resource and service cost, assigns QoS, describes geographic, resource, and
operational constraints, and describes the legal constraints of the Contract.
¾The Non-Functional Part of the Contract defines aspects needed for proper
operation of the capabilities specified by the Contract (e.g., security and
management operations), as well as other considerations (e.g., cost).
¾The Model Part of the Contract contains various types of UML models to
support the specification and description of the Functional and Non-
Functional parts. This part supports the lifecycle management of the service,
and any resources required to configure and maintain that service, in an OSS
architecture. In a nutshell, it enables our approach to be self-documenting and
self-describing.

3.2.2. Component

The NGOSS Component is an architectural element that supports one or more

Contracts; an NGOSS Component represents the unit of deployment in the
technology-neutral architecture. NGOSS Components are therefore, from the

TMF053, Version 5.7 TeleManagement Forum 2006 Page 37 of 96

The NGOSS Technology-Neutral Architecture

minimalist point of view, containers of contracts (and in the engineering aspect

containers of contract implementations).

The NGOSS Component is a container for at least two types of contracts:

¾Contracts that represent non-management functions of the component
¾Contract used to manage the functions of the component;
This distinction avoids dictating which contracts the developer of an individual
component is required to implement. The individual component developer may
implement those contracts that represent the functionality of their product, be it a self-
contained service quality management component (which could be represented by
single contract), or an end-to-end customer care system (which could be represented
by multiple contracts).

The behavior the artifacts contained within an NGOSS Component within the
NGOSS System must be manageable. The behavior of an NGOSS Component with
respect to any other NGOSS Component must be governed by at least one
Contract. Some NGOSS Components may achieve this manageability by supporting
a standard management Contract in addition to any supported non-management
Contracts.

An NGOSS Component can be further categorized into an NGOSS Framework

Service Component and/or an NGOSS Business Service Component including
Mandatory Business Service Components.
¾An NGOSS Framework Service Components (FSC) implements one or more
fundamental infrastructural services within the NGOSS that enable the
features of the NGOSS architecture (i.e. the distribution transparency
framework Services specified in [TMF-TMF053F]) to be realized.
¾An NGOSS Business Service Component (BSC) provides services that
support the business-related functionality of the NGOSS architecture, such as
billing, rating and discounting, network data management, and others. A
Business Service Component may contain either Core Business Services
(e.g., Policy, Security, Process, and Mediation) or general Business Services
(e.g., billing and reporting).
¾NGOSS Mandatory Business Service Components cover the mandatory
Process, Policy and Security services.

3.2.3. Service

A Service within the NGOSS Architecture supplies functionality made available by a

Component through one or more Contracts.

3.2.4. Resource

A Resource is a physical or logical managed entity that is part of a component.

Resources are related to Products, and are used to host or implement parts of a
Service within a Component.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 38 of 96

The NGOSS Technology-Neutral Architecture

3.2.5. Policy

A Policy is a set of rules that are used to manage and to control the changing and/or
maintaining of the state of one or more Components. Policy-based Management
controls the state of the NGOSS system and Components within this system using
policies. Control should be realized using a management model such as a finite state
machine. Note that the emphasis is on “changing and/or maintaining of the state” of a
set of Components! This enables behavior to be choreographed.

Similar to Contracts, Policies are combined to form a continuum. This is necessary in

order to relate the needs of different stakeholders to a common problem. The solution
provided by this approach, again similar to the concept of Contract, is to define a
continuum of policies that enable business, system, implementation, and deployment
concepts to be related to each other.

To give an example: the business view defines the overall goals of an organization
and expresses business policies in business language. The system view takes this
specification and translates it into technology- and vendor independent terminology.
See [PBNM] for more information.

3.2.6. Operation

An operation within a Contract is the interaction mechanism by which functionality or

parts of functionality are offered by a Component. Two types of operations are
identified: Announcements and Interrogations. All operations are non-blocking. Within
a DIOA, the order of delivery is significant, so this order must be guaranteed between
different invocations.

An Announcement is initiated by the service offering Component, where the service

offering Component sends information to the Component requesting service without
that Component replying. Usually, delivery of Announcements is not guaranteed
(e.g., it is best-effort).

An Interrogation comprises two phase of communication; the invocation of this

operation from the service requesting Component (Invocation) and the response from
the service offering Component (Termination). Usually, the service offering
Component will perform some internal tasks before terminating an Interrogation.

3.3. TNA Engineering Aspects

The TNA Engineering Aspect defines NGOSS Component as an engineering
concept, probably best related to the concept of an engineering object within the ODP
engineering viewpoint. The engineering aspects of the TNA provide a framework for
developing engineering specifications, enabling TNA Components to communicate
based on an abstracted infrastructure – the Common Communication Vehicle.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 39 of 96

The NGOSS Technology-Neutral Architecture

3.3.1. Engineering Aspects of an NGOSS Component

The left side of Figure 5 shows a group of NGOSS Components with their Contracts
(computational aspect). The right side of Figure 5 shows an engineering
representation of an NGOSS Component. The core object, optionally supported by
one or more additional objects for legacy integration, offers its services via a contract
instance and an interface object. The contract instance is an engineering
representation of an NGOSS Contract. The interface object provides the platform
specific means to interact with the other Component participating in the Contract.

NGOSS Components NGOSS Component

(computational aspect) engineering aspect)

Contract Core
COM 1 COM 2 Instance Object

Interface
Component Object
Group Legacy
Integration
NGOSS Contracts Hardware and
Software

Figure 5: Engineering Representation of an NGOSS Component

Figure 6 shows how an NGOSS Component can be developed using the above
described concept. The component’s core object(s) are supported by interface
objects and contract interfaces. Each interface might be bound to one or more
contract instances. This allows having multiple views (by means of different
Contracts) to one function via the same interface. One contract is only bound to one
interface.

NGOSS Engineering Object

Control
computational Interface Contract Interface
contract Object In Instance C n
engineering Component
operational Core Object
interface Interface Contract
programming Object I1 Instance C 1
language
interface NGOSS Component

Figure 6: Engineering Representation of an NGOSS Component

The component’s core object might offer a control interface that enables its
configuration and management.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 40 of 96

The NGOSS Technology-Neutral Architecture

3.3.2. Object Communication and Binding

The communication between components can be divided into three different layers.
As Figure 7 shows, the first layer describes the relationships between the core
objects of a Component. These objects exchange information by means of messages
or operation calls to realize the functionality that the Contract defines. The second
layer models the transmission of messages and/or operation calls between Contract
objects. The third layer is dedicated to the employed middleware and the middleware
specific protocol(s). Further layers are not needed since the middleware protocol
already abstracts the underlying network transport protocols.

Messages / Calls
Core Object Core Object
COM1 COM2

Contract Contract

Interface I1 Middleware / Management Protocol Interface I2

Channel
Control Stub
Function
Binder

Protocol
Adapter

Figure 7: Object Communication and Binding

This approach can be compared to the Reference Model for Open Systems
Interconnection (RM-OSI; [ITU-X200]). The layers are independent of each other.
Protocol services are offered via Service Access Points (SAPs), which are called
interfaces here. A TNA protocol is then the combination of the Components interfaces
and the interaction schemes that are defined by the Components services and
governed by the Components Contracts. The interface can be specified in
middleware generic or middleware specific way (e.g. CORBA-IDL). Figure 7
furthermore depicts an engineering representation of an explicit binding. The TNA is
adopting principles here based on ODP and further developed by TINA in the
Engineering Modeling Concepts [TINA-EMC].

TMF053, Version 5.7 TeleManagement Forum 2006 Page 41 of 96

The NGOSS Technology-Neutral Architecture

4. NGOSS Technology Neutral Architecture Specification

4.1. Overview
This section provides unambiguous definitions for terms used throughout the
remainder of this document (and its annexes) in the definition of the architecture. The
reader should beware of attributing colloquial semantics to these terms when
reading the remainder of the document; architectures require formal and
unambiguous definitions of terms in order to remain complete and correct; attributing
inappropriate semantics to one or more defined terms will usually destroy the
correctness of the architecture. This section will provide incremental definitions of the
artifacts needed to build an NGOSS system as illustrated in Figure 8.

Location Registration Repository Naming Mandatory

Service Service Service Service Framework
Services
Contract Inst. Contract Inst. Contract Inst. Contract Inst.
Int. Mech. Int. Mech. Int. Mech. Int. Mech.

Common Communications Vehicle

Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech.
Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst.
Policy Process Security Service Service
Service Service Service
Legacy
Application
Other Mandatory Services

Figure 8: NGOSS Technology Neutral Architecture Detailed View

At the most fundamental level, an NGOSS system is composed of three types of

inter-operating capabilities: Framework Services supporting distribution and
transparency, Mandatory Services supporting decision, sequencing and security, and
the general Business Services being provided by the NGOSS Solution. This high-
level view of an NGOSS Solution is illustrated in the diagram presented in Figure 9.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 42 of 96

The NGOSS Technology-Neutral Architecture

NGOSS
Framework Services

Common Communications Vehicle

Other mandatory Business

NGOSS Services Services

Figure 9: NGOSS Technology Neutral Architecture High Level View

Underlying this basic view is a number of software constructs or artifacts that are
essential to the construction of the NGOSS Technology Neutral Architecture.

4.2. NGOSS TNA Artifacts

The following sections provide a formal definition of software artifacts for the NGOSS
Architecture. NGOSS Artifacts are classified as either Core Artifacts (i.e., those that
basic units of composition in the NGOSS Architecture) or Container Artifacts (i.e.,
those that encapsulate or package core artifacts). Realizations/instantiations of every
NGOSS Artifact must be manageable by the NGOSS System in which the Artifact is
deployed. Manageability is defined to be, at a minimum, the ability (within the
execution environment of a deployed NGOSS System) to:

1) Deploy a new NGOSS Artifact,

2) and, Remove a previously deployed NGOSS Artifact.

In addition, all NGOSS Software Artifacts capable of being instantiated in the Run-
Time/Deployment view (i.e., Application, Service, Policy, Process and Contract) must
be supported by the ability to:

1) Advertise a previously deployed NGOSS Artifact,

2) Withdraw an advertised and deployed NGOSS Artifact,

Extensions and additions to the basic manageability functionality are allowed.

4.2.1. NGOSS Core Artifacts

The NGOSS Core Artifacts are the basic software building blocks of the NGOSS
Architecture. They represent the fundamental software elements of which every
solution that is architected, designed and built to the NGOSS Architecture is
composed.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 43 of 96

The NGOSS Technology-Neutral Architecture

NGOSS Information Model

The NGOSS Information Model defines the information/data reference model and the
common information/data vocabulary from a business as well as a systems
perspective. The NGOSS Shared Information/Data Model (SID) is the NGOSS
Information Model. The SID provides a knowledge base that describes the behavior
and structure of business entities and their collaborations/interactions. The Business
View of the SID is specified in [GB922] and Addenda. The System View of the SID is
specified in [GB926] and Addenda.

NGOSS Process

An NGOSS Process is a flow of linked activities or functionality through a solution

developed and deployed consistent with the NGOSS Architecture. The eTOM
[GB921] provides detailed descriptions of processes that have been identified to
support management of communications environments in a solution designed,
architected and developed according to NGOSS principles. Combined with NGOSS
Policies, NGOSS Processes provide the means to manage the behavior of an
NGOSS System.

NGOSS Policy

An NGOSS Policy is a set of rules that can be used to manage and control the
behavior of an NGOSS Artifact. Specifications for NGOSS Policies can be found in
[GB922-POL] Combined with NGOSS Processes, NGOSS Policies provide the
means to manage the behavior of an NGOSS System.

NGOSS Contract

The NGOSS Contract is “the central concept of interoperability in the NGOSS

architecture” [TMF-TMF053D]. That is, the NGOSS Contract is the fundamental unit
of interoperability in NGOSS. An NGOSSContract provides a specification of
NGOSSContractOperations and behavior; its instantiation exposes functionality
contained in an NGOSSComponent. The NGOSSContract is a structure which is of
interest throughout the NGOSS Lifecycle, providing a container to relate Business,
System, Implementation and Run-time/Deployment View information. Thus, the
Contract is not only the fundamental unit of interoperability, but the key to providing
traceability throughout the NGOSS Lifecycle. These four related views are: the
NGOSS Contract Requirements, the NGOSS Contract Specification, the NGOSS
Contract Implementation and the NGOSS Contract Run-Time Instance. Further
information about Contracts and the NGOSS Lifecycle can be found in [GB927]. A
detailed discussion of Contracts and their use within the NGOSS Architecture can be
found in [TMF053b]. The formal specification of the Business View of the NGOSS
Contract can be found in [GB922-1C], and the System View in [GB926-1C].
NGOSS Contract Requirements

The NGOSS Business View Contract (NGOSS Contract Requirements) provide a

description of the needs of a particular capability (or capabilities) that are offered by

TMF053, Version 5.7 TeleManagement Forum 2006 Page 44 of 96

The NGOSS Technology-Neutral Architecture

Contract provider(s) and used by Contract consumer(s). A detailed specification of

the NGOSS Business View Contact can be found in [GB922-1C].
NGOSS Contract Specification

The NGOSS Contract Specification (or NGOSS System View Contract) is a

technology neutral specification of the functionality of a Contract detailed in the
NGOSS Business View (NGOSS Contract Requirements). It provides an
architectural, or System, specification of the requirements covering functionality of a
Contract, pre-conditions required prior to executing the Contract, post-conditions
required subsequent to Contract execution, and technology neutral architectural
constraints imposed on the contract. A detailed specification of the NGOSS System
View Contract can be found in [GB926-1C].
NGOSS Contract Implementation

The NGOSS Contract Implementation is an Implementation View manifestation of a

Contract. The NGOSS Contract Implementation provides a realization of the
requirements and specification of the Business and Systems Views for a specific
technology, that is to say it is the Technology Specific manifestation of the
Technology Neutral Contract specification.

NGOSS Contract Implementation Instance

The NGOSS Contract Implementation Instance (or more commonly Contract

Instance) is a run-time manifestation of a Contract Implementation that provides
functionality to other run-time entities. It represents the unit of binding and thus an
NGOSS Contract Instance is specific to the run-time environment in which it is
instantiated. Since NGOSS can be implemented using a wide number of run-time
environments, the NGOSS TNA does not proscribe how or when the Contract
Instance is created.

All NGOSS Contract Instances MUST be manageable. Manageability may be

provided by one of two methods: or
¾Explicitly, where a Contract Instance providing manageability is included in
the same NGOSS Component ,
¾Implicitly, where manageability is provided by external functionality provided
by the distribution environment in which the Component is deployed.
If Contract Implementations are managed implicitly, the NGOSS Component MUST
provide the information needed to manage the Contract Implementations it packages
to the external functionality. The information needed to either register and initialize
explicit Contract manageability functionality included in the Component or to register
the Contracts packaged within a Component with external functionality must be
provided in a Component Content Information Block (CCIB).

Further details about Manageability will be provided in the annex [TMF-TMF053U],

which will document Manageability for NGOSS artifacts.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 45 of 96

The NGOSS Technology-Neutral Architecture

NGOSS Contract Concepts

NGOSS Contract Operation

An NGOSS Contract Operation is an interaction, through a Contract invocation, between a client

(requesting) Contract Instance and a server (providing) Contract Instance. An NGOSS Contract
Operation Must be either an Interrogation or an Announcement.
Announcement

An Announcement13 is defined to be an interaction that must consist of:

¾An Invocation – initiated by a client (requesting) Contract Instance, resulting in
the conveyance of information from that client (requesting) Contract Instance
to a server (providing) Contract Instance, requesting a function to be
performed by that server (providing) Contract Instance.
Announcement Signature

An announcement signature is the definition of the name of the Announcement

invocation and the number, names and types of its parameters.

Interrogation

An Interrogation14 is defined to be an interaction that must consist of:

¾The initial interaction – the Invocation – initiated by a client Contract Instance,
resulting in the conveyance of information from that client Contract Instance to
a server Contract Instance, requesting a function to be performed by that
server Contract Instance.
¾A second interaction – the Termination – initiated by the server Contract
Instance, resulting in the conveyance of information from the server Contract
Instance to the client Contract Instance in response to the Invocation.
Interrogation Signature

An Interrogation signature is the definition of the following elements:

¾The name of the Interrogation invocation,
¾The number, names and types of the Interrogation invocation parameters,
¾A finite, non-empty set of definitions, one for each possible Termination type
of the Interrogation invocation; each definition contains the name of the
Termination and the number, names and types of its parameters.

4.2.2. NGOSS Container Artifacts

13
Announcements have similar semantics to Notifications in other DIOAs.
14
An interrogation is similar to an operation, in which the client requests that something be done, and the server responds
with information that results from performing the request.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 46 of 96

The NGOSS Technology-Neutral Architecture

Building upon the NGOSS Core Artifacts, the NGOSS Architecture defines three
Container Artifacts which are used to package or encapsulate the NGOSS Core
Artifacts. Two of the NGOSS Container Artifacts, the NGOSS Application and
NGOSS Component are common to any solution designed to NGOSS principles
(whether DIOA oriented or SOA oriented). The third Container Artifact, the NGOSS
Service, is introduced specifically to specialize a solution as constructed using a
Service Oriented Architecture approach.

NGOSS Application

An NGOSS Application is a Container Artifact which, at the discretion of a Service

Provider, defines, models and provides the capabilities needed to support a specific
business goal within their operating environment. NGOSS Applications have
presence throughout the NGOSS Lifecycle. The Logical View of an NGOSS
Appliation provids a container for business requirements and technology neutral
NGOSS Application (General Part)
General Application Functional Sequencing Application Information
Policy Specifications Specifications (from eTOM) Model (SID based)

NGOSS Contract
Specification
B
NGOSS Contract NGOSS Contact NGOSS Contract
Specification Specification Specification
A NGOSS Contract D E
Specification
C

NGOSS Application (SP Specific Part)

SP Specific Functional Information Extended
Application Policies Sequence Extensions Model Extensions Functionality

specifications. The Physical View provides a container encapsulating functionality

delivered by software vendors and the Processes and Policies needed to manage the
behavior of this functionality, to deliver capabilities that meet the specific goals
specified by the Logical View of the NGOSS Application. An NGOSS Application can
reference (and thus ‘contain’) other NGOSS Applications.

Figure 10: NGOSS Application

An NGOSS Application is composed of two parts:

¾ General Part – Generic part of the Application common to all Service

Providers. The NGOSS Application General Part includes:

ƒ NGOSS Policies relating to the deployment, configuration, operation

and manageability of the Application,

TMF053, Version 5.7 TeleManagement Forum 2006 Page 47 of 96

The NGOSS Technology-Neutral Architecture

ƒ NGOSS Flows (or references to flows described in the eTOM) the

sequence the functionality specified by the Application,

ƒ A reference to the portions of the NGOSS Shared Information/Data

Model (SID) used within the Application specification,

ƒ Contracts which provide technology neutral descriptions of the

interfaces of the functionality specified by the Application. The
Contract Specifications must be in the form specified by the NGOSS
System View Contract Specification [GB926-1C].

¾ Specific Part – Extensions to specialize a generic Application specification to

a particular Service Provider. The NGOSS Application Specific Part may
include:

– NGOSS Policies specific to the environment, configuration, business

plan,

– NGOSS Contracts that extend functionality beyond that general

Application Specification,

– Extensions to the NGOSS Information Model (if needed) to support

extended functionality,

– Variations to Functional Sequencing to accommodate extended

functionality.

NGOSS Component

The NGOSS Component15 is an architectural element that packages, at the

discretion of software developers, one or more Contracts; a Component represents
the unit of deployment in the technology-neutral architecture. NGOSS Components
are therefore, from the minimalist point of view, containers of Contracts from the
perspective of the software developer. To instantiate Contracts, there is an execution
environment that, using Contract Implementations and information packaged by a
Component, creates Contract Instances. An NGOSS Component can contain or
encapsulate other NGOSS Components.

The NGOSS Architecture focuses on the Contract as the fundamental unit of

functional specification, defining interfaces and interface behaviors. Whereas the
NGOSS Application focuses on desired functionality from the perspective of a Service
Provider, the focus of the NGOSS Component is as a physical container of delivery
for Contract Implementations (ie., a Software Vendor’s or System Integrator’s
perspective). The Application, Component and the Contract have a lifecycle that is
linked to the NGOSS Lifecycle:

15
a.k.a. Component

TMF053, Version 5.7 TeleManagement Forum 2006 Page 48 of 96

The NGOSS Technology-Neutral Architecture

¾Business Applications, Components and Business Contracts are logical

entities that can not be directly instantiated. They are high-level requirements
that are suitable for use in business analysis and the RFx process.
¾System Applications, Components and System Contracts are also logical
entities that exist only within the context of the system Computational model.
They are technology neutral system level specifications of the requirements
provided by the Business View of Applications, Components and Contracts.
¾Application Implementations, Component Implementations and Contract
Implementations have both a physical and logical existence. That is, they
exist as part of the models associated with the Implementation View, and also
exist as physical, deployable entities. Being more precise, in the
Implementation View, a Component that contains Contract Implementations
comes into existence. One or more Component Implementations are mapped
together with applicable processes and policies to yield an Application
Implmentation, The Component Implementation is deployable.
¾In the Deployment View, the Component has been deployed into a running
system, and the Contract Implementation is used by the execution
environment to create instantiations of the Contract Implementation that can
be accessed at runtime by other functionality to provide value-added
functionalities that support the mission of the business.
In addition to NGOSS Contract Implementations, the Component must provide
information about the contents packaged within the Component to the NGOSS
Distribution and Transparency Framework so that the NGOSS Contracts contained
within the Component can be registered and thus become locatable and any Policies
contained within the Component can be registered with the Policy Management
Service. This information is called the Component Content Information Block.

An NGOSS Component must:

¾Be installed as a single unit (that is partial installations are not permitted.)
¾Be removed as a single unit (that is upon removal of a Component, all
artifacts contained within the Component are removed). Prior to removal, all
NGOSS Contract Instances instantiated from NGOSS Contract
Implementations packaged within the Component must be made unavailable.
¾Contain at least one value-added functionality NGOSS Contract
Implementation That is, the Component must provide at least one capability
adding value to the environment within which the Component is deployed.
This capability must be accessible externally to the Component.
¾Provide a Component Content Information Block. The Component Content
Information Block contains the details to either:
¾Register Manageability Contract Implementations and to instantiate and
register Manageability Contract Instances from the Manageability Contract
Implementations packaged within the Component if explicit manageability is
implemented. (This information may be accessible manually or automatically
depending upon the deployment environment), or

TMF053, Version 5.7 TeleManagement Forum 2006 Page 49 of 96

The NGOSS Technology-Neutral Architecture

¾Register and instantiate the valued-added functionality Contacts packaged

within the Component with the external execution environment (if implicit
manageability is selected).
¾Provide details to register the value-added functionality Contract
Implementations packaged within the Component. These details are
contained either within the associated Manageability Contract Implementation
or within the Component Content Information Block.
¾Provide details needed to instantiate one (or more) value-added functionality
NGOSS Contract Instance for each value-added functionality Contract
Implementation.
¾Have each NGOSS Contract Implementation packaged within the
Component registered in the Repository. (Note: Component could also
package “Private” Contract Implementations, i.e., NGOSS Contract
Implementations that are neither visible nor available outside a very limited
closed domain. “Private” Contact Implementations may optionally be
registered in the Repository.
¾Have each active NGOSS Contract Instance instantiated from a NGOSS
Contract Implementation packaged within the Component registered in the
Repository. (Note: Registration for “Private” Contract Instances is also
optional).
An NGOSS Component may:
¾Package one or more Policies related to the operation of the NGOSS
Contract(s) packaged within the Component. If the Component packages
Policies, the information needed to register these Policies with the NGOSS
Policy Service must be contained within the Component Content Information
Block.
Component Packaging

The decision of what NGOSS Contracts to include in an NGOSS Component is left to

Component developer. Thus, developers are free to compose NGOSS Components
in the way that is most applicable to their business needs and products. Sample
packaging might include:
¾A single functioned implementation offering a single NGOSS Contract (e.g.,
billing record format normalization),
¾A multi-functioned implementation offering a single NGOSS Contract (e.g.,
self-contained service quality management system),
¾A multi-functioned implementation offering multiple NGOSS Contracts (e.g.,
an end-to-end customer care system),
¾A multi-functioned implementation offering multiple NGOSS Contracts and
one or more Polcies, or
¾A complex Component packaging all of the previous examples.
While an NGOSS system can be built and deployed to perform many different tasks,
all NGOSS environments must contain certain capabilities to support the distributed,

TMF053, Version 5.7 TeleManagement Forum 2006 Page 50 of 96

The NGOSS Technology-Neutral Architecture

open nature of the environment. Thus, NGOSS components are categorized into two
types:
¾Components packaging capabilities mandated by the NGOSS Architecture
that must have:
• NGOSS Distribution and Transparency Framework Services as
defined in TM053f (Registration, Location, Repository, Naming, and
Federation),
• NGOSS Mandatory Services including Process Management, Policy
Management and Security Management
¾And, Components packaging capabilities that support the value-added
business-related functionality of solutions implemented using the NGOSS
architecture, such as billing, rating and discounting, network data
management, and others.
The packaging of mandatory capabilities with value-added business-related
functionality in the same Component is strongly discouraged as it has the potential to
lead to accidental removal of NGOSS mandatory services required by the NGOSS
Architecture.

As described in Sections 2 and 3, NGOSS is a DIOA and can be implemented as a

number of specific architectures including DIOA, SOA, object-oriented architecture
and resource-oriented architecture. The following sections describe an NGOSS
Component from the DIOA and SOA perspective. In either approach, the basic unit of
functionality and interaction in NGOSS is the NGOSS Contract. The difference
between the two approaches is the encapsulation of NGOSS Contracts.
NGOSS Component - DIOA Perspective

In a DIOA approach, the NGOSS Component is the basic unit of encapsulation.

Thus, an NGOSS Component in a DIOA environment has the following structure:
¾The NGOSS Component must package one or more NGOSS Contract
Implementations.
¾The NGOSS Component must also contain a Component Content
Information Block that is accessible by the deployment environment (this can
be either manually readable or automatically readable). The Component
Content Information Block provides a list of all NGOSS Contract
Implementations and Policies packaged within the Component and provides
the information needed to register, instantiate and activate all Manageability
Contracts packaged within the NGOSS Component. Information to register,
instantiate and activate (and de-activate and de-register) the value-added
functionality Contracts will be contained in their respective Manageability
Contracts.
An NGOSS Component in a DIOA environment is depicted in Figure 11.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 51 of 96

The NGOSS Technology-Neutral Architecture

NGOSS Component

Contract Contract
Implementation Implementation
1 or more
Contract Implementations

Component
Content
Information

Figure 11: NGOSS Component DIOA Perspective

NGOSS Component - SOA Perspective

Implementing NGOSS using an SOA approach introduces an additional level of

encapsulation; the NGOSS Service. In contrast to the DIOA approach, where the
Contract is the basic unit of both functionality and manageability, in an SOA
implementation, the Contract remains the basic unit of functionality, but value-added
functionality Contracts are grouped together and managed as a unit or NGOSS
Service. Thus, in an implementation of NGOSS using a SOA approach the basic unit
of Manageability is the NGOSS Service. In an SOA implementation, an NGOSS
Component must contain at least one NGOSS Service.

Figure 12 illustrates an NGOSS Component implemented using a SOA.

NGOSS Component

Service Service
1 or more Services

Component
Content
Information

Figure 12: NGOSS Component SOA Perspective

TMF053, Version 5.7 TeleManagement Forum 2006 Page 52 of 96

The NGOSS Technology-Neutral Architecture

NGOSS Service

An NGOSS Service (either CustomerFacingService or ResourceFacingService

as defined in the SID GB922 and Addenda) is the NGOSSExtensibleElement of
one or more NGOSSContractOperations managed as a single unit. A Service is the
primary unit of manageability for capabilities in an NGOSS environment implemented
as an SOA. Figure 13 provides an illustration of an NGOSS Service. Note that Figure
13 shows an NGOSS Service containing 2 or more Contracts; one must be the
Manageability Contract for the Service, the remaining one(s) are the value-added
functionality Contract Implementations (NGOSSContractOperations), and at run-time
Contract Instantiations, managed by as a unit by the NGOSS Service.

The decision of which Contract Implementations to manage as a single unit (and thus
NGOSS Service) is left to the developer, so long as each Implementation and
Instance has an associated Manageability Contract.

An NGOSS Service must:

¾Be packaged within a single NGOSS Component. That is, an NGOSS
Service cannot provide Manageability for Contract Instances outside either
the Service or the Component that packages the Service.
¾Contain at least one value-added functionality Contract Implementation That
is, the Service must provide at least one capability adding value to the
environment within which the Service is deployed. This capability must be
accessible externally to the Service.
¾Must be manageable as a single entity.

Services

Contract Contract
Implementation Implementation
1 or more
Contract Implementations

Figure 13: NGOSS Service

Services Required by the NGOSS Architecture

The NGOSS TNA mandates two types of capabilities: functionality needed to provide
the distribution and transparency required for its distributed nature and functionality
needed control and coordinate the actions of an NGOSS solution; if they are
performed, the environment they are performed in, and the sequence in which they
are performed. The former are called NGOSS Framework Services. The later, whose
requirements were outlined in Sections 2.3.3, 2.3.4 and 2.3.5 are referred to as
NGOSS Mandatory Services.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 53 of 96

The NGOSS Technology-Neutral Architecture

NGOSS Framework Services

The NGOSS Framework Services provide the infrastructure necessary to support the
distributed nature of the NGOSS TNA. The following section provides a brief
introduction to these capabilities; further details may be found in a Annex to this
document [TMF-TMF053F] NGOSS Distribution and Transparency Framework
Services. Figure 14 provides a high-level pictorial representation of the NGOSS
Framework Services.

Repository

Naming Services

Location Services Registration Services

Specifiers
Components Designers/Developers
and Administrators

Figure 14: NGOSS Framework Services

Registration Service
The NGOSS Registration Service provides for services and functionality needed to
support location transparency in the system. The entities within an NGOSS System
that are considered to be of interest from an architectural view are:
¾The NGOSS System Repository,
¾Entries that identify important Shared Information, which includes Contracts,
Processes and Policies,
¾Contract Registrations,
¾Component Content Information Blocks, and
¾Contract Instance Registrations
The NGOSS System Registration Service provides a maintenance interface (for the
addition, modification, deletion and browsing of Components, Contracts and Contract
Instances) to the NGOSS System Repository (assumed to be a single logical
repository, possibly comprised of a federation of separate physical repositories). The
information contained in the Repository includes instructions on where the entities

TMF053, Version 5.7 TeleManagement Forum 2006 Page 54 of 96

The NGOSS Technology-Neutral Architecture

specified above are located and how they can be accessed and/or invoked. The
access and invocation of this information is done through a Service Location
Framework service; the direct access to the Repository browse functionality can be
used by designer or administrators

Repository Service
The heart of the Distribution Transparency Framework Services is the Repository,
which provides a logical view of all the information about deployed distributed system.
Information contained in the Repository includes registration information for each
business process, policy, Component, Contract Implementation and Contract
Instance deployed within the deployment scope of the repository and the advertising
information for each Contract Instance. Registration information for the Distribution
Transparency Services themselves is also included as they too are realized as
Contract Instances. In addition, the Repository contains all security and policy
information associated with each Component, Contract, and Contract Instance.
Although the Repository is often represented as a single instance of a database, this
is simplification for illustrative purposes. The Repository should be viewed as a logical
illustration and thus may be implemented as a single database, a group of
cooperating peer databases, or a hierarchical group of interoperating databases.

Naming Service
The Naming Service is responsible for generating and resolving unique names for the
various entities (Business Processes, Components, Contracts and Contract
Instances) contained in the Repository. The Naming Services interact with the
Registration Services at the time of Component Installation, Contract Registration and
Contract Instance Advertisement to assign an identifier that will be used to access,
modify, and/or remove the Component, Contract or Contract Instance from the
NGOSS system environment, with the Contract Instance Location Services at the
time of Contract Instance Location to resolve identified service names into its current
location, and with the browsing services supported by the Repository.

Location Service
Location Services, often built on Naming Services, provide a means to map a request
for an object to a particular instance of that object. The NGOSS Location Service
([TMF-TMF053F] currently describes a specialization, the Contract Instance Location
Service) is used at run-time to decouple the “hard binding” of consumers and
providers to facilitate distribution transparency and the location of available objects
within an NGOSS system.
Other Mandatory NGOSS Services

Further discussion of the NGOSS Process and Policy Management Services may be
found in [TMF-TMF053C]. [TMF-TMF053S] provides additional information about
NGOSS Security and details about the NGOSS Policy Management Architecture will
be documented in [TMF-TMF053P].

Policy Management Service

The NGOSS Policy Management Service acts as a supervisor of actions being

carried out by all capabilities implemented in an NGOSS system. Hence, the Policy

TMF053, Version 5.7 TeleManagement Forum 2006 Page 55 of 96

The NGOSS Technology-Neutral Architecture

Management Service can apply constraints and/or conditions on what operations are
executed, as well as when, by whom, and how they are executed, within an NGOSS
system. These constraints can be used to impose regulatory, business, enterprise or
local rules on processing sequences and conditions that are required to be met
before (i.e., pre-conditions) and after (i.e., post-conditions and exceptions) any action.

Process Management Service

The Process Management Service acts as a conductor or coordinator of activities

spanning across the NGOSS Components implementing the Business Services. This
Service provides the externalized process control that has been mandated by the
NGOSS Service Provider stakeholder. The Process Management Service ideally
executes logic expressed using a means that is different from the implementation
language used for the Component. This makes it easier to rearrange and/or alter the
business process steps, and then have the Process Management Service rearrange
the interaction between the Contract Implementation Instances (if necessary). There
may be multiple such Process Management Services within an NGOSS environment,
each one used at multiple levels of abstraction in implementing the control structure
of a system.

Security Management Service

Security is an essential ingredient in the development of NGOSS systems and should

not be considered an item that can be incorporated into a solution at a later date.
Rather, Security capabilities must be pervasive throughout the whole NGOSS
environment and must be woven into NGOSS system solutions from the outset. The
NGOSS Security Management Service provides the infrastructure to support the
security requirements for an NGOSS system as documented in [TMF-TMF053S].
¾

4.3. NGOSS Domain

At this point we have defined the artifacts necessary to build the NGOSS domain first
depicted at the beginning of this Section. Figure 15 shows the build-up and includes a
depiction of a legacy application with some (or all) of its capabilities encapsulated with
Contract Instance (and Implementations) to allow transparent access by NGOSS
client and provider Contract Implementations. The Figure also illustrates the NGOSS
Repository and shows a sample of the type of information that could be contained in
the Repository. This information includes: Shared Information, Component Content
Information, Contract Information, Contract Implementation Information, Contract
Instance Information, Policies, Process, Security Information, Manageability
Information, etc.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 56 of 96

The NGOSS Technology-Neutral Architecture

Shared Component Service Contract Contract Instance

Processes Policies
Information Registrations Registrations Registrations Registrations
Repository

Location Registration Repository Naming Mandatory

Service Service Service Service Framework
Services
Contract Inst. Contract Inst. Contract Inst. Contract Inst.
Int. Mech. Int. Mech. Int. Mech. Int. Mech.

Common Communications Vehicle

Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech.
Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst.
Policy Process Security Service Service
Service Service Service
Legacy
Application
Other Mandatory Services

Figure 15: NGOSS Technology Neutral Architecture Detailed View

4.4. Interoperation of NGOSS Domains

One of the goals of NGOSS is to facilitate the interoperation of multiple domains.
Such a requirement could be as the result of interoperability agreement between two
enterprises, an acquisition, or requirement for interoperability between two different
technology domains. To achieve interoperation, NGOSS defines a concept called
Federation. The following section provides an overview of the NGOSS Federation
capabilities which are further detailed in [TMF-TMF053F] Distribution and
Transparency Framework Services. If the two domains are fully NGOSS conformant
(i.e., each domain implements all of the Mandatory Framework Services, the other
Mandatory NGOSS Services, conforms to either the DIOA or SOA implementation
model, and utilize Data Models that are semantically equivalent and exchangeable to
the NGOSS SID Information Model, then interoperation between the domains is fairly
straight-forward. In this case, the interoperation would require the specification and
development of the details of the Federation (e.g., policies for each side documenting
rules for visibility and access) and an Adaptor (if needed) to translate from one
Common Communications Vehicle Technology to another. Figure 16 illustrates the
interoperation of two such NGOSS conformant domains.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 57 of 96

The NGOSS Technology-Neutral Architecture

Shared Component Service Contract Contract Instance Processes Policies Shared Component Service Contract Contract Instance Processes Policies
Information Registrations Registrations Registrations Registrations Information Registrations Registrations Registrations Registrations
Repository Repository

Location Registration Repository Naming Mandatory Location Registration Repository Naming Mandatory
Service Service Service Service Framework Service Service Service Service Framework

Contract Inst. Contract Inst. Contract Inst. Contract Inst.

Services
Adapter Contract Inst. Contract Inst. Contract Inst. Contract Inst.
Services

Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech.

Common Communications Vehicle Common Communications Vehicle

Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech.
Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst.
Policy Process Security Service Service Policy Process Security Service Service
Service Service Service Service Service Service
Legacy Legacy
Application Application
Other Mandatory Services Other Mandatory Services

Figure 16: Interoperation of two NGOSS Domains

4.5. Interoperation of an NGOSS Domain to non-NGOSS/Legacy Domains

A much more difficult (and common in today’s environment of many existing non-
NGOSS Legacy domains) is to interoperate between an NGOSS Domain and a non-
NGOSS Legacy Domain. The first step is to identify the functionality that is desired to
expose (on the Legacy Domain side) and the rules for access and visibility (on the
NGOSS Domain side). Second, the non-NGOSS Legacy Domain side must deploy
both Contract Implementations that wrap the functionality being exposed and that
implement the Mandatory NGOSS Framework Services. Finally, the non-NGOSS
Legacy Domain must implement either an Interface Mechanism conformant with the
Common Communications Vehicle, or an Adaptor between NGOSS Domain
Common Communications Vehicle and the distribution technology. This may need to
include semantic mapping between data models. Figure 17 provides an illustration of
an NGOSS domain interoperating with a non-NGOSS or Legacy domain.

Shared
Information
Component Service Contract
Registrations Registrations Registrations
Contract Instance
Registrations Processes Policies Must include Framework
Repository Services as the Minimum
Location Registration Repository Naming Mandatory
Service Service Service Service Framework

Contract Inst. Contract Inst. Contract Inst. Contract Inst.

Services
Adapter
Int. Mech.

Int. Mech. Int. Mech. Int. Mech. Int. Mech.

Exposed Legacy or
Common Communications Vehicle NGOSS non-NGOSS
Services Domain
Int. Mech. Int. Mech. Int. Mech. Int. Mech. Int. Mech.
Contract Inst. Contract Inst. Contract Inst. Contract Inst. Contract Inst.
Policy Process Security Service Service
Service Service Service
Legacy
Other Mandatory Services Application

Figure 17: Interoperation of an NGOSS Domain with a Legacy or non-

NGOSS Domain

4.6. Overview of NGOSS Communications

Figure 18 shows an Interaction Diagram, indicating the typical high-level sequence of
interactions that occur between Components in an NGOSS system. The labeled

TMF053, Version 5.7 TeleManagement Forum 2006 Page 58 of 96

The NGOSS Technology-Neutral Architecture

arrows the sequence of interactions that occur from initially registering an instance of
a Contract Implementation, through the location of an instance of a desired providing
Contract Implementation, resulting finally with the request for functionality and the
final response from the provider.

Consuming Registration Repository Contract Instance Providing

Contract Framework Framework Framework Contract
Instance Service Service Service Instance

Register Consuming Contract Instance

Add Consuming Contract Instance to Repository
Request Instance of Providing Contract
Request Instance of Providing Contract
Respond with Instance of Providing Contract
Located Instance of Providing Contract
Request
Response

Figure 18: High Level Interaction Diagram for NGOSS Communications

This diagram shows that the Contract Instances are decoupled and make use of
NGOSS Framework Services (along with the Common Communications Vehicle as
illustrated in the NGOSS Domain figures) to exchange information. The first step in
this process is for the Consuming Contract Instance to register with the NGOSS
Framework (this is actually done by the consuming Contract Manageability Instance).
Next, the consuming Contract Instance queries the Framework Services to locate an
instance of the desired Providing Contract Instance (again, via the Common
Communications Vehicle). Once a Providing Instance is located, a request is
formatted and sent via the communications mechanism. The response comes back
in a similar way. It is important to note that there may be more than one
communications vehicle and even more that one communications vehicle technology
in an NGOSS system deployment.

Furthermore, the exact nature of the Common Communications Vehicle is a

technology-specific dependency. That is to say, in some technology-specific
implementations, the NGOSS communication vehicle may be supplied by a specific
identifiable runtime entity, whereas in others, it may be an endemic functionality
provided transparently by the technology.

This interaction diagram simplifies a number of steps in order to emphasize the

decoupling of services and their implementations. More information and details about
the interactions between Contract Instance and the NGOSS Framework Services
may be found in [TMF-TMF053F].

TMF053, Version 5.7 TeleManagement Forum 2006 Page 59 of 96

The NGOSS Technology-Neutral Architecture

5. References
The follow documents were referenced within this document, or are considered be
relevant to and supportive of this document.
[ETSI-ES201] European Telecommunications Standards Institute, ETSI: Access and Terminals
(AT); Data Over Cable Systems; Part 3: Baseline Privacy Plus Interface
Specification. ETSI Standard ETSI ES 201 488-3 V1.2.2 (2003-10), October 2003
[ETSI-TS188-001] European Telecommunications Standards Institute, ETSI: Telecommunications
and Internet Converged Services and Protocols for Advanced Networking
(TISPAN); NGN management; OSS Architecture Release 1. ETSI Technical
Specification ETSI TS 188 001 V1.1.1 (2005-09), September 2005
[Gartner AV-19-6751] Yefim V. Natis: Service-Oriented Architecture Scenario. ID Number: AV-19-6751,
Gartner Inc., April 16, 2003
http://www.gartner.com/resources/114300/114358/114358.pdf
[Gartner SPA-401-068] Yefim V. Natis, Roy w. Schulte: Service-Oriented Architectures Part 1. ID
Number: SPA-401-068, Gartner Inc., April 12, 1996
[IETF-RFC2119] Bradner, S.: Key words for use in RFCs to Indicate Requirement Levels. BCP 14,
IETF RFC 2119, March 1997
[ITU-T X901] ITU-T Recommendation X.901 (1997): Information technology – Open Distributed
Processing – Reference model: Overview.
[ITU-T X903] ITU-T Recommendation X.903 (11/95): Information technology – Open
Distributed Processing – Reference model: Architecture.
[ITU-X200] ITU-T Recommendation X.200: Information Technology – Open Systems
Interconnection – Basic Reference Model: The Basic Model. International
Telecommunication Unit, Geneva, Switzerland, July 1994
[Oasis RM] OASIS (Organization for the Advancement of Structured Information Standards):
Reference Model for Service Oriented Architectures. Working Draft 08,
September 9, 2005
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
[PBNM] John Strassner: Policy Based Network Management. Morgan Kaufman
Publishers, Sep 2003, ISBN 1-55860-859-1.
[Raymond95] Raymond, K: Reference Model of Open Distributed Processing (RM-ODP):
Introduction. Proc. of the International Conference on Open Distributed
Processing, ICODP’95, Brisbane, Australia, 20 - 24 February, 1995
[RJB99] James Rumbaugh, Ivar Jacobson, Grady Booch: The Unified Modeling Language
Reference Manual. Addison-Wesley, December 23, 1998
[SEI00] Kurt Wallnau et. al.: Volume II: Technical Concepts of Component-Based
Software Engineering, 2nd Edition. TECHNICAL REPORT CMU/SEI-2000-TR-
008 ESC-TR-2000-007, Carnegie Mellon University, Software Engineering
Institute, Pittsburgh, PA, May 2000
[SZY99] Clemens Szyperski. Component Software: Beyond Object Oriented
Programming. Addison-Wesley, 2nd edition, November 13, 2002
[Thelin03] Jorgen Thelin: A Comparison of Service-Oriented, Resource-Oriented, and
Object-Oriented Architecture Styles. OMG’s 2nd Workshop On Web Services
Modeling, Architectures, Infrastructures And Standards, Munich, Germany,
February 10-13, 2003

TMF053, Version 5.7 TeleManagement Forum 2006 Page 60 of 96

The NGOSS Technology-Neutral Architecture

[TINA-EMC] TINA-C: Engineering Modeling Concepts (DPE Architecture). TINA-C Deliverable,

Version 2.0, Archiving Label TB_NS.005_2.0_94, TINA-C, December 1994
[TMF-GB921] TM Forum: Enhanced Telecom Operations Map (eTOM) – The Business Process
Framework. GB921, Version 0.3, Release 5.0, April 2005
[TMF-GB922] TM Forum: Shared Information and Data Model: Business View Concepts and
Principles and supporting Addenda. SID Release 6.0, October 2005
[TMF-GB922-1C] TM Forum: Shared Information and Data Model: Business View Concepts and
Principles – Addendum 1C: Business Contract. GB922-Addendum1C, Version
4.5, November 2004
[TMF-GB922-4SO] TM Forum: Shared Information/Data (SID) Model: Addendum 4SO – Service
Overview Business Entity Definitions. GB922-Addendum4SO, Version 2.1,
August 2004
[TMF-GB922-1POL] TM Forum: Shared Information/Data Model: Common Business Entity Definitions
– Policy. GB922-Addendum 1POL, Version 1.0b, August 2003
[TMF-GB926] TM Forum: Shared Information/Data Model: System View Concepts and
Principles. Version 1.0, January 2004
[TMF-GB926-1POL] TM Forum: Shared Information and Data Model: Common Business Entity
Definitions – Policy. GB922-Addendum 1POL, To be published
[TMF-GB927] TM Forum: NGOSS Lifecycle and Methodology. GB927, Version 4.5, November
2004
[TMF-TMF050] TM Forum: NGOSS Compliance Testing Strategy Technical Specification. TMF
050, 2002
[TMF-TMF051] TM Forum: New Generation Operational Support System (NGOSS™) PART I
(Business Case). TMF051, 2001
[TMF-TMF052] TM Forum: New Generation Operations Systems and Software (NGOSS™)
PART 2 (Requirements). TMF052, 2001
[TMF-TMF053B] TM Forum: NGOSS Architecture – Technology Neutral Specification - Contract
Description: Business and System Views. TMF053B, Version 4.0, August 2004
[TMF-TMF053C] TM Forum: NGOSS Architecture – Technology Neutral Specification – Behavior
and Control Services. Version 1.1, Release 4.0, August 2004
[TMF-TMF053D] TM Forum: NGOSS Architecture – Technology Neutral Specification -
Metamodel. TMF053D, Version 4.0, Release 1.1, August 2004
[TMF-TMF053F] TM Forum: NGOSS Architecture – Technology Neutral Specification - Distribution
Transparency Framework Services. TMF053F, Version 4.0, August 2004
[TMF-TMF053P] TM Forum: NGOSS Architecture - Technology Neutral Specification, Policy
Architecture. TMF 053P, Version 5.5 December, 2005
[TMF-TMF053S] TM Forum: The NGOSS Security Principles. TMF053S, Version 1.0, January
2004
[TMF-TMF053U] TM Forum: Manageability of NGOSS Software Artifacts and Use Cases. TMF053U,
Version 5.5, December, 2005
[TMF-TMF057] TM Forum: NGOSS Phase 1 Technology Application Note – XML. TMF057, Draft
0.71 May 22, 2001
[WFMC-Gloss] The Workflow Management Coalition: Workflow Management Coalition –
Terminology & Glossary. WMFC-TC-1011, Issue 3.0, February 1999

TMF053, Version 5.7 TeleManagement Forum 2006 Page 61 of 96

The NGOSS Technology-Neutral Architecture

6. Conventions in this Document

6.1. Keywords that indicate Requirement Levels
For the purposes of the present document, the following terms and definitions apply:

Throughout the present document, the words that are used to define the significance
of particular requirements are capitalized. These words are based on [ETSI-ES201]
and [IETF-RFC2119]

MAY This word means that this item is truly optional. One vendor may choose to
include the item because a particular marketplace requires it or because it enhances
the product, for example; another vendor may omit the same item.

MUST NOT This phrase means that the item is an absolute prohibition of
the present specification.

MUST This word means that the item is an absolute requirement of the present
specification.

OPTIONAL Please see “MAY”

RECOMMENDED Please see “SHOULD”

REQUIRED Please See “MUST”

SHOULD NOT This phrase means that there may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed before
implementing any behavior described with this label.

SHOULD This word means that there may exist valid reasons in particular
circumstances to ignore this item, but the full implications should be understood and
the case carefully weighed before choosing a different course.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 62 of 96

The NGOSS Technology-Neutral Architecture

7. Appendix A: DIOA Defined16

7.1. Purpose and Areas of Concern of a DIOA
Each distributed system is designed to accomplish a purpose. The system and its
purpose can be viewed from different perspectives, whereas each perspective
creates its own requirements. However, all perspectives belong to the same basic
understanding: A distributed system needs to be prepared to be used and operated in
a stable, secure, and efficient way. To guarantee this objective for a long time
operation, the system needs to be controlled, administered, and maintained in its
entirety, supporting the general aim of the system, and for each single component, to
ensure that each ring of the chain functions perfect.

7.1.1. Target Environments

New developments can be identified. Formerly separated networks converge.

Services for telecommunication, entertainment, information, and education move to
the same infrastructure. The market changes from a provider dominated market
towards a customer driven market. These developments demand for a rapid service
creation, testing, deployment, operation, and withdrawal. The lifecycle of applications,
services, and resources gets short, so that a dedicated management system cannot
be provided just in time. Generically, two ways of evolution for management are
reasonable. Management systems can be engineered basically to be applicable to
any type of distributed system or management is incorporated into the very systems
themselves. [Booz96]

A DIOA combines the characteristics of classical middleware and management to

harmonize them, in other words to integrate them. This integration does not focus on
the definition of management functionalities for middleware platforms, but on the
integration of basic characteristics of definition languages, meta models, repositories,
protocols and protocol elements, programming interfaces, and application services. It
can be described in the form of a general framework.

This work follows this approach. The integration is done in multiple steps. A DIOA
fulfills business needs that are specified with business models and supported by
service platforms. The environments reflect certain applications, services, and
resources that need to be controlled, administrated, and maintained. Furthermore, a
DIOA is affected by emerging technologies that promise to solve business needs and
customer requirements more efficient or that enable services not possible to be
realized yet.

Business Models

One of the strong driving forces in telecommunications is the need to create a

collaboration consensus between the different players in shared business

16
This section is based on section 2 of [vdMeer02] and further studies. For a complete example of a DIOA please see also
[vdMeer02]

TMF053, Version 5.7 TeleManagement Forum 2006 Page 63 of 96

The NGOSS Technology-Neutral Architecture

opportunities. The formal expression of that conception can be found in a business

model, identifying the main players (stakeholders), their business roles, and
interactions between them. It is based on the projection that the telecommunication
systems evolve into an open, deregulated, multi-provider market and information
place.

The Intelligent Network (IN) has defined a standard business model for
telecommunications [ITU-Q1201]. The Telecommunication Information Networking
Architecture (TINA) has combined new issues of the telecommunication market to
develop a flexible model focusing on the telecommunication market [TINA-BM]. This
model has been adopted by the Study Group 11 of the International
Telecommunication Unit (ITU) as a reference model for the open telecommunication
market.

The modeling of business processes is changing in many areas. Concepts like

Collaborative Business (cBusiness) are going to overcome the legacy business
process modeling that is focused on information of a company. The approach of
cBusiness demands a negotiation resulting in the definition of a shared goal of
collaboration between two or more companies. The business processes are no
longer modeled using a linear timeline but based on clearly identified business roles.
[Röhricht01] [Scheer02]

Beside these generic business models, other organizations have realized

environment specific models for the description of roles and interactions. One
example is the Printer Management Information Base (MIB) [IETF-RFC1759]. Here,
the identified roles are closely related to a printing device. The interactions describe
use cases for a printing device.

Service Platforms

Service platforms are an instrument to design, test, deploy, operate, and terminate
services regarding business needs and technical constraints. The term “service” is
used with a very diverse meaning that depends on the segmentation of areas of
concern. A general model for this segmentation is to distinguish the problem areas of
transmission (transmitting bits), connectivity (end-to-end stream binding),
communication (sessions for users and applications), and information (access to
distributed entities). Each area comes with a dedicated definition for the term service.
[Tönnby00]17

17
Note: the here introduced separations of concern do not necessarily reflect the reality of the SID standards

TMF053, Version 5.7 TeleManagement Forum 2006 Page 64 of 96

The NGOSS Technology-Neutral Architecture

1 2

3 4

end-system network node (e.g. switch) service intelligence

Figure 19: Service Platforms – Distribution of Intelligence [Campolargo99]

The major paradigm of a service platform depends on the actual place where the
intelligence for information services resides. Two different approaches are used today
(cf. Figure 19 case 1 and 2): The intelligence is located centralized within the network
(telecommunication, [Magedanz96]) or the intelligence lies at the end systems (the
Internet, [IETF-RFC1958]). Both approaches offer a limited flexibility since they
cannot support all kind of services with a similar quality of service. For example, an
emergency call demands a connection to a responsible operator within several
seconds. This cannot be provided when the intelligence is located at the end-
systems, since the emergency call must be transmitted in a very limited time window
and highly prioritized inside the network [Draft-Hohno]. Solutions for the special
requirements of telephony services within the Internet are currently under
investigation [Draft-IEPREP]. Furthermore, the fast creation of new services from
independent service providers requires an enormous degree of flexibility. This is
usually not offered when the intelligence is located inside a huge telecommunication
network only [DRAFT-OPES].

The convergence of telecommunications and the Internet has resulted in

developments that focus on those issues. Within the last years, Distributed
Processing Environments (DPE, [TINA-EMC]) and Open Service Access (OSA,
[3GPP-OSAReq]) appeared aiming to distribute intelligence within the network and at
the end systems at the same time (case 3 of Figure 19).

Current trends show that services will be created dynamically and can be activated
anywhere [Magedanz01]. This requires service platforms that are capable of placing
intelligence wherever it is needed, at the time it is needed there, and in a form that
serves services best: centralized, distributed, at end systems, at switches, or at
special nodes (case 4 of Figure 19, [Campolargo99]).

[Tönnby00] explains the shift from traditional solutions towards new approaches.
Services for information are no longer built on vertically integrated services and
networks but as horizontally structured applications built on top of services from any

TMF053, Version 5.7 TeleManagement Forum 2006 Page 65 of 96

The NGOSS Technology-Neutral Architecture

kind of network. Portals for information services get important for unifying information
access [Scheer02]. Connectivity services integrate circuit switching and packet
switching, with a significant trend towards packet switching. Connectivity is supposed
to be ubiquitous and, when realized with computers, based on the Internet Protocol
(IP). Transmission moves from narrow-band networks to broadband networks.
Communication services recognize that communication is not only done between
users, but also between users and ‘things’, and between ‘things’.

7.1.2. Defining Use, Operation, Control, Administration, and Maintenance

The terms use and operation describe the part of a system that is seen by users and
customers. They are concerned about the system’s ability to serve them. A company
running a system relies on its efficient operation in order to generate revenue. This
operation is supported by controlling the system. The term control describes the brief
but permanently reoccurring task of keeping the system stable to serve its customers
and to generate revenue. This includes e.g. the configuration of system components
and the record of data for accounting.

Usage

Administration Operation

Maintenance Control

Figure 20: Use, Operation, Control, Administration, and Maintenance

Administration and maintenance reflect long term operation and control of a system.
This general task is divided into several individual procedures. Administration starts
with the permanent monitoring of the system and the logging of all occurring events to
analyze the behavior of its components. The second aim of monitoring is the
detection of system failures.

7.1.3. Areas of Concern

In Figure 21 the three areas of concern are separated. Applications provide the
interface to users and customers enabling them to utilize services. Services are
software assemblies of components that offer functionality for applications and
provide the access to resources. Resources are software and hardware components
needed for the provision of services and for their execution. In other words, a
distributed system employs resources to complete services and applications.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 66 of 96

The NGOSS Technology-Neutral Architecture

The figure furthermore shows the two main activities inside such a system.
Information is mapped across levels, upwards and/or downwards, for usage,
operation, and control. The system is managed at each level through control,
administration, and maintenance. The assignment of individual tasks to one activity
depends on the system’s purpose. This is also true for the separation of the activities.
The mapping of information is supported by management activities and the system’s
management relies on information mapping.

Applications

Information System
Services
Mapping Management

needs to be done Resources needs to be done

accross levels at each level

Figure 21: Areas of Concern and Activities of Distributed Systems

Both activities have commonalities. The mapping of information as well as the

management of the system can be described in terms of presentation, specification,
submission, re-specification, triggering, queuing, access, and execution. This layered
approach is used to model modular client/server applications. It is built upon small
and functionally specialized components that can be reused across multiple systems.
Each layer of this model provides a specific function in the overall scope of the
system.

The first layer focuses on the presentation of information along with the verification of
results to support the specification and the submission of individual tasks. The
specification answers six questions about a task: Who? (identifier) wants What?
(request) Where? (destination) When? (schedule) Why? (purpose) and How?
(execution plan). The answers to Who?, What?, When?, and Why? are the basis for
a submission that is a complete job specification. The re-specification is responsible
for the mapping of What? towards a set of commands that is needed to be executed
to fulfill the purpose. Triggering activates and deactivates jobs based on date and
time information, completion of other jobs, or other available data. Queuing provides
load balancing and the prioritizing of jobs. Access functions as a mediator between
the above layers and the execution layer. It provides interfaces to resources.
Execution executes any job that is submitted from submission via access. The type of
service executed here depends on the overall purpose of the system and might range
from database access, media conversion, user interaction, up to device and network
usage. All described layers are supported by navigation, security, metering, and
logging.

These commonalities between information mapping and system management should

lead to a similar design of software that handles them. However, the reality is
different. Management activities are outsourced to specialized systems that act
independent of the systems they manage. The reason for that is the evolution of
network systems. Starting with basic services (telephony and data transmission), the
first two types of networks that existed had had no need for automated management.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 67 of 96

The NGOSS Technology-Neutral Architecture

The networks had been operated manually. Changes in society and on the market
have led to the extinction of this business model. Networks have become connected,
the market has demanded more than the basic services, and the number of devices
has increased. This resulted in the actual need for an automated management of
services and resources to continue to run the network in an efficient (and profitable)
way. The operation of services and their management became separated areas with
different approaches. Today, distributed systems and services run on top of
middleware and are managed by dedicated management systems.

7.2. Conceptual Framework of a DIOA

The conceptual framework offers concepts and rules for the definition of an
architecture as a DIOA. The concepts are expressed in form of objectives and
requirements. The main objective is the integration of middleware and management
with unified management. This objective leads to a number of requirements, such as
the support of services for naming of objects and building of repositories. The rules
reflect the concept in a multi-layer model. This conceptual model defines rules that
need to be followed in order to realize the concepts. Finally, the concepts and the
rules can be viewed together to define an architecture and its components. The
conceptual framework gives recommendations for the realization of identified
components. Additionally, this section provides a review of available technologies.

7.2.1. Objectives

The main objective of this DIOA framework is to provide means for that enable to
produce extreme flexibility for user applications, e.g. an Operation Support System
(OSS), in the way they may exploit Information, Communications and Technology
(ICT) resources. This leads to the integration of applications, management,
middleware and resource concepts while maintaining the independence from
concrete technologies. It aims for the seamless integration of capabilities in all layers
so that management is an embedded capability not independent or tacked on. The
aim in NGN is to produce extreme flexibility for user applications in the way they may
exploit, i.e. control, ICT resources in service delivery. The integration serves as a
basis to develop service platforms with integrated management facilities that enable
applications, services, and resources to be used, controlled, operated, administered,
and maintained in a unified way. The independence provides the realization of the
framework employing the technology of choice, whereas the decision for the
technology can be neither foreseen nor predicted.

Components that belong to the framework should benefit from the integrated and
unified management in the way that their management can be done by the
framework itself (instead of a certain complementary management system).

The second objective is that the framework needs to be designed for multiple
purposes. The target environment spans from small systems built for a simple
purpose (as the usage and control of a home network) up to huge distributed systems
covering a multitude of service within a multi-domain environment and many different
roles and businesses.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 68 of 96

The NGOSS Technology-Neutral Architecture

The third objective is to support the two major activities (information mapping and
system management) as introduced in section 7.1.3. The framework should offer
mechanisms to map information across identified levels and, at the same time, to
manage entities of those levels.

The fourth objective refers to the acceptance of the framework itself. The history of
the Internet has taught that adoption is a better predictor than perfection. The
acceptance of the framework is not given for the sake that it integrates middleware
and management. Instead, the framework will be used only if it integrates
management and middleware up to a reasonable level, employs widely known and
accepted methods and technologies, and creates novel functions or improves
existing ones.

7.2.2. Requirements

The objectives for the definition of the framework as well as the target environments
lead to the definition of the requirements. In general, the framework should enable
interworking, portability, and scalability. Interworking reflects the need of business
roles and framework components to interact, since the target environment of the
framework is a global market of converged services and networks. Portability is a
requirement that has to be introduced because the further usage of existing
technologies is not certain, emerging technologies have not shown their applicability,
and future technologies are yet unknown. Scalability should prepare the framework
for distributed systems for the range of small up to huge application areas.

The second block of general requirements relates to the functionality the framework
has to support. Since applications, services, and resources are realized by distributed
components, the framework itself must support distribution. The distributed
components can be implemented with various technologies. This leads to the
necessity of a framework that is technology independent. The integration of
distributed systems in the Internet and the WWW imply requirements that are
described as web-enabled and directory-enabled. Last but not least, the mapping
of information across levels and the management of each level follows pre-defined or
negotiated methods of actions. The framework should offer mechanism to enable a
policy-based realization of them.

The handling of distributed systems makes it necessary for the framework to offer the
basic functionality that the distribution of components demands. Mechanisms must be
identified for the naming and addressing of components as well as for their
registration. The approach of a centralized naming service (as a single point of
failure) seems not sufficient, especially looking at P2P networks and mobile agent
technology. Registered components will seek for services with a certain Quality of
Service (QoS). They should be aided by discovery and lookup services. The
communication among components can be arranged in a peer-to-peer manner or by
message services.

The support of automated control, administration, and maintenance must be based

on formal descriptions of components and policies for their interaction. Policy and
profile services (or data and type repositories) can be mechanisms to realize this.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 69 of 96

The NGOSS Technology-Neutral Architecture

The visualization of components, interactions, and data types is a requirement for

the manual control of a distributed system.

The technical challenges can be seen in the interoperability of components, the

control of resources that are employed by the framework, and the definition of
formats for data exchange and evaluation. Connectivity and reliability of
framework services might be based on middleware technology. However, the
framework has to ensure them explicitly.

7.2.3. Conceptual Model

The conceptual model identifies four planes. Each plane is dedicated to a specific
problem context. Each problem context describes a dedicated viewpoint to the two
areas of concern (information mapping and system management) and the five terms
(use, operation, control, administration, and maintenance) introduced in 7.1.2. The
planes are used to specify the different types of information that need to be mapped
and the different levels of management that is needed. The approach of a conceptual
model is taken from the IN standard series [ITU-Q1201].

The conceptual model provides the basis for a specific architecture. It presents rules
for components of a specific architecture and describes relationships between those
components. The four planes of the conceptual model are presented in Figure 22.
The definitions of each plane can be employed to describe particular aspects of the
architecture. The four planes are
¾Business Model Plane, covering business functionality and processes within
functional blocks;
¾Service Engineering Plane, modeling functional blocks as computational
objects providing services;
¾Service Framework Plane, modeling framework and other mandatory
services as computational objects; and
¾Basic Technology Plane, identifying the employed technologies and their
relationships.
On the first view, the conceptual model separates the applications from technologies.
Business models become technology independent. This means, a business
application (business processes) is not using a particular middleware or management
technology. Those technologies become transparent for the business application.
The conceptual model allows substituting middleware and management technologies
without changing the business applications.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 70 of 96

The NGOSS Technology-Neutral Architecture

el
od
M
s
es
sin
Bu

g
rin
ee
n
Domain B

gi
Domain C

En
e
DomainA

ic
rv
Se

k
or
ew
am
Fr
e
ic
rv
Se

s
ie
og
l
no
ch
Te
sic
Ba
Figure 22: Conceptual Framework - Conceptual Model

However, the conceptual model must not be seen as a dogma. Application might
need direct access to technologies. This is especially important for the management
of resources. This direct access belongs to the business model and the design of the
application. An architecture derived from the conceptual model should not deny such
a direct access.

Business Model Plane

The Business Model Plane focuses on the design and the implementation of
business applications. A business application is an implementation of a set of
functionalities and processes that might be distributed over multiple hosts. This set of
functionality does not include the support for distribution [TMF-ACT01-99]. Following
[TINA-ODL], a group of object consists of object specifications that are called
components. An application can be seen as a group of objects. A business
application component is then a single object specification within a group.

The design of a business application can be derived from a business model.

Appropriate models and tools can be used for design and implementation. The final

TMF053, Version 5.7 TeleManagement Forum 2006 Page 71 of 96

The NGOSS Technology-Neutral Architecture

implementation can profit from a concrete architecture. The actual purpose of future
business applications can neither be predicted nor foreseen. The conceptual model
gives no further recommendations for this plane.

Service Engineering Plane

The Servicde Engineering Plane concentrates on the modeling of (distributed)

objects. An object is a part of an application that models a real world entity. It is
implemented in a computational, identifiable entity that encapsulates state and
operations. Attributes are sets of data with a fixed semantic [CORBA] [TMF-ACT01-
99].

The interfaces of objects are specified in a certain language. Many middleware and
management architectures employ a specific interface language. The languages are
combined with tools for automated processing such as compilers and interpreters.
The selection of an appropriate interface language depends on the objectives of the
specific architecture. Many languages only include the signature of an interface. This
signature might not be enough. Languages from the management area often add
semantic information to individual parts of a signature. This information can be used
to qualify an interface or parts of it. Furthermore, this information can provide the
basis for repositories that enable lookup, monitoring, and configuration of objects.

A specific architecture can support the application design with a set of basic
specifications. This can be done e.g. in form of a core model (like the DMTF core
model [DMTF-CIM]) or a structure of information (like the Structure of Management
Information - SMI; [IETF-RFC2578]).

Beside objects, Figure 22 shows the concept of domains. A domain can be used to
separate (or to delegate) responsibilities. Domains can be implemented e.g. for the
collection of objects that deal with different connectivity services (signaling, packet
switching), objects that belong to functional areas (like the management functions of
[ITU-X700]), or objects that relate to layers of the Reference Model for Open Systems
Interconnection (RM-OSI; [ITU-X200]). A domain can also be used to reflect
geographical distribution or hierarchies of an organization. The reflection of business
models is an important factor for modeling domains.

A protocol is needed to define how interactions between objects can take place. The
characteristics of the protocol depend on the interface language. The specification of
the protocol should enable an easy mapping to technologies of the Basic Technology
Plane. The protocol must enable the identification of called objects. Furthermore, it
should provide a reliable and encrypted transmission. An Application Programming
Interface (API) can be used to realize protocol mechanisms and to provide access to
protocol features.

Service Framework Plane

The Service Framework Plane models a collection of interfaces and objects

(services) that provide basic (mandatory) functions for (business application) objects
[CORBA-NS]. A service is independent from the application domain and from objects
of the Service Engineering Plane. One of the most important services is a naming

TMF053, Version 5.7 TeleManagement Forum 2006 Page 72 of 96

The NGOSS Technology-Neutral Architecture

service, which enables the identification of (available) objects. The target

environments introduced in section 7.1.1 demand for other services. The exchange of
asynchronous events can be realized with an event service. Monitoring of objects and
longtime configuration management relies on logged events. Ad-hoc networking and
peer-to-peer communication need lookup services to search for objects that offer a
specific functionality.

The mandatory services that must be provided by a specific architecture are a

naming service and an event service. Furthermore, the architecture should offer
services that combine information about object instances (naming) with information
about object classes (specification). This combination allows the assembly of
repositories that ease the administration and maintenance of a system. Additionally,
the architecture should offer functionality for the visualization of instances and classes
in order to support the manual management of a system.

Basic Technology Plane

The Basic Tachnology Plane is introduced to model middleware and management

technologies. This plane functions as a mediator to the actually employed middleware
with specific interface languages, communication protocols, and services.
Management systems can be integrated into the architecture and existing
specifications can be reused if available. The technology comprises middleware and
management architectures (such as CORBA, Java, Simple Network Management
Protocol – SNMP, Telecommunication Management Network – TMN) as well as
concrete products.

The connections between the technologies in Figure 22 should indicate that there
must exist an interworking between these very technologies. This interworking is
needed to enable a communication between the objects and services. To give an
example: a business application WWW Monitoring can be realized in CORBA and a
business application WWW Alert can based on an SNMP Manager. Both objects
should communicate with each other. This communication can be realized with a
CORBA/SNMP bridge (horizontal integration within the Basic Technology Plane).
Another possible realization is that the business application WWW Alert would also
be a CORBA object that communicates with the SNMP Manager and functions as a
gateway by itself (vertical integration realized in the Service Engineering Plane and
the BasicTechnology Plane).

7.3. Components of a DIOA

The conceptual framework defines the basic concepts and the conceptual model
specifies the basic rules for a concrete architecture. A DIOA does concentrate on the
two middle planes of the conceptual model. The rules of the Service Engineering
Plane are used to define the basic components of a DIOA. The rules of the Service
Framework Plane already identify services that need to be realized. A DIOA should
not define methods for business models. Those models are related to the business
logic of application, which should be supported but cannot be defined by a DIOA. The
Basic Technology Plane depicts important realizations and products. A DIOA must
recognize those technologies and should reuse existing approaches for interworking
between different technologies.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 73 of 96

The NGOSS Technology-Neutral Architecture

Application Services
Meta Schema Messaging, Specification,
Core Model API
Visualization, Database
Repository
Configuration
Formal Core Services Console
Notation
Naming, Directory, Monitoring, Performance
Compiler API
Lifecycle, Config, Notification Monitoring
Mappings
Administration
Tools
Communication Services Tools
Control Services

API Protocol Services

Protocols and Formats

Development Execution Environment Deployment

Figure 23: Components of a DIOA

The components of a DIOA belong to the three parts of development and operation of
a distributed system. These three parts are depicted in Figure 23. They are
development, execution environment, and deployment. The development step follows
a business model. A DIOA should support the development with an appropriate
formal notation for the specification of objects. This specification is based on a meta
schema (or object model), which needs to be designed in a way that reflects the
needs of the target environments (cf. section 7.1.1). A core model can be specified
using the formal notation. Task of the core model is to provide basic definitions for a
distributed system, such as often used data types and generic objects. The formal
notation defines syntax and semantic of a language that is derived from an object
model. Here, the mapping of specifications to concrete middleware technology,
programming languages and compilers must be specified by a DIOA. This mapping
can be supported by tools for an automated processing of specifications.

The second step is the execution of the distributed system. This is supported by a
DIOA in form of an execution environment, which provides an interface to the Basic
Technology Plane. Figure 23 shows the execution environment in form of three
layers. Each layer provides a unified access to its functionality via one or more APIs.
The lowest layer realizes the communication between objects and between objects
and services. For this communication, a DIOA needs to define a protocol along with
data formats, and control services. The protocol defines the communication behavior,
including the transmission of data. The data formats are used by the protocol for the
transmission of information specified in the formal notation. The control services can
be used to include additional functionality for addressing, security, and transactions.
The protocol must be specified in a technology independent way. This should allow
the usage of many different technologies for the actual exchange of data.

The services of the Service Framework Plane are further separated in two groups.
The first group collects core services, which must be present in the execution
environment for usage and operation of a distributed system. The second group

TMF053, Version 5.7 TeleManagement Forum 2006 Page 74 of 96

The NGOSS Technology-Neutral Architecture

depicts services that might be present. This second group of services should improve
the architecture’s ability to support control, administration, and maintenance.

The final step is the deployment of the objects and the distributed system itself. Here,
a number of tools should be provided for the configuration of the system. These tools
can be offered in form of an administration application. This application should be
able to visualize information about the actual state of objects, including instantiated
objects, request counts, runtime behavior, monitoring, and log information. The tools
should be based on core and/or application services. Following this approach, an
administration tool by itself is a distributed application that can be modeled using the
conceptual model and the mechanisms of the architecture.

The following subsections discuss state of the art technologies for the components of
the architecture. These technologies are parts of actually available middleware and
management architectures. Section 7.3.1 starts discussion with an overview of object
models and metamodels. Section 7.3.3 concentrates on interface languages and
syntax notations. An object model and a formal notation provide the basis for the
definition of repositories. Section 7.3.2 shows that a repository represents a virtual
data store that combines specifications (object classes and related definitions) and
runtime information (object instances).

The section 7.3.4 reviews approaches for protocols, data formats, and
communication services to define the lowest layer of the execution environment.
Section 7.3.5 is dedicated to transparency services. Tools and user interfaces to
application services should support the deployment of applications. Other tools for the
deployment of applications are not discussed explicitly. They belong to the concrete
target environment. However, the specifications of a DIOA should give
recommendations for those tools.

7.3.1. Object Models

An object model is the composition of interacting objects that concentrates on clearly

identified aspects of the real world. Object models can be abstract or concrete. An
abstract object model identifies basic characteristics of objects [OMG-OMA]. The
client/server paradigm ([Orfali96]) and the manager/agent relationship ([Hegering99])
can be denoted as abstract object models. A concrete object model adds specific
recommendations and rules. A concrete object model identifies the semantic of
objects. Furthermore, it can restrict the abstract model by eliminating entities or
placing additional restrictions [CORBA].

The object models of [CORBA] and [TINA-CMC] define an object as presented in

section 0. In general, these characteristics apply also to managed objects. In detail,
managed objects are further restricted. They provide an abstraction from a physical
resource (network component) or logical resource (e.g. profiles). The operations of a
managed object are often predefined in the object model. SNMP declares access
policies for attributes (read-only, read-write, read-create, not-accessible; [IETF-
RFC2578]) that directly influence set and get operations of the protocol. X.700 has
standard operations defined for all managed objects (create, delete, action) and
standard operations for attributes (get, replace; [ITU-X720]).

TMF053, Version 5.7 TeleManagement Forum 2006 Page 75 of 96

The NGOSS Technology-Neutral Architecture

Furthermore, managed objects emit notifications. Notifications are closely related to

the resource that is modeled by the managed object. This is an important
characteristic of the manager/agent relationship. [Hegering99]

The CIM Meta Schema allows describing object instances [DMTF-CIM]. This feature
enables a designer to specify a distributed system in a very restricted way, including a
set of object instances. This approach makes configuration management easier and
solves some issues of an initial start-up of a system.

A Reference Model

The Reference Model for Open Distributed Processing (RM-ODP; [ITU-X901],

[Raymond95]) can be used as a guideline for the design of distributed systems. The
computational and the engineering viewpoint can be employed as a basis for
concrete object models. The left side of Figure 24 shows a computational object, the
right side an engineering object. [Linington95] states that “Objects can have any
number of interfaces. This ability to partition the observable behavior of an object
between multiple interfaces gives a valuable tool for structuring the specification of an
object’s behavior.”

Streaming
Object 1 Object 2 Interface
Core
Object
Operational
Interface
Object Group Legacy
Integration
Hardware
and Software

Figure 24: Computational and Engineering Objects

Figure 24 shows Object2 with one computational and one streaming interface.
Furthermore, the mapping to engineering objects is presented. These engineering
objects decouple the interfaces (interface objects) from the implemented behavior
(core object) and legacy technology (legacy integration).

Semantic Information

The concrete object models of middleware offer mechanisms that describe the syntax
of an object. TINA adds the two textual descriptions behaviorText and usage, which
should be used to explain behavior and usage in a natural language of choice [TINA-
CMC] [TINA-ODL]. SNMP calls such a description a definition, which must be used to
explain the minimum requirements on an object’s implementation [IETF-RFC2578].

The CIM meta schema introduces qualifiers to characterize objects and other named
elements. This mechanism allows the CIM meta schema to be “extensible in a limited
and controlled fashion” [DMTF-CIM]. Adding new qualifiers increases the availability

TMF053, Version 5.7 TeleManagement Forum 2006 Page 76 of 96

The NGOSS Technology-Neutral Architecture

of meta data about a schema, which can be automatically processed in a particular

management environment.

Attributes and Parameters

Attributes and parameters of interfaces belong to specific types. The permitted types
are usually identified in the concrete object model. Middleware distinguishes between
basic types and constructed types e.g. described in [CORBA]. Basic types are in
many cases similar to basic types of programming languages, like different kinds of
integers, floating point numbers, characters, and Boolean types. Constructed types
can be records (struct), discriminated unions, sequences of other types, arrays,
interfaces etc. The description of the semantic of types is mostly limited to ranges
(e.g. for integers), minimum/maximum boundaries (e.g. for arrays), and the memory
allocation (e.g. characters).

Management object models define a more restricted semantic of types. E.g., SMI
uses one type for IP addresses, two types for counters, and one type for time ticks
[IETF-RFC2578]. The CIM meta schema includes a type for date and time
information [DMTF-CIM]. [ITU-X721] defines generic types for attributes, actions, and
notifications. Generic attribute types include counters (simple and settable), gauge
(dynamic variable), and tide-mark (minimum or maximum value of a gauge during
measurement time). Each implementation of such an object model is expected to
support the defined types along with their semantic. Interworking between
management systems is only guaranteed when these types are used.

Object Identifiers

For management, administrative policies are used for assigning identifiers. These
policies are either defined directly in the object model (SNMP in [IETF-RFC2578]) or
belong to the characteristic of employed technologies (e.g. distinguished names for
directories as defined in [ITU-X720]). These identifiers are further used to generate
repositories and to enable interworking between different implementations.

Rules for Object Instantiation

In middleware, an interface represents a syntactical description of a service that is

offered to clients. An object satisfies an interface when it provides the service
according to the operations of this very interface. Management defines more
restrictive rules for the instantiation of objects. An OSI managed object must support
all the attributes, operations, behavior, and notifications specified in all mandatory
packages. Furthermore, it exists, from a management point of view, if it has a
distinguished name and supports the operations and notifications defined for its class.
Otherwise, it does not exist from a management point of view, even if a physical
counterpart exists [ITU-X720].

Object orientation

Object-orientation is based on at least two key issues: encapsulation and inheritance.

Encapsulation reflects the fact that objects distinguish between their interfaces and

TMF053, Version 5.7 TeleManagement Forum 2006 Page 77 of 96

The NGOSS Technology-Neutral Architecture

their implementation. Inheritance provides the basis for code-reuse and for code-
clarity [Stroustrup92]. The most management object models do not allow multiple
inheritance [Hegering99]. As [CORBA-MAN] states: “Real embedded interfaces don’t
differ in the services they offer, they differ in the entities they manage … In object-
oriented terms, services represent a case in which inheritance is not appropriate.”

However, not all object models must follow an object oriented approach. The object
model of SNMP does not include any kind of object-oriented design mechanism.
SNMP managed objects are declared, implemented, and used as a set of variables.
The variables can be structured in tables. A table might contain any number of
columns and each column represents a single variable (managed object)
[Zeltserman99].

7.3.2. Repositories

Management Information Bases and Interface/Object Repositories are (usually

distributed) virtual data stores that manage information about an object-oriented
system. A MIB defines the naming conventions for stored objects. In middleware, the
term repository describes a database that holds interface/object signatures. For
DCOM and CORBA, these repositories contain information about an object’s
signature and its actual implementation. Middleware for the control of appliances,
such as Jini and UPnP, add information about the semantic of interfaces/objects.

Management architectures define a central naming scheme in which names (or parts
of names) are assigned by an authority. The names are arranged in a hierarchical
structure reflecting a hierarchy of managed objects. SNMP uses an OBJECT
IDENTIFIER that is constructed of a number of labels [IETF-RFC1157]. The SNMP
standards track demands the implementation of several parts of the MIB at each
agent. The implementation of the system group, e.g., is mandatory [IETF-RFC1213].
For OSI management, a name binding must be assigned to each object specification
[ITU-X720]. Furthermore, an Object Identifier Tree (OIT) is defined as basis for a
consistent object naming [ITU-X722].

The CIM mechanisms for naming and object databases facilitate the task of sharing
management information between a variety of platforms. The major issue of naming
is the enterprise-wide addressing of objects. Object databases based on CIM naming
are employed to realize a MIB-like instrumentation [DMTF-CIM]. The creation of
different scope hierarchies, regarding the actually used models, must be able to be
changed over times. This does not permit a single, standardized MIB as of SNMP
and X.700 management systems.

7.3.3. Formal Notations

Formal notations are languages used for the specification of objects and their interfaces.
They do not depend on actual implementations. Those languages are built of a number of
definitions that explain syntax and semantic of an object model (or a meta schema). A
formal notation is defined by a grammar, usually a variant of the Backus-Naur Form
(BNF), such as Augmented BNF (ABNF, [IETF-RFC2234]) or Extended BNF (EBNF,
[ISO14977]). Notations for managed objects are often based on the Abstract Syntax
Notation 1 (ASN.1) [ITU-X208]. Almost all specifications are coded as plain text files. This
gives a number of intrinsic characteristics:

TMF053, Version 5.7 TeleManagement Forum 2006 Page 78 of 96

The NGOSS Technology-Neutral Architecture

¾Platform independence (every platform is able to handle plain text files);

¾Extendibility (every platform supports tools for editing plain text files);
¾Automated processing (no additional re-formatting is necessary); and
¾Readability (as long as the reader is familiar with the formal notation).
A formal notation defines conventions for permitted character sets (ASCII18, Unicode,
ISO19 Latin-1), identifiers, keywords, comments (single line, multi-line), and
preprocessing. With particular language elements, the definition of naming and
scoping rules is established.

The formal notation that are of interest for MAMA can be categorized as follows.
¾Interface Definition Language (IDL) – is used for the specification of interface
signatures in DCE20, CORBA, and DCOM. [DCE-RPC] [CORBA]
¾Object Definition Language (ODL) – enables the description of ODP
computational objects with interfaces, object groups, and a number of
templates. [TINA-ODL]
¾Languages for the specification of managed objects – are employed by
management architectures. Examples for those languages are SMI, the
Guidelines for the Definition of Managed Objects – GDMO, and DMTF
Managed Object Format – MOF. These languages are either a subset of
ASN.1 (SMI [IETF-RFC2578], GDMO [ITU-X722]) or an extension of IDL
(DMTF MOF; [DMTF-CIM]).
¾Languages for generic data exchange – XML and derived languages provide
technology independent mechanisms for data exchange. As a meta
language, XML offers the ability to specify domain specific languages that can
be processed with standardized tools.
All languages are designed following a concrete object model. The applicability of the
languages within this thesis depends on the concrete object model of MAMA. In
general, languages from all categories can be used. However, each category has
specific characteristics that need to be considered.

The object models of CORBA and DCOM do not distinguish between object and
interface. Their IDL does not support more than one interface per object. With ODL,
multiple interfaces per object can be realized. Both languages give no
recommendations or restrictions for operations and type definitions. Languages from
the area of management primarily support generic interfaces for specific
management functionality. This includes meta information on semantic of objects,
interfaces, and attributes as introduced by an object model. IDL and ODL do not offer
such a facility.

Object identifiers are almost case-insensitive. This means, two identifiers collide when
they differ only in the case of their characters. Case-insensitive identifiers already
support scripting languages, which do not distinguish between upper-case and lower-
case characters. [DMTF-CIM]
18
American Standard Code for Information Interchange
19
International Standardization Organization
20
Distributed Computing Environment

TMF053, Version 5.7 TeleManagement Forum 2006 Page 79 of 96

The NGOSS Technology-Neutral Architecture

In IDL, attributes can be declared as read-only. Parameters of operations can be

declared as in, out, or both; clarifying in which direction a parameter should be
transmitted [ITU-X920]. Furthermore, mappings from IDL to programming languages
are defined [CORBA]. ODL adds templates for the creation of interfaces, objects, and
object groups. These templates serve for “software distribution and modularity”
[TINA-ODL].

SNMP goes a similar way offering an object-type macro that should be used to define
SNMP managed objects [IETF-RFC2578]. The OSI management framework
provides a complete set of guidelines. GDMO includes templates for objects,
attributes, behaviors, and notifications [ITU-X722]. Each managed object can be
assembled with packages. A package can be declared as conditional, which offers a
policy for object instantiation. Each managed object is accompanied with a name
binding [ITU-X722].

The DMTF MOF language adopts many IDL features (from DCE IDL). Special
compiler directives are available to include paths in a global name space for MOF
object classes and instances [DMTF-CIM].

The combination of SOAP and XML promises a mechanism to access distributed

systems from the WWW. XML was originally defined as “[…] a method for putting
structured data in a text file” [W3C-XML-10P]. Basically, XML defines no objects or
interfaces but documents. Structure of information and content are separated.
Structure of information can be declared with tags [ISO8879]. A Document Type
Definition (DTD) defines constraints on storage layout and logical structure. XML
further distinguishes between well-formed (XML conform) and valid (conform to a
well-formed DTD) documents [W3C-XML].

The use of ASN.1 as basis for languages from the management area is currently
discussed in the IETF. The discussion started with the work on a new version of SMI
(SMIng; [IETF-RFC3216]), which incorporates management and policy schemes.
[IETF-RFC3780] defines a new language that depicts several features from object-
oriented languages and from programming languages. On the other hand, [Draft-
ASN1NG] proposes the usage of ASN.1 for the new version of the SMI. The IETF
Draft is conforming to the requirements identified in [IETF-RFC3216].

7.3.4. Communication Services, Protocols, and Formats

Protocols

A protocol defines mechanisms for the exchange of data between distributed objects.
[ITU-X210] recommends a reference model that includes the basic definitions of a
protocol and protocol services. Information is transmitted in Protocol Data Units
(PDU), which contain protocol information (header) and the actual data (payload).
PDUs can be designed for specific service primitives [ITU-X210]. [Tannenbaum96]
explains many protocols in detail.

SNMP defines a protocol in [IETF-RFC1157] as “an application protocol by which the

variables of an agent’s MIB may be inspected or altered. Communication among
protocol entities is accomplished by the exchange of messages, each of which is

TMF053, Version 5.7 TeleManagement Forum 2006 Page 80 of 96

The NGOSS Technology-Neutral Architecture

entirely and independently represented within a single datagram using the basic
encoding rules of ASN.1”. The OSI management framework recommends a complex
set of entities, services, and protocols for the exchange of management information.
[ITU-X701] [ITU-X710]

Another example of a protocol is HTTP. The HTTP is an application level protocol

[IETF-RFC2616]. It is based on an asynchronous communication model and realized
as a request/response protocol. Communication is organized with the simple
exchange of messages in form of documents. Access to legacy systems is provided
by gateways and proxies. This protocol can serve as communication protocol for
other application protocols (such as the Simple Mail Transfer Protocol – SMTP or the
File Transfer Protocol - FTP).

Data Encoding

An important issue for data transmission is data encoding. [CORBA] defines a

transfer syntax (Common Data Representation – CDR) that maps ordinary IDL data
types to a bi-canonical, low-level representation. The Basic Encoding Rule (BER)
formulates encoding rules for the transmission of ASN.1 typed information.
Application level protocols, such as FTP and HTTP, are often based on text
messages. The actual transmission of these messages is realized with transport
protocols. Special transport mappings are used to define how information “maps onto
an initial set of transport domains” [IETF-RFC1906].

[Palme02] provides a comparison of ABNF, ASN.1 BER and DTD-XML. The excerpt
compares characteristics regarding the level of coding, the encoded format, the
readability of the code, and the efficiency of data packing, binary data, and layout
facilities. One example is given for textual encoding measured in octets. This
example shows that ASN.1 BER is the most efficient language (61%) followed by
ABNF (19%) and XML (11%). [Palme02] has recently specified an encoding for XML
data, which promises to optimize the encoding of XML data for transmission.

Message Formats

Message formats provide a facility to generate requests, to locate objects, and to

manage communication channels [CORBA]. For management protocols, these
message formats are predefined in form of a set of PDUs (SNMP; [IETF-RFC1905])
or a combination of PDUs and service elements (OSI, [ITU-X710]). For middleware
protocols, these message formats realize a subset of interactions needed for a
client/server relationship [CORBA] [DCE-RPC].

SNMP uses a mechanism called variable binding for the payload of a PDU. This is a
simple list of variable names and corresponding values. Some PDUs are concerned
only with the name of a variable and not its value (e.g., the GetRequest-PDU). In this
case, the value portion of the binding is ignored by the protocol entity. [IETF-
RFC1157]

Protocol Services

TMF053, Version 5.7 TeleManagement Forum 2006 Page 81 of 96

The NGOSS Technology-Neutral Architecture

An SNMP request is atomic, which means it is either completely successful or not at

all. More sophisticated transaction protocols are the 2 Phase Commit Protocol (2PC)
and the 3 Phase Commit Protocol (3PC). They are able to operate a unit of work over
multiple objects. Commit and abort messages are exchanged to signal a successful
operation of a complete unit or to instruct a rollback [Heuer97]. The Common
Management Information Service (CMIS) offers a parameter that indicates in which
manner operations over multiple (managed) objects are to be synchronized. This
parameter can be set to atomic (similar to SNMP) or best effort. [ITU-X710]

The Common Management Information Protocol (CMIP) allows the collection of

managed objects for each operation [ITU-X710]. Such a selection involves two
phases: scoping and filtering. Scoping entails the identification of the managed
objects to which a filter is to be applied. Filtering entails the application of a set of
tests to each member of the set of previously scoped managed objects to extract a
subset. The subset of scoped managed objects that satisfy the filter is selected for the
operation. Four specifications of scoping level are defined, enabling to address
managed objects in a management hierarchy: the base object alone, the nth level
subordinates of the base object, the base object and all of its subordinates down to
and including the nth level and the base object and all of its subordinates (entire sub
tree).

7.3.5. Transparency Services

Naming and Directory Services

Naming services support the identification of objects. The naming service provides a
name-to-object resolution. Each object must register itself at a naming service. Other
objects can retrieve information about registered objects, at least their system specific
address. Commonly used naming schemes are object references (in CORBA), hash
identifiers (in Java Remote Method Invocation – RMI), or distinguished names (in
OSI, TMN). IP networks use a different naming scheme. Here, a name is a set of
labels with clear boundaries (SNMP, Domain Name System – DNS; [IETF-
RFC2929]).

Naming schemes can be based on name spaces that are managed by an authority
(Universal Resource Locator – URL [IETF-RFC2396], X.500 distinguished names
[ITU-X501]). Other mechanisms, like the CORBA Interoperable Object Reference –
IOR ([CORBA]) and the DCE Universally Unique Identifier – UUID ([DCE-RPC]), do
not involve such an authority. They are based on generic algorithms.

A certain protocol can be assigned to a name, which indicates how an object can be
accessed. A CORBA IOR can be assigned to the Internet Inter-ORB Protocol IIOP,
RMI, or DCE. Furthermore, a CORBA IOR can be expressed in form of a URL
[CORBA-NS]. A URL can be assigned to any available protocol. Furthermore, the
access to a resource addressed by a URL might involve more than one protocol. For
access to an HTML21 document a client needs to request a host name from the DNS
and than the document via HTTP [IETF-RFC2396]. Names need not to be interpreted
by an application. This is task of the implementation of the protocol.

21
Hypertext Markup Language

TMF053, Version 5.7 TeleManagement Forum 2006 Page 82 of 96

The NGOSS Technology-Neutral Architecture

Names can be further integrated into a directory service. Such a service employs
directory names. An entry in a directory can be aliased, which means more than one
entry can be assigned to the same object without replicating this very object. Access
to a directory service is offered to clients via a protocol [ITU-X500] or an API [JNDI-
API] [CORBA-NS].

State of the art directory services, such as LDAP, JNDI, and Active Directory (AD),
are realized as distributed services. They offer a single point of access to clients and
manage distributed databases, which can rely on different technologies [DMTF-CIM].
The management of these databases involves two important concepts: referrals and
replication.

1 2
est DSA B DSA B
request requ request
DUA DSA C request DUA DSA C
referral (to B) refer referral (to A)
ral (B
) DSA A DSA A
request

3 4 est
requ onse DSA
request request request re p
s
DUA DSA DSA DUA DSA requ
est
response response response resp
onse
DSA

Figure 25: Distributed Directory and Referrals [ITU-X501]

The DNS, X.500, LDAP, and JNDI realize the search operations in a distributed
directory with referrals. Figure 25 shows four cases for the usage of referrals as
defined for X.500 and LDAP. In case 1, the Directory System Agent (DSA) C handles
a referral from DSA A to retrieve the requested information from DSA B without
further interactions with the client. In case two, the original client’s request is
answered with a referral to another directory server. The client is responsible for a
consecutive request. The cases 3 and 4 show two approaches for chaining. Case 3
depicts uni-chaining (one request is passed through several DSAs). Case 4 shows a
multi-chaining example (one request is forwarding it to two or more other DSAs).
[ITU-X500]

The concept of replication was introduced to improve the availability and reliability of a
directory service. Replication is employed under every circumstance that denies an
LDAP server the appropriate processing of incoming requests. The concept
comprises clients, masters, and slaves. The master, a special LDAP replication
daemon, offers the replication service to slaves. Modifications made by clients on the
master LDAP server are automatically forwarded to all relevant slaves. [Draft-LDUP]

An example for a directory service that covers multiple technologies is JNDI. Here, a
name is related to a naming context, which is the starting point for exploring a

TMF053, Version 5.7 TeleManagement Forum 2006 Page 83 of 96

The NGOSS Technology-Neutral Architecture

namespace. An initial context contains a variety of name bindings from one or more
naming systems [JNDI-API].

Visualization

Human-Computer Interaction (HCI) analysis defines design alternatives, data

structures, and evaluation of human factors in terms of efficiency for a variety of
tasks. Visualization and navigation on structured data must be seen as a single entity.
In the Curricula of HCI [Hewett96], the work is described as: “Human computer
interaction is a discipline concerned with the design, evaluation, and implementation
of interactive computing systems for human use and with the study of major
phenomena surrounding them.”

In the actual world of computing, human beings interact more with information objects
and less with computers. Hereby the computer is a tool that is used for the interaction
with information objects. HCI provides skills and techniques for information design
and makes computers more and more invisible. Interactions are split into the human
side and the mechanism side for one particular machine. The main fields of HCI are
[Hewett96]:
¾the tasks by humans and machines;
¾the structure of communication between human and machine;
¾human capabilities to use machines (including the learnability of interfaces);
¾algorithms and programming of the interface itself;
¾engineering concerns that arise designing interfaces;
¾the process of specification and design; and
¾the implementation of interfaces.
The first and central question at the beginning of a HCI process should be: “What is
the goal and how can it be achieved?” This question can be answered with a human-
machine categorization followed by a task analysis. One analytical method follows the
GOMS22 model [John96]. It provides a guideline to investigate tasks in the terms of
goal-directness, the amount of required skills, the control of interactions, and the
interaction sequences.

The characterization of tasks in the context of other tasks is another key concern in
HCI [Wright96]. Control of interaction can be done in an active or a passive context.
In the active context, the machine requires a direct action (e.g. a video game). In
passive contexts, tasks can be performed by the user at will because no direct
response is necessary (e.g. web browser).

The intended functionality is by, for example, commands a user can enter and
or/items he can selection completing a sequence of interactions. Input and output
devices and techniques should be predefined. The relevant input techniques which
best match with user requirements are to be determined. This can be keyboard-
based (e.g. commands, menus), mouse-based (e.g. picking, rubber-band lines), pen-

22
Components of a design model : Goals, Operators, Methods, Selection rules

TMF053, Version 5.7 TeleManagement Forum 2006 Page 84 of 96

The NGOSS Technology-Neutral Architecture

based (e.g. character recognition, gesture) or voice-based. Operating systems

usually offer guidelines ([Schlosser97] [MSDN-UI01]) for graphical user interfaces that
are supported by class libraries ([JAVA-J2SE]).

Dialogue is the technique for interaction with humans. [DIN96] describes sound
issues that need to be considered. Dialogues should work adequate, self describing,
controlled by hand, reaction conform, error tolerant, and individual to adapt. They
should also assist in learning to control an application.

The interaction can be done in a primary or secondary dialogue with a modal or

modeless category. A document based dialogue can be realized as a single
document interface (SDI) or a multiple document interface (MDI) [Balzert99]. New
developments and newly available technologies allow the application of avatars and
voice-based interactions with the user.

Some basic concepts of computer graphics are useful for HCI, too, like the use of
color, 2-D and 3-D spatial organization. The graphic representation of data can be
form based, diagram oriented, iconic, or a combination of all three representations
[Tiziana96].

Management Services

[ITU-X700] defines five functional areas for system management: Fault,

Configuration, Accounting, Performance, and Security (FCAPS). A variety of system
management functions is defined in the ITU recommendations X.730 up to X.799.
These management functions can be applied to control, administration, and
maintenance of applications, services, and resources. Service platforms enhance the
five functional areas with e.g. functions for subscription and service management
[TINAC]. Here, the management function is applied to the management of one
particular layer.

Fault management encompasses fault detection, isolation, and correction of

abnormal operation of the system. Faults cause systems to fail to meet their
operational objectives. Faults can be persistent or transient. Faults manifest
themselves as particular events. Error detection provides a capability to recognize
faults. Fault management includes functions to maintain and examine error logs,
accept and act upon error detection notifications, trace and identify faults, carry out
sequences of diagnostic tests, and correct faults.

Configuration management identifies, exercises control, collects data, and provides

data that allow management systems to initialize, start, operate continuously, and
terminate services and network elements. This includes functions to control the
routine operation, associate names with managed objects, initialize and close down
managed objects, collect information on demand about the current condition, obtain
announcements of significant changes in the condition of the system, and change the
configuration.

Accounting management enables charges to be established for the use of resources

in the system and for costs to be identified for the use of those resources. This
includes functions to inform users of costs incurred or resources consumed, enable
accounting limits to be set and tariff schedules to be associated with the use of

TMF053, Version 5.7 TeleManagement Forum 2006 Page 85 of 96

The NGOSS Technology-Neutral Architecture

resources, and enable costs to be combined where multiple resources are invoked to
achieve a given communication objective.

Performance management enables to evaluate the behavior of resources in the

system and the effectiveness of communication activities. This includes functions to
gather statistical information, maintain and examine logs of system state histories,
determine system performance under natural and artificial conditions, and alter
system modes of operation for conducting performance management activities.

Security management supports the application of security policies by means of

functions that include the creation, deletion, and control of security services and
mechanisms, the distribution of security-relevant information, and the reporting of
security-relevant events.

7.4. References for the Appendix

[3GPP-OSAReq] 3GPP: Stage 1Service Requirements for the Open Service Access (OSA). 3rd
Generation Partnership Project, Technical Specification, Release 5, Document
Number TS 22.127, June 2001
[Balzert99] Helmut Balzert: Lehrbuch Grundlagen der Informatik. Spektrum Akad. Verlag;
Heidelberg/Berlin; 1999
[Booz96] Booz Allen & Hamilton: Telekommunikation in der Welt von morgen:
Marktstrategien, Konzepte und Kompetenzen für das 21. Jahrhundert. Institut für
Medienentwicklung und Kommunikation (IMK), Verlagsgruppe Frankfurter
Allgemeine Zeitung, 1997
[Campolargo99] Mario Campolargo: Information society – R&D Challenges and Opportunities.
Invited Speech, 4th International Symposium on Autonomous Decentralized
Systems, ISADS’99, Tokyo, Japan, March 21-23, 1999
[CORBA] OMG: The Common Object Request Broker: Architecture and Specification.
Minor Editorial Version CORBA 2.4.1, OMG Document 00-11-03, November 2000
(Revision 2.4 October 2000)
[CORBA-MAN] CORBAMAN: CORBA Management Agent Generic and NE specific information
model. Revision 1.1, March 6th, 2001
available at <http://www.corbaman.com> (last visited 03/14/02)
[CORBA-NS] OMG: Naming Service Specification. Revised Version, OMG Document 01-02-65,
OMG, February 2001
[DCE-RPC] Open Group Technical Standard: DCE1.1: Remote Procedure Call. Document
Number C706, August 1997
<http://www.opengroup.org/publications/catalog/c706.htm> (visited on
09/07/2001)
[DIN96] DIN EN ISO 9241-10: Grundsätze der Dialoggestaltung. 1996
[DMTF-CIM] DMTF: Common Information Model (CIM) Specification. DMTF, Version 2.2, June
14, 1999
[Draft-ASN1NG] O. Dubuisson, P. H. Griffin, M. Perin, A. Sarma, B. Scott, A. Triglia: ASN.1 for
SMIng. IETF Draft, Networking Group, November 13, 2001
Document expires May 13, 2002
[Draft-Hohno] H. Ohno, R.Atarashi: The Emergency Communications on the internet. IETF
Draft, Version 0, November 2001

TMF053, Version 5.7 TeleManagement Forum 2006 Page 86 of 96

The NGOSS Technology-Neutral Architecture

[Draft-IEPREP] Hal Folts: Emergency Telecommunications Service in Evolving Networks. IETF

Draft, Version 0, February 15th, 2002
[Draft-LDUP] Ed Reed, Uppili Srinivasan: LDAP Replication Architecture. IETF Draft, Version
0.7, March 2002
[DRAFT-OPES] G. Tomlinson, R. Chen, M. Hofmann: A Model for Open Pluggable Edge
Services. IETF Draft, November 20th, 2001
[Hegering99] Hegering et.al.: Integriertes Management vernetzter Systeme. 1. Auflage, dpunkt
– Verlag für digitale Technologie, Heidelberg, Germany, 1999
[Heuer97] Andreas Heuer: Objektorientierte Datenbanken: Konzepte, Modelle, Standards
und Systeme, 2. Auflage, Addison Wesley Longman Verlag GmbH, Bonn, 1997
[Hewett96] Hewett, Baecker, Card, Carey, Gasen, Mantei, Perlman, Strong and Verplank:
ACM SIGCHI Curricula for Human-Computer Interaction. ACM SIGCHI, 1992,
1996
< http://sigchi.org/cdg/cdg2.html> (last visited 09/01/01)
[IETF-RFC1157] J.D. Case, M. Fedor, M.L. Schoffstall, C. Davin: Simple Network Management
Protocol (SNMP). IETF RFC 1157, May 01, 1990
[IETF-RFC1213] K. McCloghrie, M.T. Rose: Management Information Base for Network
Management of TCP/IP-based internets: MIB-II. IETF RFC 1213, Mar 01, 1991
[IETF-RFC1759] R. Smith, F. Wright, T. Hastings, S. Zilles, J. Gyllenskog: Printer MIB. IETF RFC
1759, March 1995
[IETF-RFC1905] J. Case, K. McCloghrie, M. Rose, S. Waldbusser: Protocol Operations for Version
2 of the Simple Network Management Protocol (SNMPv2). IETF RFC 1905,
January 1996
[IETF-RFC1906] J. Case, K. McCloghrie, M. Rose, S. Waldbusser: Transport Mappings for Version
2 of the Simple Network Management Protocol (SNMPv2). IETF RFC 1906,
January 1996
[IETF-RFC1958] B. Carpenter et. Al.: Architectural Principles of the Internet. IETF RFC 1958, June
1996
[IETF-RFC2234] D. Crocker: Augmented BNF for Syntax Specifications: ABNF. IETF RFC 2234,
November 1997
[IETF-RFC2396] T. Berners-Lee, R. Fielding, L. Masinter: Uniform Resource Identifiers (URI):
Generic Syntax. IETF RFC 2396, August 1998
[IETF-RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S.
Waldbusser: Structure of Management Information Version 2 (SMIv2). STD 58,
IETF RFC 2578, April 1999.
[IETF-RFC2616] R. Fielding et. al.: Hypertext Transfer Protocol -- HTTP/1.1. IETF RFC 2616,
June, 1999
[IETF-RFC2929] D. Eastlake, E. Brunner-Williams, B. Manning: Domain Name System (DNS)
IANA Considerations. IETF RFC, September, 2000
[IETF-RFC3216] C. Elliott, D. Harrington, J. Jason, J. Schoenwaelder, F. Strauss, W. Weiss:
SMIng Objectives. IETF RFC 3216, December 2001
[IETF-RFC3780] F. Strauss, J. Schoenwaelder: SMIng - Next Generation Structure of
Management Information. IETF RFC 3780, May 2004
[ISO8879] ISO 8879: Information Processing - Text and Office Systems - Standard
Generalized Markup Language (SGML). ISO, Geneva, Switzerland, 1986

TMF053, Version 5.7 TeleManagement Forum 2006 Page 87 of 96

The NGOSS Technology-Neutral Architecture

[ISO14977] ISO/IEC 14977: Information technology -- Syntactic metalanguage -- Extended

BNF. ISO, Geneva, Switzerland, 1996
[ITU-Q1201] ITU-T Recommendation I.312/Q.1201 (10/92): Principles of the Intelligent
Network Architecture. Geneva, Switzerland, October, 1992
[ITU-X200] ITU-T Recommendation X.200: Information Technology – Open Systems
Interconnection – Basic Reference Model: The Basic Model. International
Telecommunication Unit, Geneva, Switzerland, July 1994
[ITU-X208] ITU-T Recommendation X.200: Open Systems Interconnection – Model and
Notation – Specification of Abstract Syntax Notation One (ASN.1). International
Telecommunication Unit, Geneva, 1993
[ITU-X210] ITU-T Recommendation X.210: Information Technology – Open Systems
Interconnection – Basic Reference Model: Conventions for the Definition of OSI
Services. International Telecommunication Unit, Geneva, November 1993
[ITU-X501] ITU-T Recommendation X.501 (08/97): Information Technology – Open Systems
Interconnection – The Directory: Models. International Telecommunication Unit,
Geneva, August 1997
[ITU-X500] ITU-T Recommendation X.500 (1993): Information technology – Open Systems
Interconnection – The Directory: Overview of concepts, models and services.
International Telecommunication Unit, Geneva, 1993
[ITU-X700] ITU-T Recommendation X.700: Management Framework for Open Systems
Interconnection (OSI) for CCITT Applications. International Telecommunication
Unit, Geneva, September 1992
[ITU-X701] ITU-T Recommendation X.701 (1997): Information technology – Open Systems
Interconnection – Systems management overview.
[ITU-X710] ITU-T Recommendation X.710 (1997): Information technology – Open Systems
Interconnection – Common management information service.
[ITU-X720] CCITT Recommendation X.720 (1992): Information technology – Open Systems
Interconnection – Structure of management information: Management information
model.
[ITU-X721] CCITT Recommendation X.721 (1992): Information technology – Open Systems
Interconnection – Structure of management information: Definition of
management information.
[ITU-X722] CCITT Recommendation X.722 (1992): Information technology – Open Systems
Interconnection – Structure of management information: Guidelines for the
definition of managed objects.
[ITU-X901] ITU-T Recommendation X.901 (1997): Information technology – Open Distributed
Processing – Reference model: Overview.
[ITU-X920] ITU-T Recommendation X.920 (1997): Information technology – Open Distributed
Processing – Interface Definition Language.
[JAVA-J2SE] Sun Microsystems: J2SE API Specification Version: 1.3. Sun Microsystems, Palo
Alto (CA),2000
[JNDI-API] Sun Microsystems: Java Naming and Directory Interface – Application
Programming Interface (JNDI API). JNDI 1.2/Java 2 Platform, Standard Edition, v
1.3, Sun Microsystems, July 14, 1999
[John96] Bonnie E. John, David E. Kieras: Using GOMS for Interface Design and
Evaluation: Which Technique? Association for Computing Machinery Inc.,
Pittsburgh (PA) / Ann Arbor (MI), 1996

TMF053, Version 5.7 TeleManagement Forum 2006 Page 88 of 96

The NGOSS Technology-Neutral Architecture

[Linington95] Linington, P.: Why objects have multiple interfaces. ISO/IEC JTC1 SC21 / WG7
Draft answer to Q7/5, 1995
[Magedanz96] Magedanz, T., Popescu-Zeletin, R: Intelligent Networks. Basic Technology,
Standards and Evolution. Int. Thomson Computer Press, London, 1996
[Magedanz01] Thomas Magedanz: Enhancing Parlay with Mobile Code Technologies. Proc. of
the 6th IEEE Intelligent Network Workshop, IN2001, Boston, MA, USA, May 6-9,
2001
[MSDN-UI01] Microsoft: User Interface Design and Development. Microsoft Developer Network
MSDN
<http://msdn.microsoft.com/library/> (last visited 10/23/01)
[OMG-OMA] Object Management Group: A discussion of the Object Management
Architecture. OMG Document 00-06-41, OMG, January, 1997
[Orfali96] Robert Orfali, Dan Harkey, Jeri Edwards: The essential distributed object survival
guide. John Willey & Sons, New Yprk, 1996
[Palme02] Jacob Palme: Acomparision of ABNF, ASN.1, and XML. Course Internet
application protocols and Standards. last revised March 18th 2002
<http://www.dsv.du.se/jpalme/internet-course/Int-app-prot-kurs.html>
(last visited 05/19/02)
[Raymond95] Raymond, K: Reference Model of Open Distributed Processing (RM-ODP):
Introduction. Proc. of the International Conference on Open Distributed
Processing, ICODP’95, Brisbane, Australia, 20 - 24 February, 1995
[Röhricht01] Röhricht, J., Schlögerl, C.: cBusiness. Addison Wesley, München, 2001
[Scheer02] August Wilhelm Scheer, Thomas Feld, Sven Zang: Vitamin C für Unternehmen –
Collaborative Business. Reihe „Kompendium der neuen BWL“, Frankfurter
Allgemeine Zeitung, Nr. 53, Seite 25, Frankfurt, 4. März 2002
[Schlosser97] Otto Schlosser, Jun Suzuki: Mac OS 8 Human Interface Guidelines. Apple
Computer (CA), Technical Publications, 1997
[Stroustrup92] Bjarne Stroustrup: Die C++ Programmiersprache. Second Edition, München,
Addison-Wesley, Reading, Massachusetts, 1992
[Tannenbaum96] Andrew S. Tannenbaum: Computer Networks. Prentice Hall International, Third
Edition, 1996
[TINAC] <http://www.tinac.com/about/principles_of_tinac.htm> (visited 11/01/01)
[TINA-BM] TINA-C: TINA Business Model and Reference Points. TINA-C Deliverable, TINA
1.0, Version 4.0, May 20, 1997
[TINA-CMC] TINA-C: Computational Modeling Concepts. TINA-C Deliverable, TINA 1.0,
Version 3.2, Archiving Label TP_HC.012_3.2_96, TINA-C, May 17, 1996
[TINA-EMC] TINA-C: Engineering Modeling Concepts (DPE Architecture). TINA-C Deliverable,
Version 2.0, Archiving Label TB_NS.005_2.0_94, TINA-C, December 1994
[TINA-ODL] TINA-C: TINA Object Definition Language Manual. TINA-C Deliverable, TINA 1.0,
Version 2.3, Archiving Label TR_NM.002_2.2_96, TINA-C, July 22, 1996
[Tiziana96] Tiziana Catarci, Shi-Kuo Chang, Maria F. Costabile, Stefano Levaldi, Giuseppe
Santucci. A Graph-based Framework for Multiparadigmatic Visual Access to
Databases. Universita di Roma “La Sapienza”, Roma, 1996
[TMF-ACT01-99] TeleManagement Forum: Requirements of Management of ORB-based
Telecommunication Management Building Blocks. TIM/ACT Working Document,
Issue 1, August 2nd, 2000

TMF053, Version 5.7 TeleManagement Forum 2006 Page 89 of 96

The NGOSS Technology-Neutral Architecture

[Tönnby00] Ingmar Tönnby: It’s all about co…. 7th International Conference on Intelligence in
Services and Networks, IS&N 2000, Athens, Greece, February, 23-25, 2000
[W3C-XML] World Wide Web Consortium: Extensible Markup Language (XML) 1. W3C
Recommendation, 10-February-1998;
<http://www.w3.org/TR/1998/REC-xml-19980210> (last visited 11/01/01)
[W3C-XML-10P] World Wide Web Consortium: XML in 10 points;
<http://www.w3.org/XML/1999/XML-in-10-points> (last visited 11/01/01)
[Wright96] Peter C. Wright, Bob Fields, Michael D. Harrison: Distributed Information
Resources: A New Approach to Interaction Modelling. Dept. of Computer Science
University of York, Helsington/York, 1996
[Zeltserman99] David Zeltserman: A practical Guide to SNMPv3 and Network Management.
Prentice Hall PTR, Upper Saddle River, NJ, USA, 1999
[vdMeer02] Sven van der Meer: Middleware and Application Management Architecture. PhD
Thesis, Technical University Berlin, October 25, 2002

TMF053, Version 5.7 TeleManagement Forum 2006 Page 90 of 96

The NGOSS Technology-Neutral Architecture

Administrative Appendix
This Appendix provides additional background material about the TeleManagement
Forum and this document. In general. sections may be included or omitted as
desired, however a Document History must always be included..

About this document

The NGOSS Technology Neutral Architecture Specification is being issued as Public
Evaluation Version 5.5

The purpose of an Evaluation Version is to encourage input based on experience of

members and the public as they begin to use the document. Following the Evaluation
Period, documents that are seen to deliver value are candidates for formal approval
by the TM Forum. All documents approved by the TM Forum undergo a formal review
and approval process.

This document will continue under formal change control. Further work will be
reflected in revisions to this document.

Document Life Cycle

The NGOSS Technology-Neutral Architecture is being issued as Member Evaluation.
It can be considered valid until further notice. The purpose of an Evaluation Version
is to encourage input based on experience of members and the public as they begin
to use the document. Following the Evaluation Period, documents that are seen to
deliver value are candidates for formal approval by the TM Forum. All documents
approved by the TM Forum undergo a formal review and approval process.

This document will continue under formal change control. Supporting work will be
issued as companions to this document. A document of this type is a “living
document,” capturing and communicating current knowledge and practices. Further
inputs will be made because of detailed work ongoing in the TM Forum and the
industry.

Document History

Version History

Version Number Date Modified Modified by: Description of changes

1.0 2001.01.01 TMF Release for member
evaluation (reformatted)
1.01 2001.01.13 D. Raymer, Updates based on TMF
R. Trivedi membership evaluation

TMF053, Version 5.7 TeleManagement Forum 2006 Page 91 of 96

The NGOSS Technology-Neutral Architecture

1.02 2001.01.16 A. Vincent Dublin Meeting Rough

Changes
1.03 2001.01.24 A Vincent Post Dublin Review
1.04 2001.01.29 A. Vincent Post Dublin Review 2
1.08 2001.02.09 D. Lewis Dublin input edited for
consistency
1.09 2001.03.30 D. Raymer, Rework from Dublin, Paris
R. Trivedi Inclusion of ARCs and
Comments from
BAC/SDM
1.5 2001.04.27 TMF Updated for Member
Evaluation
1.60 2001.08.21 D. Raymer Updates based on Long
Beach TAW review
1.99 2001.09.07 D. Raymer Updates based on TSA
input. Release for working
team evaluation, prior to
general member
evaluation.
2.1 2002.05.02 J. Strassner Edits per
053_series_update_team,
concentrating on policy,
the shared
information/data model,
and process. Minor
editing and clarification
updates also included
throughout the document.
2.5 2002.05.27 TMF Formatted for Public
Evaluation
2.6 2002.12.23 J. Sventek Major edits reflecting red
team architectural
discussions with regards
to RM-ODP, binding,
contracts, etc.
2.7 2003.02.21 G. Covino major rearrangements of
contents in section 2 and
4 to clear distinguish
between requirements
and NGOSS principles;
other minor editing like
reducing details on Policy
and Process models
3.0 2003.04.07 G. Covino tuning of definitions,
general formatting
3.01 2003.07.01 G. Covino minor fixings
3.5 2003.07.08 TMF Formatted for Public
Evaluation with NGOSS
R3.5
4.0 2003.12.18 G. Covino fixing on security
references, aligned terms
with latest TMF053F
(CILS instead of SLS)
and TMF053B (contract
vs interface)

TMF053, Version 5.7 TeleManagement Forum 2006 Page 92 of 96

The NGOSS Technology-Neutral Architecture

4.0.1 2004.01.30 TMF Template & cosmetic

fixes
4.3.3a 2005.08.29 S. van der Meer Added Architectural
Concepts
4.3.3b 2005.08.31 S. van der Meer Re-organized section 2
and 3, added architectural
concepts
4.3.3c 2005.09.19 S. van der Meer Re-organized section 2
and 3, added ODP and
computational and
engineering aspect of
TNA
4.3.3d 2005.09.20 S. van der Meer Added annex on DIOA,
defining DIOA
4.5.1 2005.09.15 S. van der Meer Reorganized document
according to discussions
in TMW Montreal, added
annex for DIOA
4.5.1a 2005.10.05 M. Huddleston Editorial on DIOA, SOA et
al area
4.5.2 2005.10.07 S. van der Meer Addressed comments
and corrections for
section 2, finalized section
2, re-opened section 3
4.5.2a 2005.10.11 J. Strassner Review and minor edits of
entire document
4.5.3 2005.10.12 S. van der Meer Included input for sections
2.3, 4 and addressed
comments
4.5.3a 2005.10.12 J. Fleck Finalized section 4
4.5.4 2005.10.13 S. van der Meer Edited section 1, 2, 3, 7,
removed old section 5,
added new section 5
4.5.4a 2005.10.13 M. Huddleston Editing final comments
throughout
4.5.5 2005.10.16 S. van der Meer Formatting, figures, typos,
changed text in section 7
4.5.6 2005.10.16 M. Huddleston Grammar editing and
comment editing
4.5.7 2005.10.17 S. van der Meer Final check, minor typo
and figure caption
changes
4.5.8 2005.10.17 S. van der Meer Changed sequence of
sections 2.2.1.1 and
2.2.1.2
5.0 2005.10.17 J. Fleck Updated to V5.0, minor
corrections, added
Lifecycle Team and
Architecture Working
Group to active NGOSS
Teams, accepted various
changes and deleted
comments from working
text.
5.1 2005.10.18 J. Fleck Updated Figure 9 as per

TMF053, Version 5.7 TeleManagement Forum 2006 Page 93 of 96

The NGOSS Technology-Neutral Architecture

CCB comments.
5.2 2005.11.07 Tina O'Sullivan Updated template and
other cosmetic items.
5.3 2005.11.14 Tina O'Sullivan Removed section 8.
5.4 2006.07.24 J. Fleck Updated and corrected
Section 4 (includes
separation of NGOSS
Core and Container
Artifacts and Application
Definition as well as minor
error corrections)
5.5 2006.09.11 J. Fleck Update of Manageability
requirements for NGOSS
Software Artifacts to align
with forthcoming TNA
Manageability Addendum
5.6 2006, Sept. 25th Tina O'Sullivan Final updates prior to
submission to baseline.
5.7 2006, Nov 21 Tina O'Sullivan Approved by CCB to
enter Member Evaluation

Release History

Release Number Date Modified Modified by: Description of

changes
Release 6.0 2005.10.18 J. Fleck Official release with
NGOSS 6.0 Package
Release 6.3 2006.Nov.21 TNA team. Major updates to
TMF053-B and
associated sections.

Acknowledgments
This document was prepared by the members of the TeleManagement Forum
Lifecycle team – TNA working group:
Martin Creaner TeleManagement Forum
Tina O’Sullivan TeleManagement Forum
Joel Fleck Hewlett-Packard (team lead)
Dave Raymer Motorola
Martin Huddleston QinetiQ
John Strassner Motorola
Sven van der Meer Waterford Institute of Technology (current editor)

Additional input was provided by the following people:

TMF053, Version 5.7 TeleManagement Forum 2006 Page 94 of 96

The NGOSS Technology-Neutral Architecture

Geoff Coleman Briar Creek Limited

Giuseppe Covino Telecom Italia Group
Cliff C. Faurer TeleManagement Forum
Amr Elkady Alcatel
Alain Lemoine Eftia OSS Solutions
Jerry McCollom Agilent Labs
Michael Ogg Valaran
Joe Sventek University of Glasgow
John Kaplan Connexn Technologies
Steve Afrin ComInsights
Francis Anderson Tivoli
Francesco Caruso Telcordia Technologies
Cindy Cullen Telcordia Technologies
Tony Dean TeleManagement Forum
Petre Dini Cisco Systems
Paul Doyle ADC Telecommunications
Jane Fox Telcordia Technologies
Wedge Greene Worldcom (sponsor)
Carlton Hall CH2M Hill
Matt Izzo Agilent
Paul Levine Telcordia Technologies
Dan Matheson Hewlett-Packard
Bruce Murrill TeleManagement Forum
Christopher Prowse Defense Evaluation and Research Agency (UK)
Jonas Rabin Lucent Technologies
Jean-Luc Richard Evidian
Tony Richardson TeleManagement Forum
Jeff Risberg TIBCO
Ken Roberts Cisco Systems

Enrico Ronco Telecom Italia Group

Edward Scott PrismTech
Al Vincent TeleManagement Forum
Stuart Ward Orange
Jim Willits Hewlett-Packard
Willie Donnelly Waterford Institute of Technology

TMF053, Version 5.7 TeleManagement Forum 2006 Page 95 of 96

The NGOSS Technology-Neutral Architecture

Mícheál Ó Foghlú Waterford Institute of Technology

About TeleManagement Forum

TeleManagement Forum is an international consortium of communications service
providers and their suppliers. Its mission is to help service providers and network
operators automate their business processes in a cost- and time-effective way.
Specifically, the work of the TM Forum includes:
¾Establishing operational guidance on the shape of business processes.
¾Agreeing on information that needs to flow from one process activity to
another.
¾Identifying a realistic systems environment to support the interconnection of
operational support systems.
¾Enabling the development of a market and real products for integrating and
automating telecom operations processes.
The members of TM Forum include service providers, network operators and
suppliers of equipment and software to the communications industry. With that
combination of buyers and suppliers of operational support systems, TM Forum is
able to achieve results in a pragmatic way that leads to product offerings (from
member companies) as well as paper specifications.

TMF053, Version 5.7 TeleManagement Forum 2006 Page 96 of 96