Controlling the amount
of calls passing through your switch is very important feature and in order to
ensure that real amount of calls that have been routed is equal to the expected
one you need to understand the mechanism of controlling CPS rate.
The issue here is hidden in unpredictable spikes of new calls that coming to the switch. These spikes should be handled properly to make sure that the less possible amount of calls is rejected and CPS value is not over exceeded.
During the time frame of 1 minute we received 60 calls. And we are expecting this value matching 1 CPS. However we may receive 50 calls in 5 seconds and 10 calls during next 55.
Should the switch reject 45 out of 50 calls that came in 5 seconds?
In this situation our developers created a mechanism that dynamically control the call rate. It is called token bucket. Bucket is full of tokens and the number of tokens in the bucket depends on CPS value. Bucket is constantly, linearly refilling with new tokens to ensure that it is full. Bucket capacity is equal to CPS value multiplied by call cost in tokens and multiplied by 60 seconds. Bucket cannot hold more tokens than it`s capacity. Each call has it`s own cost in tokens. In order to pass the calls we need to grab the certain amount of tokens out from the bucket. If there is no necessary amount - call will be rejected.
Now, here goes a simple example:
CPS is 1 and the bucket is full.
One call costs 100 tokens.
Bucket filling speed is CPS * Call cost(100 tokens per second).
Bucket size is CPS * Call cost * 60 seconds (6000 tokens)
Now if we would receive 50 calls in 5 seconds all of them will pass through. However only 1500 tokens will stay in the bucket(Decreased on 5000 tokens on calls and increased on 500 tokens on re-filling flow).
If we receive another
portion of 55 calls in next 5 seconds only 20 of them will pass and the rest of
them will be rejected however if the portion will be smaller(10 calls during
next 50 seconds) all of them will pass successfully.