Netcracker BSS/OSS Data Archive at Telecom Scale

A netcracker bss oss data archive contains the operational data from across the Netcracker BSS/OSS estate that has long-term regulatory, revenue-assurance or operational-forensics value but doesn't belong in the live finance ERP. On the BSS side: subscriber master and history (account lifecycle, plan-change history, consent history, port-in/port-out events), order history (orders, fallouts, provisioning state, workflow audit), billing history beyond the operational ERP window (closed bill cycles, historical invoices, payment history, AR aging snapshots, partner-settlement history). On the OSS side: network inventory snapshots (sites, cells, network elements, IP address pools, VLAN/circuit inventory over time), service activation events (every service activation, deactivation, modification with timestamp and operator), trouble tickets and SLA compliance history, fault history. Plus the cross-cutting feed that's the volume monster — rated and unrated CDR archive at billions per day.

Because the right destination is different. Fusion is your downstream finance ERP — it should hold what finance needs for current-period and recent-period reporting (open AR, current-FY revenue, current-FY partner settlement, customer master, supplier master). What it should not hold: billions of CDRs per day, network-element inventory snapshots, every service activation event from the last 7 years, fault history. That's archive data — high volume, queryable on demand for regulator data calls, revenue-assurance investigations and dispute resolution, but priced and stored differently from production Fusion data. The netcracker bss oss data archive is the right home — columnar Parquet in cloud object storage at 8–12x compression vs Oracle DB, partitioned for query efficiency, accessed via presto/trino without paying Oracle DB rates for analytical workloads.

Multiple overlapping requirements. FCC requires 18+ months retention for CDRs with CALEA-compliant retrievability — law enforcement can subpoena CDRs for criminal investigations and the operator must produce them in a defined format within a defined window. EU ePrivacy Directive can extend that. GDPR overlays right-to-erasure on subscriber personal data. BNetzA, Ofcom, ACMA, IDA, MIIT each have their own retention and submission requirements. SOX requires 7-year retention with auditable trace from GL entry back to original supporting evidence. FCC 800/900 surcharge and USF contributions require audit substantiation. State PUC requirements vary by US state. The netcracker bss oss data archive is designed to satisfy every one of these simultaneously with a single archive layer, scoped read-access logging and configurable retention per data class.

Tier-1 mobile operators generate 2–5 billion CDRs/day (voice, SMS, data, roaming, partner settlement). A 7-year FCC retention window with 5B CDRs/day = ~12 trillion rows. Storing that in Oracle DB is economically untenable. The netcracker bss oss data archive streams rated and unrated CDRs to columnar Parquet in cloud object storage (AWS S3, Azure ADLS, GCP GCS), compressed 8–12x versus Oracle DB row format, partitioned by network element + day + service type for query efficiency. Mediation_record_id and rated_cdr_id are indexed so revenue assurance, CALEA, fraud, dispute and partner-settlement workflows can lookup specific records in milliseconds. Query layer is presto/trino with workload isolation so regulator data calls don't impact operational analytics.

Revenue assurance teams use the archive layer to investigate revenue-leakage patterns — comparing rated CDR volumes from the mediation layer against billed revenue at the bill-cycle level, identifying tariff misapplication, discount misapplication or partner-settlement variance. Dispute resolution teams use it for customer billing disputes — pulling the specific rated CDRs that substantiate a disputed call/SMS/data session, with timestamp, network element, called party and applied tariff. Both workflows run as scoped, audit-logged presto/trino queries against the netcracker bss oss data archive. Read-access is logged with user, query, scope, timestamp and result-size for SOX and regulator audit. Performance is sub-second for indexed lookups and seconds-to-minutes for aggregated investigations.

GDPR right-to-erasure requires the operator to remove a subscriber's personal data on request, while preserving aggregated analytical and statutory-retention data. The netcracker bss oss data archive supports GDPR erasure through tombstoning — the subscriber's personal-identifier fields (name, address, email, phone number, government ID) are nulled and the subscriber record is tombstoned, while aggregated analytical fields (call counts, data usage, revenue contribution) and statutory-retention CDR records (kept for FCC/CALEA mandatory retention, where erasure exemption applies) are preserved. Tombstone events are signed, timestamped and logged in a separate audit table for regulator inspection. The architecture satisfies both GDPR Article 17 erasure rights and FCC/CALEA mandatory retention simultaneously.

OSS data has its own archive pattern. Network inventory (sites, cells, network elements, IP pools, VLAN/circuit inventory) is archived as time-series snapshots — daily or weekly snapshots of the inventory state, indexed by inventory key + snapshot date, so historical state can be reconstructed for any point in time. Service activation events (every activation, deactivation, modification) are archived as an event log with timestamp, operator, before/after state and audit context. Trouble tickets and SLA compliance records are archived with ticket lifecycle (create, update, resolve, close) and SLA-breach flags. All of it is queryable through the same presto/trino layer as the CDR archive, with cross-domain joins (e.g., 'which trouble tickets correlated with which rated CDR anomalies for cell tower X in March') supported natively.

The netcracker bss oss data archive is the long-term operational data home; Fusion is the financial-reporting home. They integrate at three points. (1) Revenue assurance reconciliation: the archive's rated-CDR-aggregated revenue is reconciled per period against Fusion GL revenue postings, with variance reported to revenue assurance teams. (2) Dispute resolution: when a customer dispute hits Fusion AR, the dispute investigation pulls substantiation from the archive (specific rated CDRs, original invoice line, service activation context). (3) Audit trail: SOX audit trail end-to-end runs Fusion GL line → Fusion AR transaction → Netcracker invoice → bill cycle → rated CDR (archive) → mediation record (archive). The archive isn't a parallel system — it's the long-term substantiation layer that makes Fusion's financial reporting defensible.