NGOSS (New Generation Operations Systems and Software)

  Definition

NGOSS is the TeleManagement Forum (TM Forum) business solution framework for creating next generation OSS/BSS software and systems. The NGOSS program is delivering a framework for producing New Generation OSS/BSS solutions, and a repository of documentation, models, and guidelines to support these developments. The goal of NGOSS is to facilitate the rapid development of flexible, low cost of ownership, OSS/BSS solutions to meet the business needs of today, cost conscious, competitive, and rapidly evolving telecom environment.

  Overview of NGOSS


  The key elements of NGOSS

  • Enhanced Telecom Operations Map (eTOM™)

    • The eTOM provides the map and common language of business processes that are used in Telecom Operations. The eTOM can be used to inventory existing processes at a Service Provider, act as a framework for defining scope of a software-based solution, or simply enable better lines of communication between a service provider and their system integrator.

  • Shared Information/Data Model (SID)

    • The shared information and data model provides a "common language" for software providers and integrators to use in describing management information, which will in turn allows easier and more effective integration across OSS/BSS software applications provided by multiple vendors. The SID provides the concepts and principles needed to defined a shared information model, the elements or entities of the model, the business oriented UML class models, as well as design oriented UML class models and sequence diaframs to provide a system view of the information and data.

  • Technology Neutral Architecture (TNA) and Contract Interface

    • In order to successfully integrate applications provided by mutiple software vendors, the 'plumbing' of the system must be common. The Technology Neutral Architecture defines architectural principles to guide OSS developers to create OSS components that operate sucessfully in a distributed enviroment; and the Contract Interface definesthe "API" for interfacing those elements to each othe across the architecture. This architecture is called specifically called "Technology Neutral" as it does not define how to implement the architecture, rather what principles must be applied for a particular technology specific architecture to be NGOSS compliant.

  • NGOSS Compliance

    • In order to improve the probability that OSS components will truly intefrate with each other, NGOSS provides a suite of tests for compliance to the eTOM, SID, architecture, and contract interface components. NGOSS compiance can be archieved any or all of these components either singly, or in combination with other components.

  • Practical implementations and demonstrations of these solutions through a series of multi-vendor collaborative Catalyst projects
  NGOSS design goals

  • Focusing of corporate data
  • Physically and logically centralized data, providing more integrated views of customer and operational data
  • Loosely coupled distributed systems
  • Move away from stand alone OSSs to more of a common infrastructure for management process interaction
  • Application components/re-use
  • Functional re-use of business process components
  • Code re-use of software components
  • Increased use of object oriented design
  • For components of OSS functionality as well as modeling managed devices
  • Improved development time, costs, etc.
  • Technology-neutral system framework with technology specific implementations
  • Multi-vendor supply and integration
  • General purpose (cost effective) systems access
  • Operational staff low cost access to data/processes
  • Customer system interoperability to service provider data/processes
  • Separation of control of business process flow from business component operation
  • Provides flexibility to rapidly produce new business solutions
  • Allows more re-use of business components across multiple business scenarios
  • Workflow automation
  • Ability to automate present manual tasks
  • Flexibility to change business process sequence
  • Legacy/heritage systems
  • Ability to integrate existing systems in OSS infrastructure
  • Application of adaptation and wrapping techniques
  References

  Download - freely available (.pdf files)