What are Operational Support Systems (OSS) and BSS in Telecom?

Table of Contents

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.

Introductory Videos

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 in the Table of Contents to jump to the section most relevant to you.

1. A Brief History of OSS

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

TMN Framework
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 OSS/BSS Functional Blocks

TM Forum’s TAM (The Application Map), which we’ll describe in more detail below, provides a comprehensive analysis of the ~75 main functional building blocks that make up an OSS/BSS.

Each of these components plays a vital role in the comprehensive management of telecommunications services and operations, supporting everything from the initial customer interaction and service orders to the backend management of the network and associated data.

At a higher level, we like to describe the simplified TAM as follows:

The full TAM is represented by the shaded boxes in the background. The simplified TAM is represented by the blue boxes in the foreground. The very high-level workflows of Fulfilment and Assurance are shown in the arrows floating above them.

The short video below was already included in the Introductory Videos section above, but we’ll re-include here for anyone who has jumped directly to this functional building block section.

The following diagram provides a snapshot of the Simplified TAM:

Drawing upon the Simplified TAM, the following breakdown provides a more detailed explanation about these key functional blocks of OSS and BSS:

  1. Lead Generation & Marketing:

    • This block encompasses tools and strategies for attracting potential customers and nurturing leads. It also includes online platforms / portals / forms for lead capture, the design and execution of marketing campaigns, and automated systems to streamline these processes.
  2. Channel & Sales Management:

    • This involves managing the various sales channels, maintaining contact with potential clients, managing sales opportunities, and overall sales channel strategies to maximise market reach and efficiency.
  3. Product Management:

    • Concerns the design, development, lifecycle management, cataloguing, and performance analysis of products. This ensures products meet customer / market needs and are competitively positioned.
  4. Customer Management:

    • Focuses on managing customer information, building and maintaining relationships (via CRM or Customer Relationship Management solutions), and gaining insights into customer behaviour to improve customer service and sales efforts.
  5. Quote Management:

    • Deals with the creation and management of pricing strategies (Price Books), handling customer orders, designing service configurations, managing contracts, and preparing sales quotes and orders.
    • Commonly available CPQ (Configure, Price, Quote) tools primarily reside within this building block but can also cross into functionality offered by Product Management (#3), Customer Management (#4) and Service Management (#7)
    • This is just one example that highlights the interconnected nature of modern OSS/BSS environments, where data and processes must flow seamlessly between different functional blocks
  6. Case & Revenue / Billing Management:

    • Covers the management of customer notifications, service level agreements (SLAs), billing processes, accounts receivable, and collections. This block ensures revenues are accurately captured and maximised.
  7. Service Management:

    • Encompasses the cataloguing of services, managing the inventory of services, processing service orders, provisioning services, and managing changes to services as they evolve.
  8. Service Health:

    • Involves monitoring and managing the performance and quality of services. It also addresses service-related problems to maintain high service standards and customer satisfaction.
  9. Inventory / Resource Management:

    • Deals with the management of the lifecycle of resources, maintaining an inventory of resources, and the management of IP addresses. It’s crucial for optimising the use of resources and planning for capacity needs
    • It facilitates key operational workflows such as design, engineering, network / service optimisation and capacity planning activities
    • This is sometimes broken into active and passive or inside plant and outside plant functional blocks
    • This block can incorporate asset management and spares management as it deals with the lifecycle management of assets / resources. Managing the inventory of physical assets, such as network equipment, hardware, spare parts, as well as pools of associated resources such as IP addresses (IPAM – IP Address Management)
  10. Project Management:

    • Concerns the design, workforce management, and overall management of projects
    • It also includes managing workflows and contractor activities to ensure projects are scheduled efficiently and delivered successfully
    • This may also incorporate contract and contractor management
  11. Network Health Management:

    • Focuses on managing and monitoring the performance of resources, handling faults, managing capacity and usage, and ticket management for issue resolution
    • The ITIL / ITSM tools that are discussed later fall predominantly within this functional block and Service Management (#7)
  12. Partner Management:

    • Involves managing relationships with suppliers, third-party workforce management, handling carrier interconnects and billing, and procurement processes
    • This block also captures the management of network interfaces such as Connectors, Mediation Device Drivers (MDDs), Network Adaptors, etc
  13. Orchestration:

    • Refers to the alignment and coordination of processes and workflows across the OSS/BSS landscape to ensure smooth operations and service delivery
    • The development of orchestration plans often happens in conjunction with Catalogue Management and Partner / Integration Management
    • There are often multiple tiers of orchestration designed into an OSS/BSS stack, from Business to Service to Resource / Network / Domain orchestration. This function block is intended to cover all tiers even though they might be separated in real OSS/BSS architectures
  14. Workflow Engine:

    • This functional block encompasses the management and automation of workflows to improve efficiency and consistency across various processes within the organisation
    • Many of the other building blocks may have in-built workflow capabilities, but this is intended to cover overarching workflow management as most workflows traverse multiple functional blocks
    • This may include Automation capabilities such as RPA (Robotic Process Automation) functionality
  15. Data Management:

    • Covers the management of data resources, including data lakes, the querying of data, etc
    • It also the generation of reports and business intelligence (BI) to inform decision-making
    • In modern OSS/BSS solutions, this includes overarching analytics and data science functions

There are other functional elements that contribute to OSS/BSS solutions but aren’t explicitly shown in the Simplified TAM, including:

Security and Compliance:

  • This includes the management of security policies, access controls, identity management, and compliance with regulatory standards. It could be integrated within various categories like Data Management or Project Management but is not explicitly stated

IT and Cloud Services:

  • With the increasing shift to virtualized services and cloud infrastructure, dedicated management for these aspects might be covered under various sections like Service Management or Data Management, but there’s no distinct category for cloud services management

Interoperability and Integration Layers:

  • The ability for different systems to communicate and work together through middleware and API management is crucial for modern OSS/BSS stacks. This can be included under Orchestration or Partner Management but could be split out separately

 

2. TM Forum  Standards

TM Forum is a global industry association that enables collaboration between service providers, technology suppliers, consultancy companies and systems integrators in the telecommunications sector. 

Through this collaboration and the projects it fosters, TM Forum models have gained widespread use in the field of OSS implementations. It plays a pivotal role in establishing frameworks for digital transformation, agile business operations, solution design and connected digital ecosystems for the telco and OSS industries.

Evolution of telco / OSS business models, the networks under management and sophistication of the services offered across them has led to an increased importance of the collaborations via TM Forum.

Over the years, it has helped introduced many initiatives that have become industry standards. These include Frameworx, Next Generation Operations Systems and Software (NGOSS) and more recently initiatives such as ODA and the Open API framework.

2.1 Frameworx (TAM, eTOM, SID, TNA)

 The main reference models of TM Forum’s Frameworx [note: see here for a clickable model of 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
    TAM Map
    ASIDE: The TAM is a great framework. However, we’ve found that it can be overkill for some smaller telcos, service providers and OSS/BSS suppliers. As a result, we often use The Simplified TAM (as described in the earlier section on OSS/BSS Building blocks). We find it is useful for higher-level 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
    eTOM Level 0 Map
    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:
  • 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)

2.2 Open APIs

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).
GB992_Open_API_Map_R17.0.1

2.3 Open Digital Architecture (ODA)

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.

TM Forum’s Open Digital Architecture (ODA) is a blueprint for modular, cloud-based, open digital platforms that can be orchestrated more efficiently and consistently. It aims to create a living framework for collaboration between companies, moving beyond paperwork and standards to enable practical cooperation

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 (see here for a clickable model provided by TM Forum). 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 (see ODA interactive map here). 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.

2.4 Data, Metrics and 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.

2.5 Transformation Project Framework (TPF)

Whilst the TM Forum has created many useful documents relating to standards and technology. An important initiative that is currently building momentum within the Forum is the creation of a Transformation User Guides (TUG) working group. It’s ambition is to generate practical guide books to assist you to plan, implement and deliver on your next OSS / BSS transformation project. These guides will include templated approaches and practices contributed by industry experts. The first of many documents in this series, which Passionate About OSS significantly contributed to is the over-arching Transformation Project Framework (GB1011). The TPF is a work in progress, but does provide insights into where the TUG initiative is going.

2.6 Digital Maturity Model (DMM)

A key objective of the TPF is to expand upon the TM Forum’s outstanding Digital Maturity Model (DMM) [GB997A] that is used for maturity assessments across people, technology and process elements. The TPF aims to provide actionable, deliverable transformation models once the DMM is used to perform maturity assessments on your current OSS/BSS environment. The diagram below shows a dashboard we’ve built on top of the DMM to assess current state (as-is) and desired future state (to-be).

3. Other Important OSS Standards

There are numerous other standards that are widely used in the telco / OSS/BSS industries. Some of these include

3.1 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 items marked in blue are what we would refer to as the “engine room” of a telecommunications network operations centre (NOC).

Many of the OSS tools that are ITIL-centric in their design are built around this engine room:

  • Change Management – to instantiate changes to networks / services
  • Event Management – to monitor the events being generated
  • Incident Management – to perform any required incident management and then
  • Problem Management – to perform any subsequent problem management (or Post-Incident Reviews – PIRs)
  • Continuous Improvement is the other key element as it represents a continual feedback loop to ensure ever-improving operations.

Of course, the engine room is supported by other key processes including Availability Management, Continuity Management, Configuration Management, Knowledge Management and Service Validation & Testing.

The main elements of ITSM are:

  • Incident Management
  • Problem Management
  • Change Management
  • Event 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.

3.2 Where eTOM and ITIL meet

As indicated in the previous section, eTOM was developed by the TM Forum to guide the development and management of fundamental business processes within a generic telecommunications service provider. It shares some commonalities and differences with ITIL.

It’s common to see ITIL utilised in network operations centres and driving the back-end operational workflows.

Similarly, it’s common to see eTOM utilised for customer-centric workflows, driving front-of-house activities that start and end with customers.

ITIL Framework
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.

Rough ITIL to eTOM mapping
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.”

3.3  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:

3.4 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 (“certification”) of a vendor’s product against its recommendations and principles. A list of products that are certified to be TM Forum compliant 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.

3.4 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.

3.5 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)

