This test example demonstrates how to use the MCS smart UDP Capacity test to accurately validate that a customer network can maintain call quality for the maximum concurrent VoIP calls required. Unlike data bandwidth test that most suppliers use. Because the exact codec disciplines are used for the test, the quality of the network packets and bandwidth demand are simultaneously measured to ascertain, underwrite and report VoIP service quality and the precise number of calls that can be supported on a shared network.
The MCS test solicits the number of concurrent calls required prior initiation to set the capacity load to meet the minimum requirements to sustain the call volume. The test generates both the packet rate for the bandwidth demand unlike data bandwidth tests. The test automatically can include the required bandwidth headroom to underwrite performance and quality when bandwidth is shared with a host of unknown applications. This allows the definition of VoIP quality to defined to ensure that the test automatically stops when the VoIP quality for packets and delay are breached. To isolate interference from unplanned random traffic activity, this test will also auto reconfirm a breach of quality and continue. On termination, the test reports the exact call volume attained for the codec selected.
The are two key metrics used to accurately measure the number of a calls a certain connection can support. They are...
1. Packet Size (defined by the codec needed to simulate)
2. The accepted bandwidth required to support just one call
Packet Size
The packet size used to run the capacity test, in this example, is 172. This is the packet size used by a G.711 Codec. It's important to use the packet size that is relevant to the codec required. Codec tables can be commonly found online.
One Call Bandwidth
To accurately calculate the number of calls a connection can support it's important to define how much bandwidth one call typically requires. We set this value at 100Kbps per call. So, for a connection to support 10 calls it would need to be capable of sustaining 1Mbps.
Support Calls
This will get a little technical so bear with us!
The number of calls a connection can support is calculated by dividing the minimum packets per second achieved by the test by the result of another calculation. The other calculation converts the packet size, which is in bytes, into bits and then divides it into the one call bandwidth requirement, which for us is 100,00 bits.
Let's break that down a bit....
The packet size of 172 bytes is 1376 bits. The one call bandwidth requirement of 100,000 bits divided by 1376 is 72.67.
As discussed above 10 calls would require a 1,000,000 bits (1 Mbps) capacity. The packets per second rate to achieve this is 125. So, if the test achieved the desired 1,000,000 bit capacity then the packet rate would be 726 packets per second.
726 / 72.67 is 9.99, which is as good as 10 supported calls!
Headroom
By default the test example above will stop once it gets to the required capacity. So, if a user wants to support 10 calls the test will run until it gets to the capacity required to support 10 calls.
What if they can support more than that?
There are two ways to ensure the user can not only support their desired calls but support them comfortably. That's what we call headroom.
The first way is by increasing the one call bandwidth setting. As discussed above this is set to 100Kbps, which is plenty for one call. However, if you up that number to 200Kbps and the test is still successful you'll know they should be okay if the occassionaly have more calls. Note that in this scenario the supported calls will still reports as 10.
The second way is to increase the mulitplier. This is set to 1 in our example. This number, when increased, will allow the test to run past the capacity required to support the users defined calls. When this method is used the supported calls can climb above the users desired number. For example if you set the multiplier to 2 and the user entered 100 calls the result could well be 200 calls. Again, this tells you the call volume can be supported beyond what the user predicts they'll use.
Where these variables are changed are described in the code section.
This tab will highlight certain areas of the code to make implementing and tweaking how it runs easier.
Codec and Supported Calls
The image below highlights the key variables in terms of which codec to simulate and how to assess supported calls. Each one is referenced in detail on the Test Methodology tab.
Codebase
The codebase defines the testing end point. This example is actually hosted on MyConnection Server (MCS), so the codebase definition is blank. If this example was replicated on another web server then the codebase would need to be updated to reflect the MyConnection Server or Satellite to test to. The format for this is domain:port. For example codebase="yourmcs.domain or codebase="yourmcs.domain:81", depending on your port of choice.
The domain also needs to be added to the boot library include statement, shown above. When hosted on MCS /myspeed/boot.lib is sufficient. When hosting away from MCS use the FQDN, for example http://yourmcs.domain/myspeed/boot.lib.
Post Test Results
This example test outputs the results of the test to the page on completion. The image below shows the param tag that deals with this.
As shown above, a JavaScript function is declared (in this example named calcSupCalls) and specific test variables, plus other variables, are passed. The test results follow the format of $TESTNAME.RESULTNAME$. The result variables shown above are all the variables available for the capacity test.