Service Broker Small Batch Processing for OCS Throughput
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
High volumes of usage requests in telecommunications networks lead to costly network IO operations and transmission latency, limiting the throughput and increasing the Total Cost of Ownership (TCO) of Online Charging Systems (OCS), as individual requests are processed asynchronously and synchronously, resulting in inefficient processing and latency issues.
Innovation Solution
Implementing a system for small batch processing of usage requests, where requests are sorted based on their OCS business logic node destination, enqueued, and sent in batches to reduce network IO operations and context switches, with triggers managing batch size and latency, ensuring compliance with OCS latency requirements.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If individual usage requests are processed separately in a continuous network stream, then each request can be handled immediately with simple processing logic, but network IO operations become costly, context switches increase, and transmission latency limits throughput
Solution Approach 1:
Multiple individual usage requests are merged into a single batch request. The service broker aggregates usage requests from multiple network entities into batches, which are then transmitted to OCS servers as unified units. This combining approach reduces the frequency of network IO operations and context switches, thereby improving throughput while managing latency through controlled batch sizes and timing.
Solution Approach 2:
Usage requests are collected and buffered in queues before being transmitted to OCS servers. The service broker performs preliminary aggregation of requests into batches, preparing them for efficient batch processing. This preliminary action allows the system to accumulate multiple requests and transmit them together, reducing overall network overhead and improving throughput.
2Productivity
If batch processing is implemented to reduce network IO operations and context switches, then processing cost per request decreases and throughput increases, but latency may exceed the 50 ms requirement for 99.9% of requests
Solution Approach 1:
The batch processing parameters are made dynamic and adjustable. The service broker can adapt batch sizes, aggregation timing, and transmission intervals based on current system conditions, traffic patterns, and latency requirements. This dynamic approach allows the system to optimize throughput while ensuring that latency remains within acceptable limits by adjusting batch characteristics in real-time.
Solution Approach 2:
Key parameters such as batch size, aggregation timeout, and transmission interval are configurable and can be changed to balance throughput and latency. By adjusting these parameters, the system can optimize performance for different operational scenarios, ensuring that processing speed requirements are met while still benefiting from batch processing efficiency.
3Reliability
If usage requests are processed asynchronously with multiple OCS entry points and business logic nodes, then system capacity and availability are improved, but processing complexity and coordination overhead increase
Solution Approach 1:
The service broker acts as an intermediary component that manages the complexity of asynchronous batch processing. It handles request aggregation, batch formation, transmission coordination, and response routing between network entities and OCS servers. This intermediary approach maintains system availability through multiple entry points while centralizing the complex coordination logic in the service broker, reducing distributed system complexity.
Data Source
Figure 1
Figure 2A~2B
Figure 3
AI summary
In accordance with various embodiments, systems and methods that provide unified charging across different network interfaces are provided. A system for small batch processing of usage requests, can include a service broker, a plurality of servers wherein each server includes customer data, and a plurality of queues, each associated with a different server. When a usage request is received from a network entity, the service broker is configured to determine an internal ID associated with data requested by the usage request, determine on which particular server of the plurality of servers the data requested by the usage request is stored, enqueue the usage request in a particular queue associated with the particular server, and upon a trigger event, send all requests in the particular queue to the particular server in a batch.