In Chapter One of the Guide to Modern OSS we start at the very beginning: What is OSS and why is it needed?
OSS is IT for running a communications network.
OSS includes software, hardware, integration between systems, and business processes. As a collection of integrated applications, OSS supports the design, build and running of both the communications network as a whole and the individual services that make use of that network.
OSS encompasses many highly technical network management processes but ultimately its purpose is to ensure the network is efficient, services are profitable, and customers are happy.
We’ve introduced a lot of concepts there already, so let’s start by looking at the acronym OSS: What does OSS stand for?
What does OSS stand for?
OSS stands for either “Operational Support Systems” or “Operations Support Systems”.
“Operational Support Systems” is perhaps more commonly used. But don’t worry, you won’t sound dumb if you use either operations or operational.
Let’s break it down further…
Relating to the day-to-day tasks of supplying and supporting communication services. Getting technical and infrastructure jobs done. Running the network and services. As opposed to the business of selling, marketing or billing (which, as we will see later, are tasks that belong to BSS).
Enabling and improving the service provider’s operational activities: Automating operational tasks; executing them faster; making them consistent; and tracking progress/results.
One or more distinct software applications, that are responsible for doing specific OSS jobs, running on servers, or on devices installed in the network, or executed in the Cloud.
The role of OSS
OSS includes a large number of applications that a service provider requires in order to perform ‘back-office’ activities. The service provider’s ‘OSS environment’ will include many (from tens to hundreds) of separate OSS applications, each responsible for their own part of the businesses’ operation. Usually OSS applications are function-specific, owning part of the entire operations process such as monitoring for faults, fulfilling service requests, and so on.
Being focused on the network and services, OSS is used by network planners, service designers, and engineering teams. Increasingly marketing, product managers and senior staff under the CTO or COO also rely on OSS to gather data on the network state to plan strategic changes.
These are all common names for what most people in the industry now call “communication service providers”: A business that maintains a network and sells telecommunication services.
OSS & BSS
If there’s ‘back-office’ tasks there must also be a ‘front-office’ and indeed there is. More accurately called Business Support Systems (BSS), these are a separate set of applications supporting commercial, revenue and customer-relationship activities.
Combined, OSS and BSS cover the entire footprint of specialized IT applications a service provider will use to run a network and sell services.
An analogy to businesses that have customer-facing staff on the front-desk and technical boffins making stuff in the workshop out the back.
The analogy with front-office is stretched to include other points of interaction with the customer, such as call-centres and web portals.
The basics of communication networks
Let’s introduce an example now, and also explain why a modern communication network needs OSS.
A communications network is responsible for getting data from A to B. A and B might be mobile or land-line handsets, computers or servers. The data being carried from A to B includes our voices, a text message, emails and files. In modern networks everything being communicated between two points is data.
So, the things that make up a network are mainly concerned with receiving and transmitting data to carry it across the network.
A network includes hundreds or thousands of devices whose job is to move our data around.
Generally, the further the data needs to be carried and the more people or things that are communicating, then the more devices there are in the network.
We will use the term device to mean any piece of equipment that is responsible for receiving, routing, switching or transmitting data. Other commonly used terms are Network Element (NE), Managed Element (ME), Managed Device (MD).
Each device in the network is relatively simple. It either prepares or receives data and then determines where to send the data next, to get one ‘hop’ closer to the destination. It might also do other tasks such as checking the integrity of the data, making security checks, caching or compressing data and manipulating the data flow to put it on to a different type of network (for example, to take data off a radio interface and on to a fibre-optic network).
Devices come in different ‘sizes’ both in terms of how many other devices you can connect it to and how much data can be sent down each connection (commonly called bandwidth).
You will often find a large number of smaller devices in the ‘access’ network where customers connect to the network, then fewer but larger devices in the ‘core’ that carries vast quantities of data between regions.
Managing the network
To operate a network you need to know what devices you have, where they are, be able to check their configuration and reconfigure them to ‘route’ data across the network (get it from A to B in the quickest or cheapest or most reliable way).
And you need to keep an eye on the devices’ state to check there are no faults while ensuring their secure operation.
The International Organization for Standardization has a name for these network management processes – FCAPS – and it’s a good place to start.
The FCAPS guide to network management
FCAPS is an acronym for Fault, Configuration, Account, Performance, and Security.
These five simple categories cover a broad set of network management processes that must be addressed by the CSP to ensure the network is operated reliably.
Things go wrong. Devices fail. Connections between devices get cut. People accidentally reconfigure one thing which breaks another thing.
Fault management is about responding to ‘alarms’ from the network (as many devices can remotely report a fault, which is helpful) and diagnosing harder to find faults.
A big part of fault management is tracking problems, identified by the network devices or the customers, through to resolution.
Devices need to be configured to function as required and to enable them to talk to other, networked devices. Much of this has to be done remotely, as a device may be hundreds of miles away from the engineer responsible for carrying out the work.
Configuration can include minor changes to improve performance, routing of a new customer service, updates to connect new bits of network, and major changes to devices’ software or firmware.
Account management is the act of collecting statistics on how a service is being used, primarily for billing purposes. BSS applications are most involved in this management process.
Increasingly there is a need for OSS to be involved with Accounting – More sophisticated services and particularly their ‘Service Level Agreements’ require greater understanding of how a service is being supported by multiple devices across the network. Therefore Fault and Performance management data will feed in to the Account management.
Network devices and individual services must be monitored to ensure they are delivering the capabilities they were configured to deliver. Statistics can be collected from the network to aide understanding of how well data is flowing. In a modern network, performance management is as critical to operations as fault management. If service performance degrades for a customer, the impact for them can be as disruptive as a physical fault.
Networks must be secured to permit only authorized staff to configure devices or services. Security also ensures customers only have to access resources they are entitled to use.
In modern networks there is a cross-over in the roles of Security and Configuration management: As services become less fixed to a single location or device, customers are accessing services from many locations on many devices. Services no longer benefit from the simple security of being ‘hard wired’ to a single premise or terminal. Security must be managed for every customer interaction with the network.
Sounds simple enough?
If you run a network with just a few devices from the same supplier, you probably don’t need sophisticated OSS applications. You can get by with the tools that the supplier gives you and some simple spreadsheets or databases to keep track of things.
For example, from your workstation you could log-on to each device directly, through a ‘command line’, to see its state and reconfigure it. And you could manage many aspects of network security with simple desktop IT applications.
But in a network run by even a small telecommunications company, things are rather complex.
Scale – the number of things you need to manage and the number of decisions you need to make – quickly makes running the network extremely challenging.
and how OSS can help
How big is a CSP’s network? The answer obviously depends on the region they are serving and how many customers they have.
Even a small European telecommunications company probably has thousands of devices to manage, across several different technology types like IP, optical and radio. In addition they need to manage each service across that network too, for hundreds of thousands, or millions of customers.
A typical national North American CSP would be at least ten times bigger.
A large Asian operator, another five to ten times bigger.
You can’t keep track of a quarter of a million network devices and one hundred million customers using a spreadsheet.
Network devices are distributed over a wide area, such as a city or country: Device can be installed in roadside cabinets, on antenna towers, in telephone exchanges, and many other types of site. The CSP needs to know what equipment is installed, where, so that planning can be carried out without requiring a visit to site to determine what devices are available or how much physical a site has to accommodate more devices. OSS applications employing databases, floor plans and mapping services exist to manage these records.
Network devices are distributed over a wide area, such as a city or country: Device can be installed in roadside cabinets, on antenna towers, in telephone exchanges, and many other types of site.
The CSP needs to know what equipment is installed, where, so that planning can be carried out without requiring a visit to site to determine what devices are available or how much physical a site has to accommodate more devices.
OSS applications employing databases, floor plans and mapping services exist to manage these records.
Most CSPs are supplied devices by two or more device vendors. Each vendor can supply their own Network Element Manager (NEM) or Element Management Systems (EMS) which connect to the devices to support basic configuration and fault management.
However, these applications only offer their full functionality for the vendor’s own devices. In order to configure a service across the entire network, the user has to tap details in to each vendor’s NEM or EMS. Each has its own user interface, its own way of working, and this naturally can lead to a complicated process.
Many OSS applications are designed to do their job on multiple vendors’ devices, ensuring consistency and streamlined network management processes.
Most CSP networks are made up of several different technologies. Networks still rely on technology deployed many years ago to deliver services today.
Even a new, modern network would likely comprise radio devices for mobility, IP devices for flexible data routing, and optical devices for its high-capacity bandwidth.
As a service uses several technologies to carry data from A to B, how these technologies interact can be very complicated and subject to many rules and constraints.
OSS is used to manage the complexity of network planning and service design by using templates, rules and step-by-step processes to guide users.
If you’ve ever tried to get multiple people to work on the same spreadsheet file, you know how many problems arise. The file may be locked when you want to update it. One person might overwrite another person’s updates.
In a CSP, dozens or even hundreds of people are involved in network operations at the same time. Planners, engineers, support staff, marketing, all needs to manage the network and report on the current state of devices and services.
OSS applications are designed to share data with many users, implement data update rules, and control processes that need input from different users at different stages.
FCAPS might only be five letters, but that hides a huge number of tasks to be carried out by the CSP. TM Forum’s ‘map’ of CSP business processes – eTom – comprises over thirty process categories. Each category will itself involve several monthly, daily or constant management tasks.
Automation of these tasks is frequently the responsibility of OSS applications. In many cases OSS applications can cut the time it takes to complete a repetitive task, like routing a customer’s service, from hours of manual work to just a few seconds.
OSS also makes task consistent, enforcing rules about how they are carried out, and providing updates to other systems such as the BSS (to notify customers of progress) and management reporting.
Each individual device may be simple, just routing or switching data, but they are configurable and flexible. Which devices should you connect together? How much capacity should you put in each connection, considering the cost and customer demand? What’s the best ‘route’ through the network for a particular service considering cost, bandwidth, and reliability? What happens if there’s a sudden peak in demand somewhere?
These aredifficult decision to make if the network is bigger than you can draw on a single piece of paper. A big part of OSS is analysis of networks and services, resulting in intelligent decision making, optimal network design and efficient service routing.
Let us not forget that the network of a CSP exists tomake money by selling communications products to customers.
In the not-too-distant-past, most CSPs made money from just one communication product: Plain, old telephony.
The modern trend is for more products, more customisation of services, and more ways to access those services. CSPs want to quickly create new products, and test them in the marketplace, in order to keep up with rapidly changing consumer trends.
With its detailed network records, OSS can be used to identify products that can be sold in particular regions. By simplifying and automating operational tasks, OSS can enable new products to be constructed from ‘building blocks’ of network resources.
OSS to the rescue
In summary, Operational Support Systems are IT tools and applications used to monitor and manage large communications networks.
The challenge ofrunning an efficient and profitable network, with even just a few hundred devices and customers, means OSS is a necessity for all communication service providers.
In this chapter we have briefly introduced how OSS can address the operational challenges of network management.
In the next chapter, we’ll look at the different types of OSS application that a CSP may choose to employ, and the business processes they support.
Which OSS applications a CSP chooses to invest in will depend on the return on that investment, in terms of revenue and cost-savings. And that, in turn, depends on many technical and economic factors.
John McVey, Managing Director at DonRiver, shares his views on what makes an OSS project successful.
To stay competitive in today’s market, telcos must have the ability to offer new services to their customers and be able to deliver those services efficiently.
The most successful telcos achieve this agility by employing a number of OSS solutions. But it is not simply a case of buying the right software and systems.How the solution is deployed and integrated is critical to success.
Consider, as an example, network inventory data migration, which is often the most complex aspect of implementing many types of OSS solutions.
It can be tempting to start from scratch to create unique data-integration tools.
While it’s important to realise that one Telco’s combination of OSS systems and data is unique to them, there is no need to re-invent the wheel when it comes to data migration.
There are tools that have saved telcos millions of dollars of reduced effort and increased performance. Some solutions are specific to an OSS product, others have been designed to support numerous products.
Hacking new code may initially appear relatively cheap and flexible, but the benefit of investing in a dedicated solution is that proven, high-performance integration significantly de-risks the project and shortens deployment timescales.
So, research your options early, choose a partner or supplier who can confidently offer a data migration solution, rather than assuming it will somehow be solved by a few developers in a future project phase.