What are Operational Support Systems (OSS) and

BSS in Telecom?
What does OSS (Operational Support Systems, aka Operations Support Systems) mean
exactly? Or BSS (Business Support Systems) for that matter? Where do OSS/BSS
intersect and/or overlap?
OSS is a term used to describe the information processing systems used by operators to
manage their communications networks. Originally known as Telecommunication
Network Management tools, these solutions are now so much more sophisticated. They
allow an organisation to coordinate customers, services, resources, processes and
activities. They assist operators to design, build, operate and maintain communications
networks. Traditionally, OSS tended to provide network-facing or network-operations-
facing functionality. This includes fault and performance management (assurance),
customer activations (fulfillment), asset / inventory / configuration management, network
security and so much more.
Business Support Systems (BSS) is the term traditionally used to describe the business
and/or customer-facing functionality. These tools allow an organisation to connect with
their customers (eg Customer Relationship Management or CRM), create offers for them
(eg Products / Services), issue customers with bills (eg Billing and rating) as well as
cross-carrier transactions (settlements, point-of-interconnect).
Together, OSS and BSS allow network operators to efficiently and reliably offer services
to enormous numbers of subscribers on some of the world’s most complex machines,
global telecommunications networks.

We’ve prepared the following playlist of videos to provide an introduction to OSS and
BSS. This is a multi-part series that answers these introductory questions and others,
including:

 Part 1 – What is an OSS? What is a BSS? Why are OSS and BSS even a thing?
 Part 2 – Who uses an OSS and/or BSS?
 Part 3 – What Functions do OSS and BSS Perform?
 Part 4 – What Business Benefits do OSS/BSS Generate?
 Part 5 – What’s the difference between an OSS and BSS?
 Part 6 – How do OSS & BSS interact with a Comms Network?
 Part 7 – What does an OSS/BSS look like?
 Part 8 – Where can I Find Out More About OSS and BSS?:
Additional details are provided in the sections below.

From the early days of telecommunications carriers (the companies that offered
telecommunications services such as telephony), these activities were performed
manually. With the advent of computers, carriers began to harness their processing
power by developing applications to help them operate their vast networks and
subscriber lists.

These early software applications had a narrow range of functionality. However, different
business units within the carriers soon sought to improve efficiency and sharing data by
integrating them. For example, a customer would place an order and their details would
be stored in one system. The designers would then record the customer’s specific
design configuration in another system and then this design would be implemented into
the telephone exchange itself. In this case, the automatic sharing of information between
systems is known as flow-through provisioning but requires significant integration effort.

A series of standards began to form around these applications so that there was
consistency between applications. Some of them are described below so read on, or just
click on a link to jump to the section most relevant to you.

1.1 TMN (Telecommunications Management Network) from ITU-T

1.2 FCAPS Model
1.3 Telecommunication Management Forum (aka TM Forum), including Frameworx (TAM,
eTOM and SID), Open APIs and ODA
1.4 ITIL/ITSM
1.5 3GPP Standards
1.6 Standards Compliance
1.7 Registration Authorities
1.8 Emerging Standards, including SDN, NFV, ONAP and more
1.9 Virtualisation and Open Source
1.10 The Business Case for OSS/BSS
1.11 What’s next (including OSS/BSS in the clouds)?
1.12 Additional Information
1.1 TMN (Telecommunications Management Network) from ITU-T

In the early days OSS integration tended to require bespoke solutions. Efforts to bring a
level of standardisation to OSS integration resulted in the ITU-T developing the TMN
(Telecommunications Management Network) series of standards in 1988. These are
clustered in the M.3000-M.3599 number range in ITU’s M-series of standards. These
standards identified the following four layers of functionality

Note: This image was originally sourced from

www.dhyan.com/newsletter/oct_06/index.html but this link is no longer available.

The TMN Logical Model is presented in Recommendation M.3010. It is commonly

referenced as the TMN pyramid and identifies four logical layers of network
management:
Business Management Layer (BML) – represents the functionality relating to strategic
business planning such as trending, quality, etc and provides the basis for billing,
budgeting and goal-setting.
Service Management Layer (SML) – is responsible for defining the services offered by
the carriers. This provides the interface between a customer’s services and the network
including definition, administration and charging.
Network Management Layer (NML) – provides the overall management view of the
network as a sum of component parts. This is particularly necessary for representation
of end-to-end concepts such as circuits that traverse multiple element management
domains. Is responsible for the end-to-end supervision, configuration and control of the
network.
Element Management Layer (EML) – provides definition and coordination of a collection
of network devices, albeit a sub-set of the entire network. This layer would normally
include consolidation of alarm management, backup, logging, and maintenance of the
systems that support the network devices.
We also claim that there are two additional layers to consider:

A fifth layer, Network Element Layer (NEL) – Represents the network devices

themselves that the customer’s services traverse.
A sixth layer (not shown on this diagram below), the Physical Layer (PHY) – Represents
the connectivity between devices, including cables, joints, patch-panels, patch-leads,
etc.
The diagram also shows the directions of many common workflows through an TMN
stack. A more detailed description of these flows and their interactions with network
inventory can be found in this article.

It should be noted that there are no strict boundaries to these levels of abstraction,
meaning that each vendor’s product position within the management system continuum
can be blurred and resultant terminology can be confusing. In Common Terminologies we
provide a discussion on the terminology that is commonly used in the industry and help
the reader to better understand the ways that these terms are used in the context of
PassionateAboutOSS.com.
Management Functional Areas presented in ITU/T Recommendation M.3400 include:
1) Customer Administration;
2) Network Provisioning Management;
3) Work Force Management;
4) Tariff, Charging and Accounting Administration;
5) Quality of Service and Network Performance Administration;
6) Traffic Measurement and Analysis Administration;
7) Traffic Management;
8) Routing and Digit Analysis Administration;
9) Maintenance Management;
10) Security Administration;
11) Logistics Management.

In the early days in particular ITU-T provided many useful OSS/BSS recommendations.
For example, ITU-T’s recommendation X.733 provided an early framework and common
model for classification of alarms. This allowed OSS vendors to build a standardised set
of functionality and filters (eg severity, probable cause, etc). ITU-T’s recommendation
M.3703 then provided a set of guiding use cases for managing alarms.
1.2        FCAPS Model

Further extension of TMN model occurred when ITU-T incorporated ISO’s FCAPS

(Fault, Configuration, Accounting, Performance and Security) model into their
recommendation on Management Functions (M.3400).
Fault management – Aims to identify, isolate, remedy and log negative events that occur
within a network. Fault logging can be extended to include trend analysis as a means of
predicting errors or abnormal behaviour on the network. Network devices are able to
propagate faults to higher network management layers that then provide advanced
functionality such as root cause analysis. Fault severity analysis can be used to prioritise
fault remediation activities.
Configuration management – Aims to store the attributes (or configurations) of network
devices allowing the tracking of network resources and changes in the network. Pushing
changes to the network, also known as provisioning, allows configuration updates such
as the creation of circuits or paths through various network devices. Tracking of status
allows an operator to plan for future designs and network build-out.
Accounting management – Aims to gather statistics for users such that billing
characteristics and usage quotas can be managed. RADIUS and TACACS are
commonly used protocols for accounting management. In some cases, the A in FCAPS
represents Administration, the management of authorised network users, permissions
and operational activities
Performance management – Aims to gather statistics that determine the level of efficiency
that the network is operating at. The actual statistics, or counters, recorded can vary
widely between network device types, determined by the specific performance analysis
needs of the device. Counters can include throughput, signal strength, resource
utilisation, error rates, latency, etc. These performance statistics can also be used to
analyse capacity or reliability trending. By establishing threshold analysis of counters,
such as failure rates, operators can be alerted to imminent fault conditions or
establishment of load balancing measures to alleviate underperformance of the network
before the issues become service affecting.
Security management – aims to control access to network assets, securing against
unauthorised access.
1.3        Telecommunication Management Forum (TM Forum)
Evolution of the networks under management and sophistication of the services offered
across them lead to the establishment of TM Forum‘s New Generation Operations
Systems and Software (NGOSS) program. Rapidly evolving business models have
necessitated more agile evolution of OSS tools.
Through collaboration by numerous service providers and equipment manufacturers, TM
Forum models have gained widespread use in the field of OSS implementations. The
main reference models of TM Forum’s Frameworx are:
 An application model (the Telecom Applications Map or TAM) – Provides a
