Choosing the right wireless technology - Part 2
In part one of this series, we explored several considerations for selecting the ideal wireless technology for a design. We reviewed frequency spectrum, licensed and un-licensed spectrum, as well as several common bands. We also discussed communication range and various factors that influence range such as the output power and the sensitivity of the receiver. Part one ended with a discussion about network topology, exploring mesh versus point to multi-point and some of the associated trade-offs like cost, power consumption, and latency. Dan Clement, Senior Principal Solutions Marketing Engineer, ON Semiconductor.
This article will discuss the remaining considerations including coexistence, power consumption, and security. If you are not familiar with the term, coexistence refers to devices needing to coexist and operate together in a common frequency band.
Coexistence
As discussed in the part one article, most wireless solutions are using shared spectrum in unlicensed bands. As a result, frequency bands and channels in those bands are under pressure from various types of radios and signals.
The problem of radios interfering with each other is called coexistence. This topic is explored in depth in the app note, Coexistence in 2.4GHz, so only a brief summary will be provided here.
With its high transmit power and relatively wide bandwidth, 2.4GHz WiFi networks interfere with both Bluetooth Low Energy (Bluetooth LE) connectivity and the Green Power protocol from the Connectivity Standards Alliance (formerly Zigbee Alliance). Bluetooth LE has the ability to frequency hop by detecting and retaining information on busy channels each time and avoiding these channels. This is called adaptive frequency hopping spread spectrum (AFHSS) and greatly improves the reliability of Bluetooth LE in the presence of WiFi and Zigbee packets.
Zigbee technology does not offer this feature, but it can be assigned to a channel that doesn’t overlap with a WiFi channel. Generally, Bluetooth LE and Zigbee networks can coexist together. A WiFi network needs to be actively managed by a coexistence mechanism or the channels between Zigbee and WiFi need to be setup to minimise overlap.
Above: Figure 1. Simplified frequency map
The market trend is to integrate these various radios on chip so that the coexistence is a system design concern, where both hardware and software can be fully optimised to provide the best possible experience using these different technologies side by side. However, software solutions also exist for non-integrated radios.
Without proper coexistence, audio over Bluetooth LE will stutter, retries for Zigbee packets will be required and overall WiFi throughput will be degraded. Successful coexistence will mitigate collisions and prioritise messages from the various protocols to make the overall quality of service good for all protocols. Coexistence is something that is easy to take for granted because, when it’s working properly, it’s unnoticeable.
Above: Figure 2. Simplified time domain view of the frequency map, showing how the Bluetooth LE channels frequency hop as well as skip occupied channels
Power consumption
Power consumption is one of the most important considerations. There are fundamental physics based limitations and trade-offs that dictate the power consumption required for various protocol implementations.
The transmitter, also called the RF power amplifier, is the highest consuming part of the system. RF power amplifiers are described by their class of operation. Classes A, B, AB, and C are considered linear amplifiers, and power efficiency improves with higher amplifier class. For example, a class C amplifier is more efficient than a class AB. Despite improved efficiency, linearity decreases with higher class operation. Classes D, E, F, G, etc. are non-linear amplifiers and are basically switches with resonant loads. If both amplitude and phase modulation are used, a linear PA is required. However, for constant amplitude modulations, a switching amplifier is used to maximize power efficiency since the switching can occur when the current is nearly zero. Because of these different operating modes and numerous considerations, the following example assumes an ideal class A amplifier which has an efficiency of 50%.
For example, a power amplifier transistor delivering +30dBm into a 50Ω load (antenna), at an efficiency of 50%, requires approximately 200mA. This does not take into account any of the remaining system power, just the power needed by the PA transistor (known as drain efficiency). Transmitters also have to switch on and off very quickly and with accurate rise/fall times. As a result, careful power supply design and decoupling is critical, especially in battery-operated systems that have limited energy and less capacity to sustain large switching transients.
Above: Table 1. PA transistor power consumption versus output power, 50Ω load, 50% drain efficiency
Equations:
a) Drain efficiency definition
b) Convert delivered power from dBm to mW
c) Calculate DC power (power supply), using assumed drain efficiency
d) Convert DC power to DC current
As a final note on power efficiency, another metric called Power Added Efficiency (PAE) is often used by RF engineers. This takes the power that is required to drive the PA (PinputmW) intoaccount. The PAs have large transistors, and the pre-drive circuitry can consume a significant amount of power.
Generally, the higher performance the protocol the higher the power consumption. For example, a 4x4 MIMO system requires four parallel receive and transmit chains, which nearly quadruples the power consumption. It is not a one to one relationship as some blocks are shared between the chains, but the power is still higher due to the added signal chains.
The actual airtime and duty cycle are also key considerations if you want to run your system from a battery. For very low duty cycle applications like a Bluetooth LE temperature sensor beacon, it is possible to get to 10+ years on a single CR2032 coin cell battery. Typical active time duty cycles for this type of application are about one percent, meaning the system is idle 99% of the time. This is why the sleep or idle current is a critical parameter when evaluating or designing for battery and battery-free (energy harvesting) operation.
Other power sources are of course mains power or Power over Ethernet (PoE). As an example, WiFi-based IP cameras are typically powered by PoE.
Some engineers are tempted not to care about power consumption when designing products plugged into a nearly infinite source of energy like the mains, but it’s not that simple. Governments are increasingly scrutinising and regulating the power consumption of devices. As more and more products are plugged in, incremental power savings can have a tremendous impact at scale. Power consumption should always be minimised for full economic and social benefit. Another, perhaps less obvious, power consumption consideration is the network topology itself.
Security
Security is not really a consideration but a requirement. Each of the protocols has security built-in at least at a minimum level. The topic of security is difficult, if not impossible, to summarise in a short paragraph in an overview article like this one. With that said, below are several salient points to consider.
The most vulnerable moment for any wireless network is the process of pairing or on-boarding. This is when security information needs to exchange between nodes over the air, and the network is at its most vulnerable. A common solution to this is using an out of band (OOB) protocol. For example, to commission a new WiFi router there may be a QR code that will trigger a pairing process over Bluetooth LE. Bluetooth LE is also a great choice because the range is limited, making physical distance another barrier for hackers. And of course the phone can connect to the cloud, where security information can be retrieved. In some systems, the pairing is done over a proprietary protocol link.
The most basic security, after pairing, is to encrypt the data payloads and this has been done for a very long time. However, now, in some protocols like WiFi, the management frames and protocol overhead must also be encrypted. Even that is not enough, and there has to be dynamic encryption also. Without dynamic encryption, hackers can very efficiently sniff frames and reverse engineer the protocol or act as a middleman and spoof the network. Dynamic encryption has expiring keys over time so, even if a hacker gets in, they can’t go back in time or forward in time without re-hacking. With dynamic encryption, hackers also need to interact with the actual radios, instead of reverse engineering the system offline, which is what they used to do because it’s much faster. Fortunately, this is no longer possible now.
Security schemes must also scale with the risk of what is being protected. Adding security increases cost and maintenance overhead and should be economically matched to the value of the data that is being protected. As an example, Zigbee technology is primarily a root of trust system. When commissioned, the protocol assumes a root of trust between devices. This is a very reasonable assumption because Zigbee networks are not connected to the internet and are local networks, which are under control of a system administrator.
Bluetooth LE is often used for very simple nodes that do not require full security. You may not care if other people can access your living room temperature sensor data, but you may care a lot if someone is able to hack or spoof a cold-chain tag on perishables like important medicine. Because of this, Bluetooth LE offers scalable security features based on different use cases and the value of the data being communicated.
Since WiFi is IP (Internet Protocol) based and connected to the internet, it must have the highest levels of security possible. There are varying levels of security schemes that scale with the risk level of the given application. For example, the requirements for a home network are more relaxed than a network in a bank or office building, where enterprise solutions are required.
As a final thought on security, it is important to note that security design is never completed. Both hackers and security technology play the relentless cat and mouse game and this will never change so important that your design has some mechanism to update software so that the system can be future proofed and kept as secure as possible.
Summary
This two-part series explored various system level considerations and factors that must be understood before designing a wireless product including communication protocol and interoperability requirements, frequency band and co-existence, range, power, network topology, and security.
Each technology has its place in the ecosystem; it is only a matter of knowing what will work best for your design. ON Semiconductor wireless solutions span all use cases from short to medium range to long range and beyond. Whether you are developing a simple temperature Bluetooth LE sensor beacon or enterprise quality WiFi, we can help you solve all of your wireless design challenges.