Skip to content

Telecom OSS/BSS — Operations & Business Support Systems Guide

DodaTech Updated 2026-06-24 5 min read

In this tutorial, you'll learn about Telecom OSS/BSS. We cover key concepts, practical examples, and best practices.

Telecom OSS (Operations Support Systems) and BSS (Business Support Systems) are the software platforms that run a telecom network — OSS handles network inventory, provisioning, fault management, and performance monitoring, while BSS manages billing, customer relationship management, order management, and revenue assurance.

What You'll Learn

  • The difference between OSS and BSS domains
  • FCAPS model: Fault, Configuration, Accounting, Performance, Security
  • TM Forum Frameworx and the eTOM (enhanced Telecom Operations Map)
  • Billing mediation, rating, and charging systems

Why OSS/BSS Matters

Without OSS/BSS, network operators cannot provision a new customer, detect a failed base station, generate an invoice, or ensure QoS for enterprise SLAs. OSS/BSS represents 15-20% of a telecom operator's annual IT spend. Modernizing these systems to cloud-native, API-first architectures is a top priority as networks move to 5G and network slicing.

Durga Antivirus Pro applies OSS-like inventory management to track all protected endpoints, using a CMDB (Configuration Management Database) pattern derived from telecom network inventory systems.

Learning Path

flowchart LR
  A[Telecom Fundamentals] --> B[Network Operations]
  B --> C[OSS/BSS Systems
You are here] C --> D[TM Forum Frameworx] C --> E[5G BSS / Converged Charging] style C fill:#f90,color:#fff

OSS vs BSS

flowchart TD
  subgraph OSS[Operations Support Systems]
    NMS[Network Management]
    FCAPS[FCAPS]
    INV[Inventory]
    FULFILL[Fulfillment]
    ASSURANCE[Assurance]
  end
  subgraph BSS[Business Support Systems]
    CRM[Customer Management]
    BILL[Billing]
    CHG[Charging / Rating]
    ORDER[Order Management]
    RM[Revenue Management]
  end
  OSS --> Integration[Integration Layer / ESB]
  BSS --> Integration
  Integration --> NOC[NOC - Network Operations Center]
  Integration --> CSP[CSP Portal / Customer Self-Service]
Domain Systems What They Do
OSS NMS, FCAPS, Inventory, Provisioning Network inventory, activation, fault/performance monitoring
BSS CRM, Billing, Charging, Order Mgmt Customer accounts, pricing, invoicing, order capture

The FCAPS Model

FCAPS is the ISO standard for network management, defined in ISO/IEC 7498-4:

Letter Function Examples
F Fault Management Alarm detection, correlation, ticket creation, escalation
C Configuration Management Device provisioning, software upgrades, backup/restore
A Accounting Management Usage metering, data volume tracking, session records
P Performance Management KPIs: throughput, latency, drop rate, utilization
S Security Management Access control, authentication logs, audit trails
class FCAPS_Manager:
    def __init__(self):
        self.alarms = []
        self.configs = {}

    def fault_alert(self, device_id, severity, message):
        self.alarms.append({"device": device_id, "severity": severity, "msg": message})
        if severity in ("critical", "major"):
            print(f"[NOC ALERT] {device_id}: {severity.upper()} - {message}")
            self.create_ticket(device_id, severity, message)

    def create_ticket(self, device_id, severity, message):
        print(f"[TICKET] TT-{len(self.alarms)} created for {device_id}")
        print(f"[TICKET] Severity: {severity}, Assignee: FieldEngineer-{hash(device_id) % 10}")

fm = FCAPS_Manager()
fm.fault_alert("eNB-421", "critical", "S1 link down - MME unreachable")
fm.fault_alert("eNB-422", "minor", "Sector 3 power amp temperature above threshold")

Expected output:

[NOC ALERT] eNB-421: CRITICAL - S1 link down - MME unreachable
[TICKET] TT-1 created for eNB-421
[TICKET] Severity: critical, Assignee: FieldEngineer-1
[NOC ALERT] eNB-422: MINOR - Sector 3 power amp temperature above threshold
[TICKET] TT-2 created for eNB-422
[TICKET] Severity: minor, Assignee: FieldEngineer-2

eTOM Business Process Framework

