Introduction
RF testing of wireless communication technologies has always been a complex and nuanced endeavor with many considerations and trade-offs, similar to making the ultimate lemon meringue pie. With the advent of more sophisticated communication protocols (5G and Wi-Fi 6e) and hardware techniques, such as MIMO/beamforming and heterogeneous networks, more advanced RF testing systems have emerged. Of course, this is necessary. We aren’t talking about just cellular for smartphones or Wi-Fi for tablets and TVs anymore. Almost every electronic device will eventually have a radio in it, and more non-electronic systems are being electrified and given sensing and reporting capabilities. Now modern communication devices must struggle alongside a growing number of sibling devices all screaming for attention.
I will be sharing my perspectives on the realities of specifying, designing, developing a modern and robust wireless test environment for both devices and networks. Then I will examine the uncertainties and risks of building test beds with synthetic RF technologies.
Wireless Network Hardware and System Testing: A Hard Road Ahead
Essentially, every wireless network deployed is unique and there isn’t a one-size-fits-all solution when specifying or designing RF hardware to meet the goals for a given wireless network. There is also an exploding diversity of new wireless network applications, as well as new technologies to choose from. Depending where you are in the stack, you are either working on developing hardware/software for a new wireless network device/system, or you are juggling customer requirements alongside code, standards, and regulations trying to build a wireless network. Either way, best practice and often necessity, demands that these devices/systems be tested multiple times through the process, first internally, later by regulatory agencies, and ultimately by the end-user.
The challenge could be as simple as deploying a distributed-antenna-system (DAS) or improving cellular network coverage in a car park with small cells for your region’s largest telco. There are certainly some multipath and fading scenarios to consider when determining the density of cells or radio heads, but probably not as much outside interference to be concerned about. Or the problem could be as complicated as deploying a wireless surveillance and monitoring system for pumpjacks (donkey pumps) to ensure critical oil field operations that keep the black gold flowing. This type of environment is rife with large electrical motors, high powered radios, vast distances, and harsh weather. Questions emerge, such as how do I ensure the necessary throughput for real-time video surveillance while supporting ultra-reliable flow and temperature sensors, or should I sacrifice video quality and enhance coverage with a lower frequency wireless network?
A common challenge everyone is facing when deploying the latest generation of 5G base Open Radio Access Network (O-RAN) base stations is how to keep up with the cadence of new software releases. These releases are coming in nearly monthly now (just like you see with smartphone updates using legacy Radio Access Network (RAN) systems.) With every new update the problem emerges that the current software from a base station provider may not work with the macro or O-RAN base stations from another provider that could be mixed up in your network. This new release will need to be tested before being deployed, and that really should be done in an environment that represents the real network as closely as possible. This requires various scripted verification tests, handover/hand-in/hand-out, and must be certified before it's deployed to the network.
Another common situation is certifying new wireless devices, such as an Industrial Internet of Things (IIoT) device, in a laboratory setting. Say this new IIoT device, which is required to be extremely reliable, needs to operate on a specific frequency of a certain large wireless carrier in your region. There are a vast number of performance parameters that must be met depending on the type of building or facility that is targeted. It is often better to have confidence that a new device will pass certification by performing pre-certification testing in house. But it is far too frequent that testing must also be performed in the field after a device is providing faulty coverage or the desired throughput isn’t achieved.
Defining “Real” and “Synthetic” Test Environments
I am sure some of the scenarios I have just shared illustrate the challenges many test labs are facing, and there are many more. The specific nature of the RF testing environment used during hardware/software development, wireless network development/operations, or certification is crucial in achieving the desired end result of a wireless network that performs as advertised. It seems that the approach for many engineers tasked with setting up the RF test environment (test bench) is to ask the most readily available big-box RF test equipment manufacturer what they should buy. This is somewhat like walking blind into a car dealership and asking, “What should I be driving?” You will likely end up with the fully-loaded 700bhp Dodge Challenger Hellcat even though all you needed the car for was to drive your kid to school.
The fully loaded Hellcat in this analogy represents the complex radio channel emulators, or simulators made by just a few of the larger test and measurement companies. Other than being a large capital expense with possibly more features than you may need, there are other potential considerations when looking at these systems. Many of these off-the-shelf radio channel emulators/simulators present a “synthetic” RF test environment, as opposed to a “real” RF testing environment.
What I mean by a “real” RF test environment is one where a RF system is tested in a way that the transmitted/received signals traveling the system pass through actual RF devices, components, and channels. A “synthetic” RF wireless test environment is where at least some of the signals, system, or channel characteristics are artificially generated or manipulated. For example, a device-under-test (DUT) or system-under-test (SUT) may be exposed to a signal simulated from a field recording of emissions with injected noise and distortion added to the radio response. Though the noise and distortion may resemble somewhat real system noise, this synthetic test doesn’t fully capture all the characteristics of a real RF environment with real radios nor a real RF channel.
I think of this as a similar scenario to how police, firefighters, and soldiers train in practice environments to prepare them for action in the field. In this way, the training can engrain reflexes, help reduce anxiety, and improve unit cohesion. However, I don’t think anything can replace real experience in the field and the instincts and responses developed under live fire scenarios. Also, it goes without saying that a firefighter that has only ever practiced putting out fires in training won’t be as effective as one that has repeatedly faced the inferno, mastered themselves, and did their job. This analogy also hits home, as there are active efforts to equip firefighters, police officers, and even soldiers with more enhanced sensor systems, communications, and video surveillance to help enhance their performance and provide additional security. Ergo, I think that RF testing in a real RF environment is crucial in ironing out all of the wrinkles and leads to an improved method of inherently iterative RF device development cycle.
Challenge the status quo with real RF test environment
In the field, when lives are on the line, who would you give a critical mission to; the green soldier who has never seen battle, or a veteran with a track record of success? I feel confident in my answer to that question. Developing the latest communication technologies requires a real RF test environment to get a full grasp of the system’s performance. Only then would you confidently know if the software/protocol configurations work in the real world. Only then would you be able to discover issues that might not otherwise manifest until units are shipped and customers/installers complain.
If you are curious how to take full advantage of real RF test systems to drive wireless innovation send me an email at commercialwireless@am.spectrumcontrol.com with your questions or thoughts and I will try and answer.
Stay tuned for future articles covering additional discussion of real/synthetic RF test environments, Butler matrices in radio and wireless network testing, multipath emulation, and tacking test challenges for military/defense radio systems.