3.6 IT, 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. This IT and telco convergence is also seeing a proliferation in standards and approaches used in the field of modern OSS.

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.

4. OSS / BSS Suppliers

 “The Blue Book OSS/BSS Vendor Directory,” is a comprehensive repository that simplifies the process of connecting buyers and sellers in the OSS/BSS industry. With over 500 suppliers listed, this directory serves as a central hub for searching, matching and connecting with vendors providing OSS and BSS solutions, along with related network management tools.

The directory includes company details, product information and functionality classifications to aid in finding the best-fit solution for a network operator’s unique needs. 

5. 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, followed by the sales teams that bring in the customers.

Both certainly play an important part of a network operator’s business and operations model, but the following diagram helps to articulate the true extent of the role that OSS/BSS play:

The Business Case for OSS/BSS

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

If you need to turn the intangibles of OSS into a quantifiable and compelling business case for your next project, leave us a note via the comments form below and we’ll send you a copy of our OSS Business Case Builder.

6. What’s Next for OSS?

Advances in a number of technologies described in previous chapters (eg Cloud, DevOps, Open Source) are driving a major shift in the OSS / BSS of the future (today even). Are you currently re-imagining your OSS? This article describes some of the remarkable approaches that are changing the world of telco. It also seeks your insights into any other disruptors that you’re aware of.

