Wireless will play an even greater role in future data communications than it does today. For ubiquity of service and ease of connection, wireless is unmatched as an access protocol and seems poised to be the primary means by which people and machines access the Internet and its successors.
Key Insights
- Protocols (such as Wi-Fi and Bluetooth) will be radio applets by about 2020.
- If an application needs more bandwidth, it can ask its radio to find capacity in unused spectrum.
- An important problem is how to ensure radios do not use spectrum inappropriately (such as to interfere with public-safety channels).
Wireless technology is in the midst of an important stage in its technical evolution—commercial transition from radios with behavior fixed in hardware to radios with behavior determined by software. This transition could enable far more flexible radios able to more fully exploit the radio spectrum to deliver data both faster and more reliably.
The research community has envisioned this moment since the early 1990s.10 It is now here.
Unfortunately, computer science, radio engineering, and public-policy advocates are all imperfectly prepared to take advantage. Research on vital questions has been extremely variable, with wonderful work (such as finding the right mix of programmable hardware to support high-performance signal processing in radios) undermined by almost complete neglect (such as how to describe radio behavior independent of platform and how best to share spectrum). The research, funding, and public-policy communities have hard work to do if they are to realize the promise of wireless data communications.
Here, I sketch the technology path wireless data communications is on, as well as the opportunities the future wireless environment will bring, then focus on the critical research questions we need to examine to realize (or rule out) the opportunities and make the policy decisions that will drive our common wireless future.
From Hardware to Software
By about 2020 software radiosa will have become the standard technology for commercial, as well as military, radios, employed in a range of devices, from battery-powered sensors and handheld devices to plugged-in devices (such as base stations). In software radios, all or virtually all functions, from the physical layer of frequencies and coding (such as *PSK and *-QAM) to the media-access layer (such as time-division multiplexing and carrier sense multiple access) are determined and can be changed in real time by software running in the radio.
Software radios are not new, having been around and seen as the future of military radios since the mid-1990s; they are slowly transitioning into the U.S. military today.b What is changing is their cost and packaging are reaching the point where they will also move into non-military markets.6 In the mid-1990s a software radio was the size of a small refrigerator and could easily cost more than $100,000. A software radio today is the size of computer battery and costs as little as $500. Examples include the Wireless Network after Next (WNAN),c Universal Software Radio Peripheral (USRP),d and the somewhat more expensive Microsoft Research Software (Sora) radios.e Radio chipsets with some programmable features cost even less and are incorporated into consumer WiFi products (such as programmable base-station products from Picochip). Following today’s trends, it is reasonable to expect that by 2020 fully programmable radio chipsets will be available at prices consistent with consumer products.
The importance of software radios is that they bring unrivaled flexibility; they are chameleons, running a telephony protocol (such as CDMA) one moment and a data communication protocol (such as WiFi) the next. This flexibility comes from the fact that the radio’s behavior is determined by software. Furthermore, software control changes the pace of innovation. Making a change in the radio’s behavior in the traditional hardware world means waiting six months or more for new hardware. In the world of software, change comes as quickly as a programmer can compile and debug, or overnight.
Living in a World of Software Radios
What is different about a world where software radios are the typical radio? The most obvious is that a consumer no longer buys a wireless protocol when buying a device. The notion that a PDA manufacturer would advertise support for Bluetooth or WiFi makes no sense in a world of software radios, as “Bluetooth” and “WiFi” would be applets any PDA could run. The focus will be on the PDA’s radio processing power, expressed in digital signal processor (DSP) or field programmable gate array (FPGA) capabilities.
Recasting this observation as an illustrative scenario, suppose when people arrive in a foreign country their PDAs would automatically download and start running the right phone and data-communications protocols for that country. If the protocols change overnight, the PDA simply loads (wirelessly) the new versions in the morning. If the people go inside and want to use a local wireless network, the PDA downloads the protocols from the local base station, using, perhaps, WiFi as a legacy protocol to download the new protocols. All these steps happen without requiring any action by the PDA’s user.
Another difference is available bandwidth. If an application needs more wireless bandwidth, it simply asks the radio for more. The software radio would then scan the wireless spectrum looking for unused frequencies and agree with its peer radio (such as the base station) to employ an unused frequency to provide the necessary bandwidth.
In this future world, software radios would offer consumers wireless communication not limited at time of purchase to a particular set of protocols and data-communications bandwidth not limited to a small set of overused frequencies.
They are chameleons, running a telephony protocol (such as CDMA) one moment and a data communication protocol (such as WiFi) the next.
The path to this future requires both technical and regulatory innovation and, as I aim to show here, the two paths are interlinked.
Types of Software Radios
Having sketched the future software radios have to offer, we need to consider how manufacturers will build them. At the moment it appears there will be a range of choices for constructing software radios. It is simplest to view this range from the extreme ends, where radios are near opposites in terms of their trade-offs.
The first type of software radio is a collection of programmable components, mixing FPGAs, DSPs, and possibly an embedded processor. To program it, a software engineer writes or assembles a suite of software for the programmable components.
Observe that the mix of components varies widely. The central issue is how to provide enough processing power, often parallel processing power, to address streams of digital samples at the rates required for the frequency ranges covered by the radio’s antennas.
Designers differ over how to best mix FPGAs, DSPs, and embedded processors to achieve the right processing power. There are also larger system issues; for instance, consider the filters used to select frequencies; better filters yield cleaner signals, which require less processing, but filters are more expensive than DSPs and FPGAs, so some systems choose less-good filters and more processing power. While there is still plenty of room to innovate, particularly in hardware accelerators that coexist comfortably with DSPs and FPGAs, the radio-engineering community understands this design space, as evidenced by a 2010 software radio design4 that cited 43 references.
At the other end of this design space for software radios is a highly configurable chip or chipset. To program the radio, the software engineer would set configuration registers in the chip to determine what frequencies, coding, and media-access protocol features are used.
The conceptual difference between the two ends of the design space is stark. In the programmable radio, software engineers’ ability to implement a new data-communications protocol is limited only by their imaginations and the processing power of the components. In the chipset radio, software engineers are limited to the million or so permutations of frequencies, coding, and media-protocol features the chip supports. So, for instance, it is highly likely that engineers inventing a new form of coding will be able to implement it in the programmable radio and almost certain they cannot implement it in the chipset radio. Because programmable radios offer the widest experimental range, they are the preferred approach in most research efforts, but a chipset radio has important advantages, as discussed here.
Commercial chipset manufacturers appear headed for software radios between the two extremes. The chipsets will run software in DSPs or FPGAs for some functions and configurable (but not programmable) hardware for others. Indeed, some manufacturers in the cellphone industry have already mixed processors with chipsets.f
A natural question when one thinks about building software radios is whether they are “green.” Because software radios use processors, one might assume they are substantially more power hungry than the traditional radios they replace. However, the situation is more nuanced, with much of the energy in a radio dissipated by analog components (such as amplifiers, filters, and antennas); in some radios, they are the primary energy cost. So, while the trade-off between a processor and customized hardware influences energy costs, it is not the only concern and in many radios is not even the primary concern.g
Radio designers should worry about enabling software radios to use techniques to reduce energy consumption by analog components. The essential step toward reducing energy consumption is to turn the radio off when not in use, something easier said than done. The key problem is how a radio knows to turn itself on when another radio wants to send it something. Considerable progress in recent years has taken two complementary paths: First, mechanisms make it possible for radios in a group to know when other radios are awake.3,5,12,16 And second, using a low-power wakeup, or “doorbell,” radio to signal another radio to turn on its higher-power radio to receive a transmission lowers the cost of being awake. Some working radios today use over 99% less energy than a typical WiFi chipset while transmitting the same traffic, and radio designers are beginning to migrate the results into software radios.13
Another green issue concerns disposable radios. With lower energy consumption, we envision radios with such long operating lives it may be simpler to replace than to recharge them. But if such radios are to be ubiquitous, how can we keep them from adding to our trash? One research effort in the Center for Wireless Sensor Networks at Uppsala University seeks to make radios biodegradable.h
Processors vs. chipsets radios. While this article takes the view that there is a substantial difference between a radio built from programmable components and one built on a highly configurable chipset, I would be remiss if I did not mention an alternative perspective.
There is an argument that fully programmable and chipset radios are not very different. The core observation is that RF signaling and propagation is a mature field. Radio engineers know a lot about RF physics. Many of today’s protocols, especially for the physical layer (frequencies and coding), represent sweet spots for high-quality data channels.
From this perspective, it is perfectly reasonable to assume there is a limited set of reasonable choices for radio communications and entirely plausible that a radio engineer could implement all the reasonable permutations in a chipset. If this assumption holds up, then the difference between chipset radios and radios built from programmable components is practically nil.
Unfortunately, this is a paper argument. No one has attempted to build a sufficiently rich chipset radio, so we do not know if it is possible.
Realizing the World of Software Radios
Recall that in the PDA scenario described earlier, the PDA downloads the “right” protocols whenever it needs them, but how exactly would that work? How does the PDA’s radio ensure it does not load rogue software that would interfere with, say, a publicsafety radio channel? This is an essential research problem relating to both how to exploit the spectrum and how to address regulatory concerns.
Describing radio behavior. Given that the central feature of software radios is their ability to change behavior, one might imagine a lot of practical and theoretical work has been done on how to tell a radio how to behave and how a radio can describe its own behavior. However, rather stunningly, little work has targeted this problem.
To appreciate the inadequate state of research, consider how a PDA might learn what software to download; all possible choices are poorly understood.
One scenario is that there’s a standard radio channel (or set of channels) continuously transmitting the right software for a particular region. In a poorly designed world, this channel repeatedly broadcasts the software for each product. So, for consumers who own a Nokia device, their PDA would listen until the Nokia software is transmitted. This solution has one benefit: the local spectrum regulator is able to track what software is being broadcast and ensure only “safe” protocols are distributed. Otherwise, the system wastes valuable spectrum, repeatedly transmitting software for every possible radio, and radios may have to wait a long time before their software is transmitted and available.
A much better version of this scenario, for software engineers and consumers alike, would be if all PDAs used the same software. Imagine something like Java for radio protocols. The software channel described earlier transmits only a handful of protocol implementations running on all devices. The dual challenges are that creating programming languages to program physics is difficult1 and finding a programming abstraction that works equally well for DSPs, FPGAs, configurable chipsets, and any given mix of them is, perhaps, even more difficult.
A variation is the local channel broadcasts specifications of radio protocols. Now imagine a common language describing the physical layer (such as frequencies used, coding, and power rules) and the media-access layer (such as time division vs. code division and packet formats). A radio receiving this specification would convert the specification into a configuration (chipset radios) or compile it into software that drives the radio. Some work has been done in this area,15,17 with one nice concept being that beyond specifying what the radio does, the specification also describes how the radio might scan the spectrum to learn what frequencies are available.
A different approach is that a standards body registers names for each protocol in use, an approach that works best with a small set of protocols and assumes that each radio has the software (or configuration information) for all protocols pre-loaded. It is roughly what the Joint Tactical Radio System (JTRS) uses, but the JTRS team has sought to reduce the list of approved protocols, suggesting the approach is limited.i
Approved use of the spectrum. Software radios have the potential to dramatically change how the radio spectrum is used, unsettling some regulators and spectrum licensors. Regulators worry that a software device will be programmed (intentionally or accidentally) to interfere with existing approved uses of particular frequencies. An oft-cited example is a software radio that decides to use a frequency reserved for emergency services (often idle), interfering with authorized transmissions in an emergency.
Likewise, spectrum licensors with exclusive rights to use particular frequencies, often finding it difficult to fill those frequencies with traffic, worry that software radios will be used to “squat” on their frequencies without paying the incumbent.
On paper, at least, these fears are baseless. There appears to be multiple ways to protect the spectrum from improper or unauthorized use. Unfortunately, but for some small and unpublished experiments, no one has actually confirmed that the paper solutions work in the real world.
All proposed solutions assume some executive component or terminal reconfiguration manager within each radio ensuring the radio obeys the rules. The reconfiguration manager can take many forms. Considering a few representative examples, it is useful to assume that national spectrum authorities and spectrum licensors can digitally sign information using public keys and a radio’s reconfiguration manager can check these signatures.
The simplest solution is to have each radio download a table of acceptable configurations, digitally signed by the spectrum authorities. This approach works particularly well in a chipset with a limited number of configurations. It could also work in a programmable radio; one can imagine a configuration that specifies what versions of various software modules are required and the frequencies that can be used by which software. Open questions include: What specification language should be used for the table?; How big should the table be?; and Will the table have to be broken into chunks by spectrum range, with the radios selectively downloading what they need?
Another solution is to assign every geographic area a wireless network manager that informs the radios within its area of the local operating rules. This approach is being taken by the IEEE 1900.4 and 1900.5 standards efforts, seeking to define a management architecture (1900.4) and policy language through which the network manager tells the terminal reconfiguration manager the operational rules (1900.5). However, unexplained in this approach is what a radio is able to do in the absence of a manager.
Yet another approach is for the various worldwide national spectrum authorities and licensors to digitally sign the software or radio specifications described earlier. The signers would also add attributes designating the frequencies on which the software or specification can be used. In this case, the reconfiguration manager must ensure the software is signed and running on approved frequencies. There’s some worry about how easy it would be for a spectrum authority to verify software, but research2 shows that automated verification of device drivers can be effective, suggesting verification could be an automated task.
A fourth approach is to make the trusted module in the radio into a cognitive reasoner. The radio periodically scans the spectrum for available frequencies. The reasoner then examines a signed set of spectrum rules (composed of spectrum rules from the national spectrum authority and from licensors), creating a protocol able to best use the available spectrum. A slight variation is there’s both a reasoner (not trusted) and a validator (trusted), with the reasoner creating a protocol and the validator confirming the protocol is legal. This approach is ambitious, but two projects11,14 have demonstrated validators, suggesting they might be feasible commercially.
The key problem is how a radio knows to turn itself on when another radio wants to send it something.
These approaches are not exclusive. A central wireless manager could designate some portions of the spectrum available for use by radios capable of cognitive reasoning. A cognitive radio could restrict itself to deciding which of the several signed protocol specifications is appropriate in the current environment. But little research is available to inform us about what combinations of these approaches would make sense.
How much spectrum? One motivation for developing software radios is their presumed ability to use underutilized frequencies (such as the example discussed earlier of moving to an unused frequency to get enough bandwidth). That presumption raises the question of how much of the spectrum is, in fact, unused at any given time in any given place. Unfortunately, we can only partly answer.
A limited 2005 study for the National Science Foundation surveyed the spectrum from 30MHz to 3GHz at six locations (five urban and one rural), finding all the spectrum almost completely unused. In the rural test, occupancy was only 1%, and in the most used location (in New York City), occupancy was only 13%.9
As insightful as it was, the study represents only a starting point. It measured energy in the spectrum, but energy in the spectrum is an imperfect measure. Just because a public-safety frequency is not in use doesn’t mean it’s free for others to use. Similarly, in the newly freed white-space frequencies (formerly used for analog television) in the U.S., new users must take care not to interfere with wireless microphones and other historical users of the spectrum. Furthermore, there are many ways to share spectrum, including underlaying, where a radio transmits using modest power in the same band as a strong signal, as in a TV broadcast, so regular users do not see interference, but collaborating radios distinguish between the different transmissions. Needed are richer measurement studies that test more locations and cover enough detail so software and radio engineers are able to estimate what sharing mechanisms will work well and how much bandwidth a particular radio can access and use; a first example of such a study appeared in 2010.7 More are needed.
Observe an important, though often-ignored, point in the last paragraph. The nature of wireless research is changing. The idea of simply testing how a standardized wireless protocol works under certain conditions (such as urban vs. rural) is rarely useful research. In a world in which radios can change their protocols in seconds, we must discover which protocol should run in those conditions and how a radio might learn about its environment so it can instantiate the protocol.
But even before these more sophisticated measurements are done, it is safe to say the current perceived shortage of wireless bandwidth is, in large part, a function of our inability to exploit a hugely underused spectrum.
Conclusion
Wireless is a vital piece of our data-communications present and will be an even more vital piece of the future, with software in commercial radios able to maximize that future.
Yet, looking over this article, I hope it is clear that we (computer science, radio engineering, manufacturing, and consumer and public-policy advocates) suffer from myopia. For most key topics, including radio behavior, approved use of the spectrum, and even how poorly the spectrum is used today, we have sometimes barely enough information to be excited about it and not enough to make an informed decision about how best to realize it. The point worth repeating is we are ill-prepared to make decisions about future use of wireless data communications.
We must move briskly, however, or risk missing the untapped promise of the wireless spectrum. Research is the way to fill the information gap, but in a world where low-cost software radios are beginning to appear, there’s little time to do the research. Needed instead is an evolving research plan.
It helps to start with what is going right. Radio engineers are well on the way to having wonderful radio platforms on which to run software, with USRP, WNAN, and Sora leading the way.
Regulators are beginning to provide spectrum for experimentation with these radios. Ireland’s spectrum regulator ComReg leads here, having both licensed spectrum for research and publicly declared its willingness in 2006 to make more spectrum available.8
The most pressing need is research into languages to describe radio behavior. Most visibly, software engineers need ways to describe a protocol to heterogeneous radios in the field such that they can immediately run the protocol. It should be possible to write a new protocol and deploy it to radios from multiple manufacturers in minutes (or at most hours, if regulatory approval is needed).
Research is also needed in ways to allow software radios to use the spectrum appropriately. Researchers have several paper solutions but only one implemented approach (incorporated into products from Shared Spectrum http://www.sharedspectrum.com/), but there is only limited experience. Such an important problem needs more attention.
Government research agencies need to fund a few efforts to build a chipset radio. As outlined here, several challenging problems look like they might be easier to solve on a chipset radioif we can only just build one.
There is also a need for researchers to perform richer measurements of the available spectrum to better understand how much of it is used worldwide. Furthermore, we need to understand how much available bandwidth the underused spectrum represents, meaning experiments that do not simply measure energy but that also estimate what protocols would work best in a given location and the data rates they could provide.
If done in the next five years, this research would provide the information we need to make informed choices about how to unlock the wireless spectrum for data communications. We must not delay.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment