What are OSS applications? The level of complexity that some definitions (like eTOM and TAM) use to describe OSS is quite breath-taking. Here’s a much simpler way to talk about OSS…
This article is taken from The Guide to Modern OSS, our free 79 page ebook you can download now.
Commercially available OSS applications do not neatly map on to any standards-based definitions like eTOM, TAM or FCAPS. A suite of applications from one vendor will most likely address a few functions completely, but maybe not a full end-to-end process. The features they do have may also partly address other functionality and overlap other processes.
Keep it simple
It is best to take a high-level view of the OSS application landscape when you are in the initial stages of an OSS project. Work with enough details to identify each vendor’s product, to understand the primary roles of the systems you already have, and to create your project strategy.
Later, when there is a need to specify the system integration of OSS applications, and mapping business functions to processes and data, only then an OSS Solution Architect or Business Analyst might want to use a tool as detailed as the eTOM.
OSS in the middle
OSS is concerned with the operation of the network and the technical aspects of services. Broadly speaking OSS sits between a CSP’s other IT systems: BSS applications, and the management systems and controllers of the network layer.
The OSS layer is heavily influenced by demands and trends in the customer-facing BSS layer and the technology of the network layer, so we will take a look at these two layers first.
The BSS layer
The BSS layer is concerned with the service’s customer, commercial and contractual considerations.
The interface between OSS and BSS is usually pretty clear:
- Orders for new or modified services are collected by BSS and passed to OSS for activation on the network
- Network state and usage is passed from OSS to BSS for tracking quality and service usage
- And, increasingly, technical capabilities of the network are shared between OSS and BSS to facilitate service catalogs and design of products for customers.
It is convenient to assume that the BSS layer is completely isolated from the network by the OSS layer. Certainly, OSS applications are responsible for many tasks bridging BSS and the network, but bear in mind that the BSS does have its own interfaces to the network layer.
A classic example is mediation.
Mediation applications are responsible for taking data from the network relating to how individual services use resources. CDR (call detail records) and IPDR (Internet Protocol Detail Record) are two examples of ‘raw’ statistics available from network devices. Mediation applications are responsible for pulling this data from network devices, filtering and processing it in to a common format for use by BSS charging and revenue assurance applications.
There are only a few examples of BSS interfacing to the network, and those that do exist are almost all ‘read-only’, importing and analyzing data.
That said, analysis of network data and the trend of Big Data means this is a growth area: Understanding the current state or change in the network can be used to gain valuable insight in to both the customer’s behavior and the quality of service they are enjoying.
Any non-trivial process that requires an understanding of how devices and services actually work, particularly if a change to the network is required, will reside in the OSS layer.
So, job #1 of the OSS layer is to mediate between the network and the business of keeping customers happy.
The network layer
While OSS is concerned with the operation of the network, the network itself is capable of significant ‘self-optimization’ while also supporting at least basic functions to enable manual configuration, fault finding and monitoring of individual pieces of equipment.
In a traditional optical, switched and IP network, the Network Layer is the devices, their operating systems, and their built-in interfaces.
These interfaces support integration between the network and OSS applications. Typical integration supports: Modification of the network for planning and service fulfilment purposes; Reporting of alarms from devices to the OSS layer for tracking and resolution; Real-time statistics on network utilization and performance, and service quality.
Emerging ‘virtualization’ technologies like SDN and NFV are starting to take some functionality and logic out of the devices, to be executed and controlled centrally. For example, today an IP device is responsible for working out the ‘next hop’ to pass data to get it from A to B. An SDN enabled device would defer this decision to a centralized controller.
This simplifies the line between the OSS layer and network layer, since OSS applications can now interface with a centralized controller for the domain. An SDN controller could make design and routing decisions that would previously have been carried out by an OSS application.
We will discuss the implications to OSS of new network technologies like SDN and NFV in a later chapter of the Guide.
The OSS layer
Let’s get back to the OSS layer.
The trends in customer-focus, service quality and network virtualization must be reflected in the capabilities of the CSP’s OSS environment.
The customer comes first, but we’re going to start by looking at the network-facing applications. Why? Most CSPs don’t start with a blank page: They have a network from which they need to deliver customer services, build new types of service and generate revenue. And many OSS applications depend upon or build on the underlying network-facing application.
In The Guide to Modern OSS, we will look at the major categories of OSS applications, from network-facing to customer-facing. For each, we will introduce the main functions which approximate to the individual software modules you can buy or build.
So, as we present each category of OSS applications, we’ll be putting together the nuts and bolts to build an OSS environment for an efficient, profitable, modern CSP.