Wireless entertainment may soon lead to an upswing in the telecommunications market. In large part, its commercial success will depend upon the quality and usability of new mobile terminals. To run increasingly sophisticated games and other entertainment applications, mobile terminals must be web-enabled. In addition, they have to support new software environments, interfaces, and multimedia features. Hardware features, including RF power and battery life, also must be optimized. Meanwhile, software and hardware development must face the challenges of evolving standards, complex protocol stacks, embedded applications, and even mobile location technology.
The manufacturers that develop mobile terminals have to ensure that all of these components work together before they take a product to market. They must submit their final designs to rigorous conformance and interoperability testing. Yet they also need to avoid the high cost of last-minute design changes. Manufacturers must therefore recognize the need for early and continuous testing during the product design and integration processes. Thankfully, a new generation of test instruments makes it easier to verify the advanced features, protocol implementations, and integration of software at each stage of the mobile terminal's development.
In first- and second-generation wireless communication systems, only one connection path went from the mobile terminal to the cellular network. That single path handled all calls, including any data application that was carried along with the voice information. Beginning with GPRS, however, a second connection path was added. This path allowed data transfer to and from the Internet. The link to any 2.5G or 3G mobile terminal now carries control and messaging functions for both sets of services.
To support the growing number of data applications together with voice and voice-related services, today's mobile terminals contain numerous components and subsystems. They range from audio components and traditional hardware, such as RF circuitry (combiners, filters, oscillators, mixers, and power amplifiers), to specialized chip sets. Also included are the following: protocol stacks, data-communication software, display drivers, a complex user interface, mechanical packaging, and the battery.
With the introduction of Internet connectivity and packet data transmission, the industry has witnessed a huge increase in the amount of embedded software in mobile terminals. In earlier-generation cellular phones, software consisted mainly of RF signaling protocols. Those protocols were used to control phone operation.
Today, a larger percentage of the embedded code is devoted to the multiple layers of data-communication protocols (FIG. 1). In 2.5G and 3G mobile terminals, an application stack has been added in parallel with existing signaling protocols. The application protocols allow mobile terminals to run embedded software, such as web browsers and Java engines. They also provide modem capability for transmitting and receiving data. Such capability might be needed, for example, between a handset and the Internet in order to download a web page or game.
A growing trend is to design chip sets, protocol stacks, and applications independently of the wireless terminal. Often, this design approach relies on different vendors for each specialized component. Although every component may be individually tested and certified, product developers must ensure that these components provide a desired level of performance when assembled. What happens to the mobile terminal if a short message or a voice call comes in while a user is playing a game? How is the mobile affected if it passes under a bridge while the user is downloading a web page? It is critical to understand and validate the mobile terminal's performance under real-world conditions.
Typically, product developers verify the performance of data-communication software by stressing the device under test. They then measure parameters, such as lost data packets, data throughput, and delays. This technique requires real Internet-protocol (IP) data traffic. In a wireless environment, that traffic is found in a live network. Unfortunately, it's not practical to test a mobile terminal in a commercial operation. The obvious reasons include inconvenience and a lack of environmental control.
Protocol software is more commonly verified using the large, script-based systems that were developed for conformance testing. A test script provides the exact sequence of protocol messages that must be exchanged between a wireless terminal and the network in order to implement a specific feature. Scripts can be written to test any possible scenario. The message exchanges between the wireless terminal and the network are spelled out line by line. The conformance test system steps through the messages sequentially. When an unexpected response occurs, it sends an alert.
Generally, scripted tests are required to demonstrate conformance to a particular standard. Each standard has a specified number of tests that were developed by the relevant governing organization as part of the minimum performance requirements. Product developers can augment that set with additional tests for their particular circumstances.
For ad-hoc testing in a lab, script-based testing—such as testing in a live network—also is less than ideal. The reasons are numerous: Developing a script may take weeks or even months, depending on the complexity of the test-case scenario. Creating the code takes expert resources. Plus, conformance test systems are expensive. In addition, those systems have steep learning curves. Although they can be used to test the air-interface protocols, they don't allow a connection to the Internet at full data rate. Finally, conformance test systems aren't built for an environment in which many engineers need to work in parallel, testing and debugging software as quickly as possible.
For the laboratory, a better solution is the one-box test set with protocol-analysis capability. By emulating a base station, the test set takes the place of a live RF network. It provides a controlled environment in which to test the wireless terminal (FIG. 2). Product developers can monitor the messages transmitted to and from the terminal. They also can modify network parameters, such as RF power, data coding structure, data rate, and the number of time slots. Although a test set doesn't replace conformance testing, this benchtop tool can verify protocol implementations and component integration. More importantly, it provides a reasonable assurance of the terminal's quality and performance before the device is submitted to a conformance test facility or field trial.
TESTING VIA THE STACK In the one-box test set, protocol-analysis capability is based on the wireless protocol stack. In a stack-based test set, state machines implement a subset of the wireless standard to emulate real network functionality. These test sets can provide substantial coverage of a wireless standard for a small dollar investment. Plus, the operation of the test instruments is fairly easy to learn. Product developers can run tests in any order, thereby creating test scenarios on the fly. With stack-based test sets, however, the message coverage and range of testing is limited to the particular features of the installed stack.
With stack-based protocol-analysis capability, it's easier to test the functional aspects of a wireless terminal that aren't covered in the standards. For example, the standards may specify a range of conditions under which the display of a mobile terminal must be usable. But the standards don't tell the product developer how to actually implement such a display. As web browsers, Java engines, and data applications are added to the mobile terminal, the display implementation gets more and more complicated. The test set provides a quick check of the display's performance as it runs each new application under varying conditions.
Similarly, the standards specify the format that is required to send and receive messages using the short message service (SMS) or multimedia message service (MMS). But the standards don't tell the developer how to set up the mobile terminal so that it will deliver the message when it arrives. Once again, the developer must design and test an implementation. In this step, the stack-based test set can help gauge performance.
A DEVELOPER CHECKLIST The possibilities for mobile applications are numerous. So are the opportunities for error. What is the impact of different channel speeds on interactive gaming? Does the interface to an external computer work? How fast can a mobile terminal work under the best conditions? At some point, each of these questions needs to be answered. In the case of web-based applications, the content of the traffic may drive the actions of the device rather than the messages themselves.Finding the source of data-transmission problems in a mobile terminal can be difficult. Such problems may arise from the mobile terminal or from elements of the network, including network components and web servers (FIG. 3). For this reason, the test instrument's ability to emulate the entire network—from the terminal to the Internet—is key.
The test set becomes the transducer between the Internet and the mobile device that's being developed. It should provide controls for varying the data rate, RF level, and interference level. It can then simulate the mobile terminal's environment while on a packet data call. At the minimum, a test set should be able to connect to the Internet through a wireless network, simulate real RF impairments to a data link, and capture all over-the-air messages. It also must be able to probe the protocol layers (FIG. 4).
To verify a mobile terminal's real-world operation, product developers need a way to capture all relevant events. If a transmission problem occurs, they can then sort through the masses of logged data for the source of the error. The combination of network emulation and protocol analysis in a single test set provides a useful solution.
Together, the test set's air interface and protocol stack can create realistic network conditions with data-channel errors. A test scenario might involve the following: the emulation of a live network with interference; changing the signal levels in the base-station transmitter; and setting packet-error and channel data rates. Because the environment within the test set is controlled, problems will be traceable. They can be traced back to the mobile terminal's connection or internal protocol and application implementation.
Today's complex data transactions generate an enormous volume of messages. To handle this volume, the test set's real-time logging capability needs to filter specific message types. It also must be capable of triggering on specific events. Among other useful features are the quick analysis of raw data and the storage of message content for post-capture viewing (FIG. 5). A stack-based test-set architecture makes it possible to probe at any layer of the wireless protocol stack. The designer can then see the peer-to-peer communications taking place between the mobile terminal and the network.
By probing at multiple protocol layers under realistic conditions, product developers can capture the subtle interactions between the layers of the protocol stack. In other words, it's now possible to see more of the communications picture than ever before. This capability provides a highly efficient way to validate or debug a protocol implementation or terminal.
VERIFYING PERFORMANCE When product developers activate the high data rates supported by a 2.5G or 3G standard and run TCP or IP applications over their mobile terminals, it's not uncommon that they discover that the data throughput is far below expectations. The rate of cellular data connectivity is high. But very high latency, delays, and data loss also may be at work. RF propagation conditions, network congestion, and cell loading can all disrupt the flow of data traffic. Understanding the response of the mobile terminal to these factors must be a top priority. Achieving high data throughput is crucial to the success of interactive and web-enabled mobile services.Consider, for example, that data transmission to a mobile terminal is briefly interrupted. This might occur within a vehicle that passes under a bridge or through a short tunnel. In this scenario, the lower (link and physical) layers of the data-communication protocols will eventually catch any missed bits. In the meantime, however, delays and the re-transmission of the bits may wreak havoc on the applications that are running at the higher layers.
In such cases, the test set's ability to examine the multiple protocol layers is especially helpful. The product developer can easily construct a scenario in which the RF connection between the mobile terminal and the "network" (test set) is momentarily disturbed during a data transfer. The test set captures all of the back and forth messages. This information can then be analyzed to determine how each protocol layer performed and whether the device was able to recover gracefully from the interruption (FIG. 6).
Similarly, product developers may try new channel configurations. Their impetus is to take advantage of the multiple downlink channels that are permitted by high-speed data technologies. If the data-transfer speed should slow unexpectedly, the test set can be used to verify the settings of sensitive parameters. Those parameters may need adjusting on the network side.
In conclusion, test sets are becoming more powerful. They're enabling product developers and manufacturers to fully test their applications in a manner that's consistent with actual network operation. Moreover, the combination of network emulation and protocol analysis in a single test set provides significant advantages. It offers flexibility for stressing and evaluating the layered protocol structures. Those structures enable data communication in modern mobile devices.
Connecting the test set to the Internet provides stimulus for browser functions with realistic impairments. Data transmission messages can then be recorded from the air link. By testing at the highest data rates, developers can ensure that power consumption is optimal. They also can feel confident that the mobile terminal will behave well under high-stress conditions.
Mobile terminals are evolving toward platforms that can support more sophisticated applications, such as gaming and multimedia. Accordingly, one can expect to see an even greater reliance on multiple technology vendors. They will supply various specialized components and applications. The challenge for testing will be to deliver accurate, consistent results that can be reproduced cost effectively. Such results also will need to be communicated easily among vendors.
To eliminate differences in interpretation, consistent test methodologies and platforms must emerge. Carefully designed test sets can deliver this promise. They also plan to put a full-featured network on every product developer's bench.
Agilent Technologies395 Page Mill Rd., Palo Alto, CA 94303; (800) 452-4844, www.agilent.com.