modular framework of management functional blocks. This helps to provide
greater consistency (and compatibility) between the  product suites of different
vendors

ASIDE: The TAM is a great framework. However, we’ve found that it can be
overkill for some smaller telcos and OSS/BSS suppliers. As a result, we often
use The Simplified TAM for functionality discussions and categorisation. It should
be noted that The Simplified TAM is not supported by the TM Forum, nor in
widespread use.
 A process model (the enhanced Telecom Operation Map, or eTOM) – aims
provide a common language and catalogue of business processes used in
telecommunications environments. This level of standardisation aims to simplify
the lines of communication between service providers and associated systems
integrators. The diagram below provides an overview of the process building
blocks that eTOM provides
This diagram (sourced here from TM Forum) does a great job at describing how
the many atomic process pieces (top right) provided can be assembled into a
process flow (bottom right)

Note:  You can also find further information about designing process flows using
eTOM here. It provides a brief description of how to use the eTOM frameworks to
develop flows suited to your organisation and your OSS/BSS. This includes
analysis of a sample Request to Answer (R2A) flow, as described in eTOM
Addendum E (TM Forum’s GB921E). GB921E includes many other worked
examples including:
 Order to Payment (O2P)
 Problem to Solution (P2S)
 Usage to Payment (U2P)
  Note: In addition to GB921E, you can find out about many more
about these workflow acronyms / descriptions here
 An information model (the Shared Information / Data model, or SID) – aims to
define the essential entities, relationships and attributes of data objects prevalent in
telecommunications applications / databases. It also provides a common language
for use by OSS developers / integrators. TMF has also sought to develop
standardised SID-based APIs (Application Programming Interfaces) such as OSS/J
to expedite integration of disparate systems
 A system integration framework (the Technology Neutral Architecture, or TNA)
– aims to provide architectural standardisation, whilst remaining technology
neutral, including common interfaces, mechanisms and policies. Integration is also
commonly known as the TM Forum Integration Program (TIP)
But there are some newer weapons in the TM Forum arsenal that appears to be gaining
widespread use.

First is the TM Forum Open API suite, which has over 50 REST-based APIs as well as
having many more under development. This link provides a discussion as well as
references to the full list of APIs, including specifications, swagger files and postman
collections.
The following diagram comes from the Open API Map (GB992) (accurate as of 9 Jan
2018).

Next is the TM Forum Open Digital Architecture (ODA), an evolving standard that
intends to set a new vision for OSS/BSS. It aims to unite the world’s leading service
providers, technology providers and individual thinkers to create a more modern version
of OSS/BSS.
Contributors to this evolving standard are also cognisant that there are many OSS/BSS
that have to transform with the ODA. This means that existing Frameworx concepts such
as eTOM, TAM and SID will be accommodated by ODA. Similarly, collateral developed
through evolving initiatives such as the Open APIs and ZOOM (Zero-touch
Orchestration, Operations and Management) will also be utilised.
The ODA design attempts to isolate changes within functional blocks. It does so through
the use of metadata, microservices and standardised APIs (refer to the Open APIs
section above). Whilst technology isolation is important, the greater impact is through
organisational decoupling. This can be particularly important for large siloed
organisations.

For example, it can help to de-couple:

 The products / marketing teams (who generate customer offerings / bundles)

from
 The networks / operations teams (who design, build and maintain the
network).and
 The IT teams (who design, build and maintain the IT stack)
This decoupling is designed with service oriented architectures in mind. It allows product
teams to be highly creative with their CFS (Customer Facing Service) definitions. As the
name suggests, a CFS can be obtained as a product by a customer (or just used by a
CSP’s internal consuming applications like portals). CFS tend to associate general
capabilities / attributes that are meaningful to a customer and span multiple technologies
such as latency, availability / resiliency, loss-rate, etc.
When combined with RFS (Resource Facing Services), CFS are the building blocks used
by operators to design product offerings for customers (and then design the IT systems
that support them).
RFS tend to be more closely related to resource and technology specific attributes /
capabilities. RFS definitions contain details that most customers would find irrelevant
because they’re specific to a CSP or supplier’s technology solution.

