The CGIN benchmarks test CAPv3 within a VPN (Virtual Private Network) IN application.

About the test scenario

We run two benchmarks.

  • The single-node benchmark runs the VPN application using a single instance of CGIN at 5,000 calls per second.

  • The two-node benchmark runs the VPN application using two instances of CGIN clustered over two servers, at 10,000 calls per second. Each node handles 5,000 calls.

The two-node configuration benchmarks scalability within a cluster. Differences in latency from single-node tests may be due to chatter and shared resources between nodes, which happens with a clustered install even when using high availability.

For each test, we:

  • used a call duration of 60s

  • generated load for two hours, with a ten minute ramp up period at the start

  • observed the CPU utilisation of the VPN application, the call setup latency, and the heap usage.

The VPN Application

The VPN application provides number-translation and call-barring services for groups of subscribers. It supports CAPv3 for call-control and MAPv3 for location information.

If the A party…​ then VPN responds with:

…​has called a B party in their own VPN using short code or public number

Connect with DRA=public B number, and AdCgPN=short code for A

…​and B party are not in the same VPN

Continue instead

…​dials a short code that doesn’t exist

ReleaseCall

Call flow

The VPN application applies incoming call-screening and outgoing call-screening rules, some of which require location information and involve a MAP query of the HLR.

vpn callflow
Previous page Next page