Every voice, data, SMS, roaming or IoT event reaches a point where the operator must identify the account and service, select the offer and tariff, reserve or charge the balance, then return the required quota or charging result to the network.
OVOO OCS keeps those decisions in one modular platform across Diameter Ro and Gy, HTTP Nchf event charging, REST and offline CDR processing. It is cloud native, ready for 5G event charging and built around standard Diameter and Nchf interfaces with authenticated REST integration. The platform supports 100M+ users with 99.999% availability and <1s latency.
OVOO OCS is the first OCS with native AI monetization: token based unit reservation. An LLM or agent request reserves tokens before generation, settles the tokens actually consumed and releases the rest. The same engine charges and rates API calls, so network APIs and enterprise APIs are monetized with the same rules as voice and data.
The OCS sits on the live boundary between network usage and the commercial promise made to a subscriber. Three outcomes matter on every path.
01
The network needs a quota or charging result while the service is still active.
Retries, duplicate messages and node changes need an explicit next state, not a second unexplained charge.
Service continuity depends on the charging answer and on what happens when the first answer is interrupted.
02
The selected account, offer, tariff, counter and balance all affect the commercial outcome.
A tariff change during a session must separate usage under the old value from usage under the new value.
The product model keeps commercial rules and balance actions connected to the service event that triggered them.
03
Charging records, metrics, traps, diagnostics and audit history show what the platform decided.
Offline processing and recovery remain visible without taking capacity from the live charging path.
Operations can investigate the decision instead of reconstructing it from disconnected systems.
The interface is the entry point. The commercial answer comes from the connected account, product and balance state.
The Gateway gives network elements a stable entry point and distributes traffic across Core nodes. The Core resolves subscriber and service context, selects the commercial rule, changes balances and returns the charging outcome.
Offline Mediation, scheduling, notifications, provisioning data and operator tooling remain separate services so batch work does not consume the live charging path.
The result is one charging decision model with explicit boundaries for live traffic, offline work, data and operations.
| Path | Network or system context | Supported operation | Charging outcome |
|---|---|---|---|
| Diameter Ro | IMS voice and SMS event charging | Event and session charging | Reserve, charge and settle against the selected account and tariff |
| Diameter Gy | Packet data charging | Reservation, usage and session settlement | Return quota and balance outcome for the active data session |
| HTTP Nchf | 5G SA event charging | Immediate event and reserved event flows using IEC and ECUR | Run HTTP event charging beside existing Diameter paths |
| Authenticated REST | BSS, care and operator integration | Charging evaluation, session termination and provisioning | Expose a controlled integration boundary for connected systems |
| Offline CDR and SQL | Mediation and batch traffic | Convert usage into events, rate and settle | Recover or process usage outside the live request path |
| REST token and API charging | AI gateways, LLM proxies, agent runtimes, API gateways | Token based unit reservation, per call rating, settlement and release of unused units | Reserve tokens or API units before execution, settle what was consumed and return the remainder to the balance |
Tokens are the new minutes and megabytes. OVOO OCS treats an LLM or agent request like any other chargeable session: reserve before use, settle after use, release what was not consumed. API calls follow the same path with per call rating, quotas and balances.
Generative traffic is unpredictable. Output length is unknown when the request starts, streaming responses run for seconds and a single agent step can fan out into many model calls. Post paid metering leaks revenue and prepaid hard stops break the user experience. Reservation solves both.
Same Core, same product model, same duplicate protection and rollback. Tokens are one more unit type next to seconds, bytes and messages.
Rate and charge every API call: network APIs exposed to developers, partner APIs, internal platform APIs. Price per call, per volume, per tier or per outcome, with quotas per API key, application or enterprise account.
Prepaid token wallets, monthly token bundles with overage, per model tariffs, shared team balances, promotional tokens with expiry and reseller margins. Configured in the catalog, not coded in the gateway.
Each AI application provider, MVNO brand or enterprise customer gets a scoped catalog, accounts, balances and access roles. Traffic controls keep one tenant from starving another.
Authenticated REST for reserve, extend, settle and release. Charging records, Prometheus metrics and notifications feed finance, product and operations without a separate metering stack.
Accounts, products, rating rules, balances, sessions and records stay connected to the network event that started the decision.
Charge one unit or configurable chunks during a session or at its end. Set precision and rounding by service, rate usage for the current date or a past date, and support immediate event, reserved event and session charging.
Build ordered conditions and actions from calendars, zones, counters, message fields and custom attributes. Use usage based, fixed cost or free tariffs and split usage correctly when a new tariff becomes effective.
Connect account lifecycle, identifiers, retailers, services, offers, offer groups, rating plans, tariffs and subscriptions. Priorities decide which owned product serves the current event.
Combine a monetary wallet with single service and multiple service bundles. Share balances across parent and child accounts and support top ups, refunds, transfers and one time charges.
Rate multiple services in one request with rollback protection. Resume, settle or terminate incomplete sessions and continue charging context across Core nodes.
Send balance, threshold and rule notifications to external systems. Export custom attributes and structured charging records for operations, business intelligence and finance.
A two node OCS Core configuration processed 100,000 balances simultaneously across four million accounts and balances and 50 million provisioning objects.
Delivered by a two node OCS Core configuration.
When a request repeats, a node disappears or a session never closes, the platform must show the next state and prevent an unexplained second charge.
Replicated or distributed state supports continuation across Core nodes.
Ro, Gy and Nchf paths include duplicate protection, while session processing adds rollback controls.
Interrupted usage can be resumed, settled from offline data or terminated after inactivity.
Horizontal, vertical and sharded scaling combine with weighted Gateway distribution.
Prometheus metrics, SNMP traps, detailed charging records and targeted logging expose platform behaviour.
Scoped access and GUI history cover catalog changes, top ups, refunds, deductions and transfers.
Six network rollout patterns cover MNO, MVNO, MVNE and CSP networks. AI and API charging patterns are described above.
01
OCS Gateway connects GGSN traffic with balance notifications, Offline Mediation file replay and Scheduler handling for expiries.
02
HTTP Nchf event charging runs beside Diameter Gy through HAProxy, with balance notifications, mediation and scheduling.
03
Service Broker and Call Control connect IVR, offline file ingestion and Diameter Ro online charging.
04
CAP versions 1 to 3 connect Service Broker, IVR, file and database offline flows, and session termination.
05
The exposure layer connects an SMSC Gateway through HTTP and SMPP, transaction database replay and Diameter Ro.
06
Recharge and Voucher Management connect SAP integration and notifications to external systems.
Deploy OVOO OCS on OpenStack, VMware, Kubernetes or Docker.
Run OVOO OCS on AWS, Azure or Google Cloud.
Automate delivery with Ansible, Terraform and Helm. Deployment targets include AlmaLinux, Red Hat Enterprise Linux 8 and Ubuntu 22 LTS, with versions validated for each OCS release.
OVOO OCS combines established network interfaces, commercial control, resilience and deployment freedom in one modular platform. See how OVOO OCS gives operators more control over charging, integration and deployment.
| Decision area | Traditional suite OCS | Cloud platform OCS | OVOO OCS advantages |
|---|---|---|---|
| Best fit | Operators standardizing charging inside one broad BSS portfolio | Operators building charging around a cloud platform ecosystem | Fit a focused modular OCS to the live network and surrounding BSS without buying the wider suite |
| Network interfaces | Network and BSS connectivity delivered through the wider suite | HTTP and API connectivity designed around cloud services | Use Diameter Ro and Gy, HTTP Nchf event charging, REST charging and provisioning, plus offline CDR and SQL inputs in one platform |
| Charging modes | Prepaid and postpaid charging connected to the suite catalog and billing model | Usage charging and balance services exposed through cloud APIs | Run immediate event, reserved event and session charging for prepaid and postpaid services |
| Commercial control | Rating and tariff management governed through the suite product model | Offers, usage rules and wallet services configured inside the cloud platform | Control ordered rating rules, calendars, zones, counters and tariff switching during active sessions |
| Balances and bundles | Central balances and bundles managed inside the wider suite | Wallet and entitlement services composed through APIs | Manage monetary balances, refillable bundles, parent and child sharing, top ups, refunds and transfers |
| Service continuity | Redundancy and recovery coordinated across the integrated platform | Service replication and elastic infrastructure in the cloud | Keep charging available through Core node changes with distributed state, duplicate protection, session resumption and offline settlement |
| Deployment model | Private cloud and virtualization aligned with the suite operating model | Cloud infrastructure and containers as the primary operating model | Choose private or public cloud, virtualization or containers, including Kubernetes and Docker |
| AI and API monetization | Not part of the charging model or delivered as a custom extension project | Usage metering settled after the fact, no reservation for in flight generation | The first OCS with native token based unit reservation for LLM and agent traffic, plus API charging and rating in the same Core |
| Operations | Central operations through the wider suite tooling | Cloud metrics, logs and API based operations | Operate with Prometheus metrics, SNMP traps, charging records, diagnostics and GUI audit history |
Bring your interfaces, charging model and deployment target. We will map them to the right OVOO OCS scope.
Compare your OCS optionsThe sequence begins with the services and systems already in the network, then moves through sizing, deployment and a defined pilot.
List voice, data, SMS, roaming and IoT services. Map prepaid, postpaid and hybrid requirements with event, reservation and session charging.
Record every network path, BSS connection, offline source, provisioning operation and operational owner.
Build the target traffic mix, account volume, rating logic and topology, then align the configuration to the expected traffic.
Select one real call flow, the deployment model, continuity controls and the sequence that follows a successful pilot.
OVOO OCS supports voice, LTE data, ADSL and FTTH data across prepaid, postpaid and hybrid account models, with IMS integration.
OVOO OCS controls charging and balances for SMS packages within a virtual PABX service.
OVOO OCS applies reseller recharge limits through the recharge management flow.
The same OCS Core serves an AI startup metering tokens, a virtual operator launching on a host network, a mobile operator charging 5G at national scale and an enterprise monetizing its API portfolio. Pick the package that matches the business, expand the scope later.
AI application providers
Charge LLM, agent and inference traffic in real time with token based unit reservation.
MVNO and MVNE
Full online charging for brands running on a host network, single tenant or multi brand.
Mobile network operators
Carrier grade charging for the whole network, 4G and 5G, at 100M+ subscribers.
Enterprises and API platforms
Rate and charge API calls for network exposure, partner platforms and internal marketplaces.
OVOO OCS rates voice, data and SMS using immediate event, reserved event and session charging. It also supports roaming and IoT use cases, prepaid and postpaid accounts, monetary balances and single service or multiple service bundles.
Diameter Ro supports IMS voice and event charging, while Diameter Gy supports packet data charging. HTTP Nchf supports immediate event and reserved event charging using IEC and ECUR. REST charging and provisioning interfaces plus offline CDR and SQL inputs are also available.
Yes. Diameter Ro and Gy run alongside HTTP Nchf immediate event and reserved event charging, REST and offline inputs. Operators can introduce 5G event charging while existing Diameter services remain active.
A two node OCS Core configuration processed 3,000 charging messages per second across four million accounts and balances, 50 million provisioning objects and 100,000 balances charged simultaneously. Average processing time was 11 ms and p99 was 45 ms.
Session controls support duplicate protection, rollback and continuation across Core nodes. Incomplete sessions can be resumed, settled from offline data or terminated when inactivity rules apply.
Providers and retailers can have scoped catalogs, charging rules, accounts, data and access roles. Traffic controls and administration for each retailer remain inside that tenant boundary.
Deploy OVOO OCS in private cloud, public cloud, containers or virtualized infrastructure. Supported environments include OpenStack, VMware, Kubernetes, Docker, AWS, Azure and Google Cloud. Ansible, Terraform and Helm automate delivery.
The engagement confirms services and charging modes, maps interfaces and connected systems, sizes traffic and subscribers, selects the deployment model, then defines the pilot and rollout.
Prepaid, postpaid and hybrid services use one connected product model for accounts, offers, rating plans, tariffs, balances and bundles. Configure the charging rules for each service and account model in the selected rollout.
Yes. Tariff values can be scheduled in advance, and the charging logic can split an active session at the effective time so usage before and after the change is rated with the appropriate value.
REST interfaces support charging evaluation, session termination and provisioning, while offline CDR and SQL inputs cover mediated usage. The interface map defines the operations available to each connected system.
Operations teams can use configurable charging records, Prometheus charging and JVM metrics, SNMP traps, targeted diagnostics and GUI audit history.
The AI gateway reserves a token quota before the model runs. Long generations or agent loops extend the reservation mid session. When the response completes, input, output and cached tokens are rated and charged, and any unused reservation is released back to the balance. OVOO OCS is the first OCS with native support for this reservation model for AI traffic.
Yes. API calls are rated per call, per volume, per tier or per outcome with quotas per API key, application or account. The same balances, bundles, notifications and charging records apply to API traffic, network traffic and AI tokens.