6.1 Digital twins / triplets and reality twins

Digital twins / triplets and reality twins are one of the most important disruptors that will heavily influence the world of telco in conjunction with OSS/BSS in coming years. Augmented Reality / Virtual Reality (AR/VR) will be fundamental to this transformation of our entire digital experiences and ways of working.

6.2 Cloud Native OSS/BSS

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, time-to-value (TTV) improvements, immense scalability / elasticity to cope with varying demands, inherent resilience / responsiveness, speed to innovate / evolve and cost optimisation (capital efficiency).

6.3 Modern Software Development and Deployment Practices

OSS / BSS stacks built upon IT-led concepts such as 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.

6.4 Open Source Frameworks

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 it might comprise a combination of both.

As mentioned, we have identified over 500 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. 

For network operators with in-house development skills, OSS/BSS and network service capabilities / features will be increasingly documented using APIs (increasingly built to OpenAPI Specification and made easier through the consistent and widespread 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.

6.5 Product / Service / Resource Catalogues

Modularisation and cataloguing of products, services and resources 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.

6.6 Orchestration

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.

6.7 Observability Frameworks

Observability frameworks are gaining traction within network operators to enable comprehensive monitoring, analysis and troubleshooting of complex networks. Similar network assurance tools have existed for decades but these modern solutions capture structured and unstructured data from sources beyond just network alarms / events / logs. They also can collect diverse information such as sentiment analysis, weather patterns, test equipment data and much more. Another essential element of these modern frameworks is the ability to provide customised and personalised user interfaces to present the aggregated data in highly flexible ways.

6.8 AIOps

AIOps (Artificial Intelligence for IT Operations) frameworks are continuing to grow in importance, partly because of the increased complexity and scale of modern communications networks and also because of improvements being made in the fields of AI (Artificial Intelligence) and ML (Machine Learning) that can be leveraged against telco data sets. AIOps solutions enhance network management by integrating AI/ML and big data analytics. These frameworks automate network monitoring, preventative maintenance, incident resolution and troubleshooting as well as optimising resource utilisation. These technologies are relatively nascent still but are proving to be successful in automating some steps of incident management, freeing up operator time to focus on incident resolution and fix. 

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!!

We’ve created a comprehensive report that looks at AIOps called “AIOps of the Future: A Definitive Guide” that’s downloadable here. We’ve also prepared the following introductory video:

7. Additional Information

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

  • There are more than 2.500 things on our mind relating to OSS, which you can read more about on The Passionate About OSS Blog
  • But more importantly, we’d love to hear more about What’s on your Mind? via the form below (where you’re welcome to ask us about any still unresolved questions, aspirations, challenges, frustrations, discuss career paths, and more) 
  • 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
  • The book, “Digital Transformation: Simplified” contains over 50 principles that we’ve learnt over the years of building OSS and now apply to OSS transformation projects with our clients
  • 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 top of the page to fast-track any questions or terminologies you might like to seek here on PAOSS
  • The world of OSS can be DBA (Death By Acronym), so you can look here for a list of around 1,000 acronyms that are commonly used in the telco / OSS/BSS industry
  • 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

You managed to make it all the way to the end of this article. Impressive!! Are you doing this research ahead of a new OSS/BSS project?

As you undoubtedly know already, each OSS challenge is unique. They’re all complex, they’re all different. If you’re seeking further assistance, let’s start with a simple three-step plan:

  1. Schedule an Appointment with us
  2. Collaborate and create a customised plan together
  3. Execute the plan together

To discuss ways you can reduce complexity and risk on your next OSS transformation, start with Step 1 and Request an Appointment: