Telecoms Software Development

Engineering teams building telecom BSS (Business Support Systems) and OSS (Operations Support Systems) deal with some of the most demanding data problems in enterprise software: rating billions of usage events correctly, managing network resource inventory without double-allocation, processing CDR streams at high volume while rejecting duplicates, and running billing cycles that must balance to the cent. Scrums.com builds dedicated teams for your telecom software domain: engineers who design rating engines, provisioning workflows, mediation pipelines, and self-service API layers. Every architecture decision is made to serve software companies building connectivity platforms and operators delivering communication services.

BSS Rating Engine and Billing Architecture

Usage events are the raw material of every telecom billing system. A usage_events table stores them append-only: event_id, subscription_id, event_type (VOICE, DATA, SMS), duration or bytes or count, originated timestamp, ingested timestamp, and rated_at. Events are never updated after ingestion. The rating engine applies rate_plans (each plan defines charge type, tier breaks, and price per unit) to produce a charge_amount written back to the event row. Tiered, flat-rate, and per-second billing are all expressed as rate plan configuration, not code changes.

The balance ledger is append-only: every CHARGE, PAYMENT, CREDIT, and ADJUSTMENT writes a new row with account_id, amount, and a reference ID. Current balance is always derived from the ledger sum; never stored as a mutable field. Prepaid accounts trigger suspension when balance falls below threshold; postpaid accounts enforce a credit_limit with a configurable overrun tolerance. Bill runs are periodic jobs that aggregate rated usage into invoice_line_items; the invoice record is immutable once finalised. A dunning workflow drives overdue accounts through reminder / second reminder / suspension / termination, with each step's delay and notification channel configured in a dunning_policy table rather than hardcoded.

Subscription state follows a machine: ACTIVE / SUSPENDED / TERMINATED. Every state transition writes to a subscription_events append-only log with actor, reason, and timestamp. This log is the audit trail for regulatory disputes, customer complaints, and churn analysis, not the status column on the subscription record.

Network Inventory and Service Provisioning Architecture

Network resources (circuits, IP blocks, DIDs, SIMs, CPE devices) are tracked in a network_resources table with status (AVAILABLE, RESERVED, ALLOCATED, DECOMMISSIONED) and an allocated_to_subscription_id foreign key. Allocation uses a two-phase commit pattern: a RESERVE step locks the resource (preventing concurrent assignment) and a CONFIRM step transitions it to ALLOCATED. If the service order fails after reservation, a RELEASE step returns the resource to AVAILABLE. This pattern prevents the double-allocation bug that plagues inventory systems that skip the reservation phase.

Service orders drive the provisioning workflow. A service_orders table holds order type (PROVISION, MODIFY, SUSPEND, TERMINATE), status, and timestamps. Each order type has a defined sequence of service_order_steps: each step targets a provisioning adapter for a specific network vendor (Ericsson, Nokia, Cisco, Juniper). Adapters implement a standard interface; a provisioning_log records every API call with request payload, response, HTTP status, and elapsed time. Failed steps retry according to the step's retry policy; after exhausting retries the order transitions to FAILED and an alert is raised for manual intervention.

Number portability is modelled as a porting_request record: MSISDN, losing carrier, gaining carrier, scheduled port date, and a status state machine. Porting events are append-only. The port completion event triggers a provisioning step that reassigns the DID resource to the gaining subscription and deactivates it on the losing account in the same database transaction.

Telecom BSS and OSS platforms like these are built and delivered by dedicated engineering teams through our mobile app development service.

CDR Mediation, Processing, and Fraud Detection

Call Detail Records (CDRs) from network elements arrive in proprietary formats. A mediation layer normalises them into a standard internal schema before they enter the rating pipeline. Each mediation_job records: source feed, record count, duplicates rejected, parse errors, started at, and completed at. Duplicate detection uses a cdr_hash column: a hash of (subscription_id, event_type, started_at, duration) with a UNIQUE constraint on the rated usage table. Any CDR whose hash already exists is silently discarded; no duplicate charges can enter the billing system regardless of how many times the network element retransmits.

Data usage amounts are stored as DECIMAL(18,4), never FLOAT. Floating-point rounding errors in usage accounting compound into billing disputes at scale. Roaming events require additional enrichment: the visiting network ID is resolved to an inter-operator settlement record, and TAP (Transferred Account Procedure) files are generated for wholesale billing reconciliation with roaming partners.

Fraud detection runs as a near-real-time stream evaluation over rated usage events. Velocity rules are defined in a fraud_rules table: event type, threshold (e.g., more than 100 international calls in 60 minutes on a single subscription), lookback window, and action (ALERT or SUSPEND). When a rule fires, a fraud_alert is written and, if the action is SUSPEND, the subscription state machine transitions automatically. Rules are updateable without a deployment: fraud patterns evolve faster than release cycles, so the rules table is the right place to codify them.

Customer Self-Service API and CRM Integration

The self-service API is the interface between the BSS backend and every customer-facing channel: mobile app, web portal, IVR, and third-party resellers. It exposes endpoints for: account balance and usage summary, invoice history and download, plan enquiry and plan change, add-on purchase, payment method update, and support ticket creation. All write operations (plan change, payment update) require re-authentication with MFA enforced at the API gateway layer (not at the application layer), so the enforcement cannot be bypassed by an application bug.

API rate limiting is applied per customer tier: retail accounts have lower per-minute call limits than enterprise accounts with programmatic integrations. Limits are configured in an api_rate_config table and enforced at the gateway; no rate limiting logic lives in application code. A self_service_audit_log records every write operation: customer ID, endpoint, request parameters (with PII masked), timestamp, and outcome. This log is the evidence trail for disputed account changes.

CRM integration uses event-driven synchronisation. When a subscription state changes, a billing event occurs, or a porting request completes, the event is published to a Kafka topic consumed by the CRM connector. Contact centre agents see the subscription context in a screen-pop without querying the BSS directly. customer_interactions are written back from the CRM as append-only rows: channel, agent ID, outcome, call duration, and notes. These feed the churn prediction model inputs alongside usage trend data from the billing system.

Frequently Asked Questions

What engineering skills are needed to build a telecom BSS or billing platform?

Telecom BSS platforms require backend engineers experienced in high-throughput event processing, append-only ledger patterns, state machine design, and mediation pipeline architecture. Knowledge of telecom domain concepts (CDRs, TAP files, number portability, dunning) reduces ramp time significantly. Scrums.com provides dedicated teams with both the technical depth and the telco domain context to build these systems correctly from the start.

How do you prevent duplicate CDR charges in a rating system?

A cdr_hash column derived from (subscription_id, event_type, started_at, duration) carries a UNIQUE constraint on the rated usage table. Any CDR whose hash already exists is discarded at ingestion. This means the mediation pipeline is idempotent: the same CDR file can be reprocessed after a failure without creating duplicate charges. The mediation job records reject counts so operations teams can see deduplication activity.

How is the billing balance stored to ensure accuracy?

The balance is never stored as a mutable counter. Every charge, payment, credit, and adjustment writes an append-only row to a balance ledger table. Current balance is derived from the sum of that ledger. Historical balance at any point in time can be reconstructed, disputed transactions are resolved by inspecting individual ledger rows, and there is no risk of a race condition overwriting a balance counter.

How does fraud detection work without slowing down the rating pipeline?

Fraud rules are evaluated as a near-real-time stream over rated usage events, running separately from the core rating path. Rules are defined in a fraud_rules table (threshold, lookback window, action) and evaluated by a stream processor. When a rule fires, it writes a fraud alert and optionally triggers a subscription suspension; neither operation blocks the rating pipeline. Rules are updateable without a deployment so the team can respond to new fraud patterns in minutes rather than waiting for a release.

How is number portability handled in the provisioning workflow?

Number portability is modelled as a porting_request record: MSISDN, losing carrier, gaining carrier, scheduled port date, and a status state machine. Porting events are append-only. The port completion event triggers a provisioning step that reassigns the DID resource to the gaining subscription and deactivates it on the losing account in the same database transaction, ensuring the handover is atomic and cannot succeed on the gaining side without deactivating on the losing side.