CFS and RFS operate at different lifecycles. The network / ops teams tend to create the
RFS definitions and make changes as required by changes within specific technologies /
domains. This allows products / marketing teams to design and modify CFS
independently of technology groups to suit their required customer and product changes.
This (theoretically) allows for greater scope for product innovation by product / marketing
teams.

DATA / INSIGHTS
One of the greatest features of our OSS/BSS tools is that they’re capable of collecting
an astounding amount of data about our networks, services, customers and much more.

But with so much data, the challenge is figuring out what to measure and how to derive
actionable insights. Again the TM Forum has assisted us here. They’ve compiled GB988,
which contains over 2,600 commonly used metrics.
1.4        ITIL and ITSM
ITSM is a structured model for managing and delivering Information Technology (IT)
services to customers, both internal and external to an organisation. As more
organisations become dependent on their IT solutions, the field of IT Service
Management (ITSM) gains further relevance. For many e-businesses or service
providers, the ITSM touch-points ARE the customer’s experience.

Whilst many OSS approach network, services and systems management from a
technology perspective, ITSM is a more process and people-centric approach.

ITIL (Information Technology Infrastructure Library) is rapidly emerging as the leading

framework. The main elements of ITSM are:

 Incident Management
 Problem Management
 Change Management
 Asset Management
 Knowledge, Policy and Procedure
 Service Catalog
 Service Desk
As you’ll have noticed, all of these elements have similar concepts within OSS. The first
three of these ITSM concepts can be related to what a CSP has traditionally known as
Trouble Tickets. Trouble Tickets are a record of information about outages and
degradations in the network / infrastructure, including details of restoration activities.
Incident Management – An incident is an unplanned interruption or degradation to the
network or related infrastructure. To differentiate, some CSPs use an incident to
describe an outage / degradation identified by the customer versus an Event  (an
equipment alarm, event, etc) that has been generated by the network and/or OSS.
Problem Management – A problem is the cause of one or more incidents / events. It
allows aggregation of related incidents / events, and is then used to coordinate further
investigation and remediation effort.
Change Management – A change is the addition, removal or modification of the network,
infrastructure or related knowledge bases. Changes can be Planned (ie routine
maintenance) or Un-planned (ie unexpected impacts).
In addition, ITSM’s Asset Management concept relates to the management of an
organisation’s IT assets. These can be physical, logical, virtual or even information
assets including services as long as they have tangible financial value to an
organisation. There is significant functional overlap between an Asset Management
solution and Inventory Management solutions. However, there are also key differences –
Asset Management is primarily a financial function (ie keeping track of asset value /
depreciation, lifecycle management, warranties, etc); whilst Inventory Management is
primarily an operational function (ie keeping track of resources that are available for use
in the delivery of customer services). Click here for a deeper-dive into the subtle
differences of Inventory (PNI and LNI) Management, Asset Management and Configuration
Management Databases (CMDB).
Just as there has been an increasing overlap between IT (Information Technology) and
telecommunications network technologies, there has also been an increased prevalence
of IT frameworks (such as ITIL) being used in conjunction with telecommunications
frameworks (such as TM Forum’s eTOM). Telecommunications service providers are
reliant on highly reliable IT infrastructure (eg servers, etc) and ITIL is currently seen as
best-practice for the management of these types of assets. Similarly, customers are
outsourcing the management of end-to-end IT and telecommunications infrastructure,
making demands on their service providers to supply high quality service management
of the customer’s increasingly critical network and IT assets.
ITIL (IT Information Library) was developed by the UK Government in an attempt to
standardise IT processes, particularly the handover from implementation to ongoing IT
support environments. ITIL is commonly used within service providers’ back-end
frameworks, but also has relevance when customers stipulate ITIL frameworks as part of
the managed services contracts they let out to service providers.
The short video below provides some additional insights into ITIL. Please note that I
have no affiliations with the producers of this video.

As indicated in the previous section, eTOM was developed by the TMF to guide the
development and management of fundamental business processes within a generic
telecommunications service provider. It shares some commonalities and differences with
ITIL.
This image has been sourced from here
TMF has published an eTOM – ITIL Application Note (GB921L) entitled Using eTOM to
model the ITIL Processes. This application note provides guidance on the modelling of IT
Service Management using the standard process elements within eTOM. It also shows
the detailed overlay of ITIL processes with eTOM Level 2 processes.

The description of the rough ITIL to eTOM mapping above can be found here.

Another great document for plotting a path through the overlapping worlds of ITSM / ITIL
and OSS is a document that has been jointly published by TM Forum and itSMF. It is
known as “TR143. Building Bridges: ITIL and eTOM.”
1.5        3GPP Standards
The advent of 5G cellular technology has introduced a number of key forward-looking
network management concepts. These include network slicing and virtualisation of
cellular infrastructure. As it has done for years,  the 3rd Generation Partnership Project
(3GPP) provides a focal point for standardisation across these cellular and radio
technologies. 3GPP has combined and consolidated the efforts of seven standards
development organisations (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).

In terms of management of cellular / radio networks, there are two main series of
standards published by 3GPP:

 https://www.3gpp.org/DynaReport/32-series.htm  and then

 https://www.3gpp.org/DynaReport/28-series.htm  for OAM&P (Operations,
administration and management) and Charging (which is overflow from the 32
series)
1.6        Standards Compliance

Whilst vendors may claim to be compliant to each of the standards above, most of the
above-mentioned “standards” are simply recommendations that can be adhered to in an
ad-hoc manner by vendors. The one exception is the TM Forum, which provides
thorough testing of a vendor’s product against NGOSS principles. A list of products that
are certified to be compliant with NGOSS can be found on the TM Forum website
(www.tmforum.org).
The TM Forum also offers Frameworx Implementation Conformance Assessment, which
provides verification of a service provider’s internal business processes and data model.
1.7 Registration Authorities

The IEEE acts as the registration authority for many of the unique identifiers used in
telecommunications networks. IEEE maintains a number of different identifiers including
the OIDs used by SNMP. Tutorials for these registers can be found here.
1.8 Emerging Standards

Network virtualisation is having a stunning impact on the networks and systems that
OSS/BSS manage. There are a plethora of other standards / frameworks that are
continuing to evolve that will impact OSS and BSS in varying degrees in the future.
These include:

 ECOMP / ONAP / LF Networking Fund (LFN)

 Software Defined Networking (SDN)
 Network Function Virtualisation (NFV)
 MANO (Management and Orchestration), one of the building blocks of NFV
 Metro Ethernet Forum’s Lifecycle Service Orchestration (MEF LSO)
 The OpenAPI Specification, a broadly adopted industry standard for describing
modern REST APIs
 Network as a Service (NaaS) (including this article that describes why NaaS could
be to networks what Agile has been to software development)
 DevOps
 TOSCA / Yang / Netconf
 Self-organising Networks (SON)
 OpenStack / OpenDaylight
 Continuous Integration / Continuous Improvement (CI/CD) and the many variants
of DevOps
  And many, many more (check out the PAOSS blog to see if your particular item of
interest is covered in more detail)

1.9 Open Source and Programmable Networks

The IT revolutions of virtualisation and open-source software (the other oss) are bringing
benefits to the modern OSS too. We’re seeing far more open source tools appearing in
OSS stacks coming from suppliers like Apache Software Foundation and many others.
These cloud-native, web-scaled frameworks are proving to be adept at handling
streaming data at the volumes that modern OSS cater for. Many of the hundreds of
suppliers on our OSS vendors / suppliers page have open-source components.

1.10 The Business Case for OSS/BSS

It seems that many people treat OSS/BSS as an afterthought. If not as an afterthought,
then invariably still as a cost centre rather than a revenue generator. It’s the network that
seems to get all the attention, in addition to the sales teams that bring in the customers.
They both play an important part, but the following diagram summarises the typically
under-valued role that OSS/BSS play:

For a more detailed breakdown of the claims in this image, click here.

1.11 What’s Next?

Advances in a number of technologies described in chapters 1.8 and 1.9 (eg Cloud,
DevOps, Open Source) are driving a major shift in the OSS / BSS of the future (today
even). We’re seeing a shift to more cloud-native application technology practices. With
5G use-cases often also requiring edge compute, hyperscalers are also taking an
increasing interest in offerings to telco providers. Click on this link to find out more
about OSS / BSS in these cloud-hosted environments.
The move from the 3-tier (thick client, logic, data) monolithic OSS / BSS stack to a more
cloud native / aware, distributed, modular architecture is already well underway. The
benefits of this model, if done right, are numerous – business and workforce agility,
speed to market, immense scalability / elasticity to cope with varying demands, inherent
resilience / responsiveness, speed to innovate / evolve and cost optimisation (capital
efficiency).
OSS / BSS stacks built upon Continuous Delivery, DevOps, microservices,
containerisation, hosted apps / infrastructure and automated orchestration / testing are
supporting this shift. This is the case for organisations with a strong software
development capability. However, there are still many organisations that haven’t made
the shift to having a software-centric workforce.

In either case, organisations are still likely to use off-the-shelf software as key
components of their OSS/BSS stack. That might consist of open-source frameworks /
tools like ONAP, OpenStack and many more. It might consist of commercial-off-the-shelf
(COTS) solutions. Or a combination of both.

We have identified over 400 off-the-shelf OSS/BSS suppliers in The Blue Book OSS/BSS
Suppliers Directory to help you identify the right product mix for your organisation (of
course we’d be delighted to help you find your best-fit too).
Particularly for software-first organisations, OSS/BSS and network service capabilities
and features will be increasingly documented using APIs (increasingly built to OpenAPI
Specification and made easier through the use of tools like Swagger that help design,
build, document and consume REST APIs). These services then become discoverable
and / or registered in application management catalogues.
Modularisation and cataloguing of services should give operators more flexibility and
speed to get new product offerings out to market.  It also provides the ability for
customers to reconfigure their own network services on demand. This is unlike the
OSS / BSS of the past that assumed slow changing or static data / configurations.

Orchestration is a key enabler of on-demand change, allowing automation of the

underlying infrastructure (ie compute, storage and network) and resources as well as the
network services that consume them. Some service changes will be fully automatable
and can be done rapidly in software. Other complex services will still be proceduralised,
but will need human intervention such as changes to physical infrastructure.

The aim for most carriers is to use the ubiquity of physical infrastructure, white-box CPE
(Customer Premises Equipment) and programmable networks to ensure that almost all
changes can be done in software almost instantaneously. And what is it that coordinates
all of that? Oh, that’s right, it’s our OSS/BSS!!

1.12 Additional Information

Is there something else specific that you need to find an answer for?

 The book, “Mastering your OSS” contains a more in-depth history on OSS as well
as hundreds of facts, stories, tips and tricks relating to Operational Support Systems
 A link to The Blue Book OSS/BSS Vendor Directory, a supplier list that has
hundreds of OSS vendors / suppliers
 The Passionate About OSS Podcast, a podcast to shine a light on some of the
amazing minds that contribute to the OSS community – their backgrounds, tips,
tricks and techniques
 The freebies page. which provides
 Additional background research material like terminology, etc
 Templates / tools that we use on the projects we contribute to
  Implementation techniques that we also use on our projects
 A list of hundreds of OSS vendors
 If you’re interested in getting hands-on, check out our evolving Personal OSS/BSS
Sandpit project
 The market research report, “The Changing Landscape of OSS” provides a deep-
dive analysis of the nascent technologies that are impacting, and impacted by, OSS.
The report also provides research into the organisations that are investing in each
of these technologies from an OSS perspective
 The Passionate About OSS blog has thousands of posts, which will hopefully cover
your area of interest
 Use the search bar at the right side of the page
 Looking for some other products, training courses, consultancies, etc
 If you still can’t find what you’re looking for, contact us here because we are
Passionate About OSS and would be delighted to assist you