Below is an overview of how we test Rhino performance with IN, followed by links to the benchmarks.

About the IN test scenario

To test the IN performance of Rhino we use a Virtual Private Network (VPN) application, which:

  • provides number-translation and call-barring services for groups of subscribers

  • uses the CAPv3 protocol for call-control, and MAPv3 for location information

  • uses Metaswitch’s CGIN APIs and resource adaptor to provide CAP and MAP support.

Metaswitch developed this VPN application to meet genuine business requirements from a Tier-1 network operator, giving us genuine benchmarks — instead of, for example, using a trivial demo application.

This test application performs functions that are common to many real-world IN applications:

  • monitoring the entire call, and reliably maintaining state for the duration of the call

  • interacting with external systems (MSC, HLR, call detail records)

  • supporting a large subscriber database.

The VPN application

The VPN application provides number-translation and call-barring services for groups of subscribers. It uses 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

This benchmark uses only the VPN service’s Connect with DRA call handling path, as described above. Some of the incoming call-screening and outgoing call-screening rules applied by the VPN application require location information and involve a MAP query of the HLR. This results in the application making ATI queries to the HLR for 10% of the dialogs initiated by the MSC.

vpn callflow
Note
Measuring call setup time

  • The switch simulator measures call-setup time from when it sends the InitialDP to the application until it receives the corresponding response.

  • The response time (or "call-setup" time) is the time between sending the InitialDP (1) and receiving the Connect (2), as measured by the switch.

  • The response time includes the time for any MAP query to the HLR that the application may have performed.

Configuration and results

For details, please see:

Previous page Next page