日本語
Spirent recently launched a new OCTOBOX personal wireless testbed feature called Deep Performance Metrics (DPM). In this blog post, I am going to take a closer look into this feature and how it can help in Wi-Fi testing.
In short, DPM makes certain types of Wi-Fi testing and troubleshooting scenarios a lot easier and faster to perform. It does this by making more information about the results available. With DPM, the OCTOBOX testbed can report on layer 1 and layer 2 metrics, things like Modulation Coding Scheme (MCS), number of streams, bandwidth, physical rate (PHY), and received signal strength (RSSI). This information is now available for any off-the-shelf devices that you might want to test against each other, including devices that don’t have any kind of monitoring interfaces or APIs.
Sounds like an impossible thing to do, you might say? Difficult, but definitely not impossible!
Why low layer statistics are useful
Layer 1 and layer 2 statistics are very useful to have available when you need to start troubleshooting an anomaly that you find in a testing scenario. Say you are measuring the throughput of a device and you see a result that you are not expecting. In the image on the upper left, I am showing an example from a simple handover test. There is an unexpected dip in throughput around the 90-140 second region. This would normally be a relatively complicated issue to analyze but having layer 1 / 2 statistics help to analyze the behavior quickly. In the other images, we see that the RSSI is very high during that time (-15 to -20 dBm) and that the MCS rate has taken a dip during the same period. This combination of metrics is indicative of signal saturation and not a cause for concern, since the signal level was higher than what would be seen in the real world.
As we can see from the example, layer 1 and 2 statistics can be used to pinpoint the nature of the anomaly and its place in the timeline. This acts as a first pass troubleshooting step and may typically be all you need to direct development teams to focus on the right issues. Sometimes you may need to dig a little deeper, perhaps by investigating the exchange with Wireshark.
Spirent has had some support for layer 1 and 2 statistics already. Embedding a Pal test instrument as an active device into a test scenario enables the OCTOBOX to report on them. This access to lower layer statistics is due to the deep software integration with the silicon running in these Pal test instruments. The low layer statistics are picked up by the OCTOBOX system and reported as part of the test results.
But there’s a gap
Until today, there has been a limitation with this approach. It would only work for scenarios where the Pal instrument is used as an access point or as a station. However, you might be interested in investigating how an iPhone works with your mesh as it moves across it, or perhaps how your IoT device operates with a widely deployed access point.
How we make magic happen
DPM solves this problem by using Pal test instruments in a new way. With DPM, the Pal monitors a test scenario passively and captures all packets as they are sent over the air. The OCTOBOX system then parses those packets in real time and generates the important layer 1 / 2 key metrics out of these packets. The metrics are delivered using the same familiar user and reporting interfaces that are already built into the testbed and all this is done seamlessly in the background. Thus, users can look deeper into any issues that may arise to help solve root causes more quickly and efficiently.
For more information on DPM, view the Pal Datasheet.
