Operations support system

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources: "Operations support system" – news · newspapers · books · scholar · JSTOR (September 2024) (Learn how and when to remove this message)

Operations support systems (OSS), operational support systems in British usage, or Operation System (OpS) in NTT^[1] are computer systems used by telecommunications service providers to manage their networks (e.g., telephone networks). They support management functions such as network inventory, service provisioning, network configuration and fault management.

Network inventory typically includes both physical assets, such as routers, switches, fiber-optic links and base stations, and logical resources such as IP addresses, VLANs and virtual circuits. Maintaining an accurate and up-to-date inventory is considered essential for provisioning new services, troubleshooting network issues, and planning capacity. Industry research highlights that communication service providers are modernizing inventory platforms to support automation, analytics, and integration with OSS/BSS systems.^[2][3][4]

Together with business support systems (BSS), operations support systems support various end-to-end telecommunication services. BSS and OSS have their own data and service responsibilities. The two systems together are often abbreviated OSS/BSS, BSS/OSS or simply B/OSS.

The acronym OSS is also used in a singular form to refer to all the Operations Support Systems viewed as a whole system.

Different subdivisions of OSS have been proposed by the TM Forum, industrial research labs, or OSS vendors. In general, an OSS covers at least the following five functions:

• Network management systems
• Service delivery
• Service fulfillment, including the network inventory, activation and provisioning
• Service assurance
• Customer care

Before about 1970, many OSS activities were performed by manual administrative processes. However, it became obvious that much of this activity could be replaced by computers. In the next 5 years or so, the telephone companies created a number of computer systems (or software applications) which automated much of this activity. This was one of the driving factors for the development of the Unix operating system and the C programming language. The Bell System purchased their own product line of PDP-11 computers from Digital Equipment Corporation for a variety of OSS applications. OSS systems used in the Bell System include AMATPS, CSOBS, EADAS, Remote Memory Administration System (RMAS), Switching Control Center System (SCCS), Service Evaluation System (SES), Trunks Integrated Record Keeping System (TIRKS), and many more. OSS systems from this era are described in the Bell System Technical Journal, Bell Labs Record, and Telcordia Technologies (now part of Ericsson) SR-2275.^[5]

Many OSS systems were initially not linked to each other and often required manual intervention. For example, consider the case where a customer wants to order a new telephone service. The ordering system would take the customer's details and details of their order, but would not be able to configure the telephone exchange directly—this would be done by a switch management system. Details of the new service would need to be transferred from the order handling system to the switch management system—and this would normally be done by a technician re-keying the details from one screen into another—a process often referred to as "swivel chair integration". This was clearly another source of inefficiency, so the focus for the next few years was on creating automated interfaces between the OSS applications—OSS integration. Cheap and simple OSS integration remains a major goal of most telecom companies.

A lot of the work on OSS has been centered on defining its architecture. Put simply, there are four key elements of OSS:

• Processes
  • the sequence of events
• Data
  • the information that is acted upon
• Applications
  • the components that implement processes to manage data
• Technology
  • how we implement the applications

During the 1990s, new OSS architecture definitions were done by the ITU Telecommunication Standardization Sector (ITU-T) in its Telecommunications Management Network (TMN) model. This established a 4-layer model of TMN applicable within an OSS:

• Business Management Level (BML)
• Service Management Level (SML)
• Network Management Level (NML)
• Element Management Level (EML)

A fifth level is mentioned at times being the elements themselves, though the standards speak of only four levels. This was a basis for later work. Network management was further defined by the ISO using the FCAPS model—Fault, Configuration, Accounting, Performance and Security. This basis was adopted by the ITU-T TMN standards as the Functional model for the technology base of the TMN standards M.3000 – M.3599 series. Although the FCAPS model was originally conceived and is applicable for an IT enterprise network, it was adopted for use in the public networks run by telecommunication service providers adhering to ITU-T TMN standards.

A big issue of network and service management is the ability to manage and control the network elements of the access and core networks. Historically, many efforts have been spent in standardization fora (ITU-T, 3GPP) in order to define standard protocol for network management, but with no success and practical results. On the other hand IETF SNMP protocol (Simple Network Management Protocol) has become the de facto standard for internet and telco management, at the EML-NML communication level.

From 2000 and beyond, with the growth of the new broadband and VoIP services, the management of home networks is also entering the scope of OSS and network management. DSL Forum TR-069 specification has defined the CPE WAN Management Protocol (CWMP), suitable for managing home networks devices and terminals at the EML-NML interface.

Modern OSS architectures increasingly combine network inventory with geospatial (GIS) visualization and automation to improve operations and service assurance.^[6][7]

This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (September 2008) (Learn how and when to remove this message)

The TM Forum, formerly the TeleManagement Forum, is an international membership organization of communications service providers and suppliers to the communications industry. While OSS is generally dominated by proprietary and custom technologies, TM Forum promotes standards and frameworks in OSS and BSS.

By 2005, developments in OSS architecture were the results of the TM Forum's New Generation Operations Systems and Software (NGOSS) program, which was established in 2000. This established a set of principles that OSS integration should adopt, along with a set of models that provide standardized approaches. NGOSS was renamed Frameworx.

• An information model (the Shared Information/Data model, or SID) – now more commonly referred to as the Information Framework,
• A process model (the enhanced Telecom Operation Map, or eTOM) – now more commonly known as the Business Process Framework,
• An application model (the Telecom Applications Map) – now known as the Application Framework, an architecture (the Technology Neutral Architecture) and a lifecycle model.

The TM Forum describes Frameworx as an architecture that is:

• "loosely coupled"
• distributed
• component based

The components interact through a common communications vehicle (using an information exchange infrastructure; e.g., EAI, Web Services, EJB). The behavior can be controlled through the use of process management and/or policy management to orchestrate the functionality provided by the services offered by the components.

The early focus of the TM Forum's NGOSS work was on building reference models to support a business stakeholder view on process, information and application interaction. Running in parallel were activities that supported an implementation stakeholder view on interface specifications to provide access to OSS capability (primarily MTNM). The MTNM work evolved into a set of Web Services providing Multi-Technology Operations System Interfaces MTOSI. Most recently,^[when?] the OSS through Java initiative (OSS/J) joined the TMF to provide NGOSS-based BSS/OSS APIs.

Open Digital Architecture (ODA) offers an industry-agreed blueprint, language and set of key design principles to follow. It will provide pragmatic pathways for the journey from maintaining monolithic, legacy software solutions, towards managing nimble, cloud based capabilities that can be orchestrated using AI. It is a reference architecture that maps TM Forum’s Open APIs against technical and business platform functions.^[8]

• Business support system
• COSMOS (telecommunications)
• Loop maintenance operations system
• OA&M
• Service Evaluation System
• Switching Control Center System

• Video: What is OSS/BSS?
• TM Forum
• OSS through Java initiative
• OSS News Review
• OSS Observer landing page of Analysys Mason
• Pipeline Magazine
• InsideTelephony OSS/BSS (2017.05.20 via Wayback Machine)
• Billing & OSS World
• OSS Line
• Telecommunications OSS and BSS
• Telcordia SR-2275