The TM Forum's eTOM (enhanced Telecom Operations Map) is the industry-standard business process framework. It organizes processes into three major areas:

Level 0 Processes

Strategy, Infrastructure & Product
  ├── Strategy & Commit
  ├── Infrastructure Lifecycle Management
  └── Product Lifecycle Management

Operations
  ├── Fulfillment
  │     Order -> Provision -> Activate
  ├── Assurance
  │     Monitor -> Detect -> Diagnose -> Resolve
  └── Billing
        Usage -> Mediate -> Rate -> Bill -> Collect

Enterprise Management
  ├── Knowledge & Research
  ├── Financial & Asset Management
  └── Human Resources

Fulfillment Process Flow

flowchart LR
  A[Customer Order] --> B[Order Management]
  B --> C[Service Ordering]
  C --> D[Resource Provisioning]
  D --> E[Activation]
  E --> F[Fulfillment Complete]

Billing Mediation and Charging

Billing mediation converts raw network usage records (CDRs — Call Detail Records) into billable events:

class MediationSystem:
    def __init__(self):
        self.cdrs = []

    def ingest_cdr(self, cdr):
        cdr["mediated"] = False
        self.cdrs.append(cdr)

    def mediate(self):
        for cdr in self.cdrs:
            cdr["start_time"] = cdr["raw_timestamp"]
            cdr["duration_min"] = cdr["raw_duration_sec"] / 60
            cdr["volume_gb"] = cdr.get("raw_bytes", 0) / (1024**3)
            cdr["rate"] = self.apply_rating(cdr)
            cdr["mediated"] = True
            print(f"Mediated CDR: {cdr['subscriber_id']} - {cdr['service_type']} - ${cdr['rate']:.4f}")

    def apply_rating(self, cdr):
        rates = {"voice": 0.01, "data": 0.005, "sms": 0.001}
        base = rates.get(cdr["service_type"], 0.01)
        if cdr["roaming"]:
            base *= 2.5
        if cdr["service_type"] == "data":
            return base * cdr["volume_gb"]
        return base * cdr["duration_min"]

mediator = MediationSystem()
mediator.ingest_cdr({"subscriber_id": "SUB-101", "service_type": "voice",
                      "raw_duration_sec": 300, "roaming": False})
mediator.ingest_cdr({"subscriber_id": "SUB-202", "service_type": "data",
                      "raw_bytes": 500000000, "roaming": True})
mediator.mediate()

Expected output:

Mediated CDR: SUB-101 - voice - $0.0500
Mediated CDR: SUB-202 - data - $0.0063

Common Errors

1. Treating OSS and BSS as Separate Silos

Modern operations require tight integration — a billing issue may originate from a network fault. Converged OSS/BSS platforms reduce operational friction.

2. Ignoring Real-Time Charging

4G/5G requires online charging (OCS) — rating in real-time during a session, not post-paid batch processing. Offline-only BSS cannot support prepaid 5G network slices.

3. Underinvesting in Inventory Management

Many operators do not have an accurate real-time view of their physical and logical network inventory. This causes provisioning failures and slow fault resolution.

Practice Questions

  1. What does FCAPS stand for? Fault, Configuration, Accounting, Performance, Security management.

  2. What is the purpose of billing mediation? Convert raw network CDRs (usage records) into formatted, rated events ready for invoicing.

  3. How does eTOM help telecom operators? Provides a standardized business process framework for aligning OSS/BSS systems, reducing integration costs between vendors.

Challenge: Design a converged charging system that handles prepaid, postpaid, and hybrid billing for a 5G network operator with three network slices. Show the flow from subscriber usage to invoice generation, including real-time credit control for prepaid URLLC slices.

FAQ

What is the difference between OSS and BSS?

OSS manages the network itself (faults, performance, inventory). BSS manages the customer relationship (billing, CRM, orders). OSS keeps the network running; BSS keeps the business running.

What is TM Forum Frameworx?

A suite of best practices and standards including eTOM (process framework), SID (information/data model), and TAM (application map). Used by 850+ operator members.

What is 5G converged charging?

Charging that handles prepaid and postpaid in the same system, supporting real-time credit control, network slice billing, and QoS-based pricing.


Built by the developers of Doda Browser, DodaZIP, and Durga Antivirus Pro. Updated 2026-06-24.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro