OCI for Telecom: BSS, OSS, and Network Analytics

A telecom operator has two technology estates that barely speak to each other. One is the network itself: the radio access layer, the transport backbone, the packet core, increasingly virtualised and increasingly run as software. The other is the business and operations stack that sits behind it, the BSS that bills subscribers and manages their relationship with the operator, and the OSS that provisions, activates, and assures the services the network delivers. The network gets the headlines and the capital budget. The BSS and OSS estate gets the Oracle invoices, because billing, charging, rating, CRM, and order management at carrier scale were built on Oracle Database and, in a very large number of operators, on Oracle applications such as Billing and Revenue Management and Siebel CRM end to end.

That estate is the problem this article addresses. It is too revenue critical to experiment with, too Oracle shaped to move cheaply onto a cloud that treats Oracle as a guest workload, and too expensive on aging on premises hardware to leave alone. Oracle Cloud Infrastructure earns its place on the operator shortlist for the same reason it does in other Oracle heavy industries: it is the one hyperscale cloud where the platforms under the billing core, Exadata above all, exist as native services, and where bring your own license arithmetic works in the operator's favour. This article is part of our OCI by industry series, and it covers the telecom case specifically: why the estate looks the way it does, which OCI services map to BSS, OSS, and analytics workloads, and a numbered path for getting from evaluation to a running estate without putting a billing cycle at risk.

Why operator estates are Oracle heavy

The dependency starts with money. Billing and revenue management is the system that turns network events into invoices, and for a postpaid base of millions of subscribers it processes a volume of usage records that very few database platforms handle comfortably. Oracle Communications Billing and Revenue Management, the former Portal Infranet, runs at a large share of the world's operators, and it runs on Oracle Database. Operators that bill on Amdocs, Netcracker, or CSG products frequently run those on Oracle Database too, because that is what the vendor certified and tuned for two decades. The rating and discounting logic, the general ledger feeds, and the dunning runs all live in the same place, and the bill run is the batch window the whole back office calendar is built around.

The second layer is the customer. Siebel CRM remains stubbornly common in telecom long after the broader market moved on, because the telecom verticals of Siebel encode product catalogues, bundling rules, and order capture flows that operators spent years customising and cannot cheaply rewrite. Around Siebel sits order management, often Oracle Communications Order and Service Management, the product catalogue, and the integration fabric that decomposes a customer order into the technical actions the network must execute. Every one of these systems either is an Oracle product or stands on an Oracle database, and most carry the familiar option footprint: Partitioning for event tables that grow by billions of rows a month, Advanced Compression for usage history, RAC for the systems that cannot stop.

The third layer is convergence pressure. Prepaid charging used to live in network adjacent intelligent network platforms; the industry has spent a decade pulling prepaid and postpaid into converged charging systems that meet the 3GPP converged charging model for 5G. Converged charging tightens the latency requirement dramatically, because an authorisation decision for a prepaid data session is a real time call in the service path, not an overnight batch. Whatever cloud hosts that workload must offer deterministic latency, serious transactional throughput, and a credible answer for the database underneath. That combination is exactly the brief OCI was designed against.

Mapping the BSS to OCI

Billing and revenue management on Exadata

The billing core is the anchor workload, and Exadata Database Service is the anchor answer. A billing database that runs on Exadata on premises moves to Exadata on OCI with the same RAC topology, the same Data Guard standby, and the same storage offload behaviour, because it is the same platform under a cloud operating model. That matters most in the bill run, where rating, invoicing, and general ledger extraction compete for I/O inside a window that ends when the invoices must leave. Operators that have watched a bill run overrun on undersized infrastructure know the cost: late invoices, late revenue, and a finance team asking questions. Smart Scan and the offload of heavy scans to storage are not marketing in this context; they are the difference between a bill cycle that finishes at two in the morning and one that finishes at noon.

Converged charging and the latency budget

Charging is the BSS workload with network grade requirements. An online charging decision sits in the path of a call or a data session, which sets a latency budget measured in tens of milliseconds end to end, including the database round trip. On OCI the design levers are region placement close to the packet core, RAC for continuous availability, and dedicated network paths so charging traffic never queues behind bulk transfers. For operators deploying charging functions as containerised network functions, OKE provides the Kubernetes layer while the subscriber balance store stays on Exadata where its consistency guarantees live. The hybrid pattern, stateless charging logic on Kubernetes with state on Exadata, is the one we see survive contact with production traffic.

CRM, order management, and the long tail

Siebel, order management, mediation, partner settlement, and the surrounding application tier are classic lift candidates. They run on ordinary compute shapes, scale predictably, and benefit immediately from BYOL on Base Database Service or Exadata depending on size. The practical wins are unglamorous: development and test environments provisioned in hours instead of procurement cycles, full sized performance test environments that exist only for the weeks they are needed, and a refresh of aging hardware without a capital case. For an estate where the hardware under Siebel is often a decade old, the migration is less a transformation than an overdue landlord change.

The OSS and the network boundary

Inventory, activation, and assurance

The OSS estate, network inventory, service activation, fault and performance management, has a different risk profile from the BSS. It is less batch shaped and more continuously network facing: an activation platform talks to network elements all day, and an assurance platform ingests alarms and counters without pause. The systems themselves are conventional applications on Oracle or other databases, and they move to OCI the same way the CRM tier does. What changes is the network design around them, because an OSS that loses its path to the network elements is blind, and blind is unacceptable. Activation and assurance platforms therefore deploy across availability domains with interfaces that fail over without operator intervention, and the connectivity design is reviewed with the same seriousness as the platforms themselves.

Connectivity is the design centrepiece

Every telecom conversation about cloud eventually becomes a conversation about the network path. Mediation feeds carrying billions of usage records a day, signalling interfaces from the charging system, element management traffic from the OSS, and replication between regions all need bandwidth that is predictable and latency that is boring. FastConnect provides private connectivity from the operator's own facilities into OCI at port speeds that survive peak ingest, and the design questions, how many circuits, terminating where, with what failover behaviour during a regional event, deserve answers before the first workload moves, not after. Because operators are themselves network engineering organisations, this part of the engagement is usually a fast, productive conversation, and it is the area where our OCI networking practice spends most of its telecom hours: FastConnect topology, transit routing between on premises sites and multiple OCI regions, and the security boundaries between network facing and business facing compartments.

Network analytics at subscriber scale

The third workload family is the one growing fastest. Operators sit on data few industries can match: usage records, network performance counters, location adjacent signalling data, and customer interaction history, generated continuously at petabyte scale. The use cases are well rehearsed, churn prediction, network capacity planning, fraud and revenue assurance, customer experience scoring, and increasingly the training of models that automate network operations. What has held them back is rarely ambition; it is the cost and rigidity of the on premises data platforms asked to carry them.

On OCI the analytics estate splits into a persistent layer and an elastic one. The persistent layer is the data platform itself: Autonomous Data Warehouse or Exadata for the curated, governed data that finance, revenue assurance, and regulatory reporting depend on, with object storage as the cheap landing zone for raw event data. The elastic layer is the compute that does the heavy work, Spark clusters for transformation, GPU shapes for model training, provisioned for the job and released afterwards. The economics follow the same logic as everywhere else in this series: pay continuously only for what must persist, and pay for the peak only during the peak. For an operator whose capacity planning cycle peaks quarterly and whose model retraining is bursty, that distinction is worth real money.

Two telecom specifics deserve emphasis. First, data sovereignty: usage and location adjacent data attracts regulatory attention in most jurisdictions, and several require it to stay in country. OCI's region footprint, and Dedicated Region for operators that must keep everything inside their own facilities, lets the data platform sit where the regulator expects it. Second, revenue assurance is an analytics workload with a direct line to the income statement: reconciling network events against billed events finds the leakage every operator has, and it needs the raw event volume and the billing data in one queryable place. Operators frequently fund the entire analytics platform from the leakage it recovers in its first year.

A seven step path for an operator adopting OCI

Where telecom sits in the wider industry picture

Telecom is one expression of a pattern this series keeps finding: a deep Oracle estate built around a revenue critical batch core, a network facing layer that never sleeps, and an analytics ambition waiting for elastic infrastructure. Utilities are the closest neighbour, with meter data management playing the role of mediation and a regulator watching the critical infrastructure, covered in OCI for utilities. Media and entertainment companies share the content delivery and audience analytics half of the telecom story, and many converged operators run both businesses on one estate, covered in OCI for media. And banking remains the deepest Oracle estate of all, with the general ledger standing where the billing core stands here, covered in OCI for banking. Reading the telecom case alongside those neighbours is the quickest way to separate what is genuinely carrier specific from what is simply what a serious Oracle estate looks like in any sector.

The practical conclusion for an operator is the same one we give every Oracle heavy industry, adjusted for the calendar. OCI does not need to win the network or the IT estate wholesale to be the right destination for the BSS core, and the BSS core is where the licensing money, the migration risk, and the revenue exposure all concentrate. Plan the move around the bill run, the charging latency budget, and the network design, prove the window with a rehearsed full volume cycle, and the analytics estate will follow on economics alone. Across 500+ OCI engagements we have seen estates land at an average 40% reduction in OCI spend after proper shape and license planning, with 24/7/365 monitoring keeping the bill run honest afterwards, and the operators who get there share one habit: they treated the evaluation as an engineering exercise with numbers, not a strategy slide.