Mobile Device Testing Challenges

One of the many complexities involved in developing today’s mobile devices and chipsets is that the product must cooperate with both cutting-edge and legacy wireless Radio Access Technologies (RATs). This creates a dizzying array of handover scenarios that must be tested before a mobile chipset or device designer can be confident that the finished product will perform well.

The potential problem becomes even more complicated when you consider that in a live network, handovers don’t just occur between RATs; they occur in the presence of any other signal that happens to be live at the time. This means that device designers cannot rely solely on conformance tests to ensure product quality. A conformance test will verify a handover from one RAT to another, but it will not require that this happen in the presence of other signals coming from other cells and connected to other PDNs… signals that will consistently hit the device antenna during live deployment.

A real-life example came to light recently as a chipset developer ran through DVT of a new design. The developers were using benchtop equipment to generate live signals for handover testing, but the equipment only emulated one PDN and a limited number of cells at a time. The engineers used a good bit of ingenuity to ensure that a handover from eHRPD to LTE worked as designed, and all seemed well.

One of our (Spirent’s) engineers showed up to demonstrate a new product for device and chipset developers. Within minutes, the DUT froze, pointing to what seemed to be a test equipment problem.

As it turns out, the problem was that the new test equipment offered a more realistic emulation of the live network: it was emulating multiple RATs from multiple cells and multiple PDNs. The DUT could perform the handover, but not during a 1xRTT voice call. In fact, the mere presence of a 1xRTT signal prevented a successful handover. The design team looked closely and realized they had found a bug that had once been fixed and forgotten, but had somehow crept back into their design.

The developers had not done anything wrong. The bug would certainly have been discovered eventually. At the time, the design team had no reason to believe that testing with multiple disconnected cells, RATs and PDNs was necessary. However, when these extraneous signals were readily available and enabled, the design team found a critical bug that might otherwise have cost days or weeks on their development calendars.

The moral of the story is that the mobile design cycle can be significantly streamlined when the emulated network used in the development lab offers a realistic variety of signal sources (at all layers). While DVT usually involves very specific and simple test scenarios, testing with multiple cells, RATs and PDNs can eliminate issues early in the design cycle, before they impose serious cost and time burdens on the development team.