Wireless connectivity protocols for embedded systems
Driven by our insatiable need for information and the desire for finer control over every resource of value, it seems everything is becoming connected, and much of it is being done wirelessly. Fortunately today, adding wireless connectivity has never been easier.
In this article I’ll introduce wireless terminology and basic design considerations, explain popular connectivity options such as Wi-Fi, Bluetooth, ZigBee and others, and examine hardware and software trade-offs, including design strategies, for easily and quickly incorporating wireless connectivity into an embedded design.
Wireless considerations
The first, and sometimes most difficult, decision to make when incorporating wireless is selecting which protocol to use. The protocol selection can have implications of interoperability (or not) with other products, which could even be supplied by a competitor.
On the other hand, a proprietary protocol could restrict access to a product-set under your control if you can forego the wider market for interoperable products. Additionally, some proprietary protocols can provide a solution tuned to specific performance parameters like simplicity, network resiliency or security.
Which frequency bands to use is often determined by market requirements, especially with the larger industry alliances like Wi-Fi. But the choice of frequency bands can be a trade-off with propagation range; wherin doubling the frequency halves the range. It can also be a trade-off with power consumption and over-the-air data rate.
In the U.S., the Federal Communications Commission (FCC) has set aside portions of the RF spectrum as designated Industrial-Scientific-Medical (ISM) bands, which are unlicensed and unrestricted, meaning they are open for anyone to use without requiring a license. However, these frequencies are not unregulated. All products which intentionally radiate in these frequency bands must pass certification testing to demonstrate that emissions are within the limits prescribed by CFR Part 15.
Unlicensed bands vary from country to country, so products designed for worldwide distribution will also have to address the certification requirements imposed by the governments of their ultimate destination. The unlicensed 2.4-GHz band is particularly unique in that it’s an unlicensed band nearly worldwide – the primary reason for its popular use as the frequency band used by Wi-Fi and Bluetooth.
Another important consideration is the topology needed by the network. Star topologies are an aggregation of point-to-point links, with a central master node that manages a fixed number of slave nodes and serves as the conduit for all upstream communication. Master nodes can also link with other master nodes to extend a star network into various configurations, sometimes called tree or cluster-tree networks. Wi-Fi and Bluetooth use the star topology.
One of the drawbacks of a star topology is that if a master node fails, the entire network (or sub-network) fails. Mesh networks provide the most resiliency and flexibility. In a mesh topology, nodes have routing capability so that every node has multiple pathways to every other node, and the network can “self-heal” around failed nodes. The IEEE Std 802.15.4 radio, used by ZigBee and many other sensor networking protocols, uses a mesh topology.
Popular protocols – different networks have different needs
When talking about wireless, the four primary networking protocols are Wi-Fi, Bluetooth, ZigBee and cellular. It’s important to remember that each of these was originally created to meet the needs of varying applications.
Wi-Fi was created to replace the Ethernet cable, so that high data throughput was a priority at the expense of complexity and power consumption. Bluetooth was created to replace the serial cable and includes quality-of-service overhead to carry voice. Requiring much less power than Wi-Fi, Bluetooth has high pairing latency and is limited to a small network of seven slaves. ZigBee was created for large, robust sensor networks with low-cost, low-power nodes, but doesn’t have nearly the throughput of Wi-Fi or Bluetooth.
The legacy of the original design trade-offs for these applications can become the baggage for using them in emerging applications like Home Area Networks (HAN) or Body Area Networks (BAN). One of the advantages of Wi-Fi, for example, is that the application does not need to know that the link is wireless. On the other hand, to build a Wi-Fi-connected smart light bulb means it needs enough processing power to run the TCP/IP stack.
It is also important to remember that while each of these popular protocols might be based on an industry radio standard, the network protocols themselves are not standards – but rather industry alliances. The alliances exist to promote the use of the protocol and guarantee interoperability. To market and sell products that use these protocols requires a membership in the alliance. This also helps to explain why new variants of these protocols seem to be targeting the application space traditionally dominated by others.
The new Wi-Fi Direct protocol, for example, attempts to simplify point-to-point ad-hoc connections between devices for syncing, file transfers, printing, etc. without the need to configure an access point (a function typically done using Bluetooth today). Another new variant of Wi-Fi, called Wi-Fi Display, allows for redirection of video and audio from a small screen (tablet or cell phone) to an HDTV.
In 2010, the Bluetooth SIG released version Bluetooth 4.0 which includes a new variant called Bluetooth Low Energy (now rebranded as Bluetooth Smart). This new version allows much larger networks, dramatically shortens latency, and reduces power consumption to ten percent that of classic Bluetooth, overcoming the previous limitations for using Bluetooth in sensor networks. However these changes came at the expense of backward compatibility – Bluetooth Smart can coexist, but isn’t compatible with classic Bluetooth, and can’t carry voice.
Protocols for sensor networks
Unlike Wi-Fi, which has become universal for wireless data networks, and Bluetooth, which is included in every cell phone shipped today, there is no ubiquitous protocol for wireless sensor networks. ZigBee is the best known, has the largest alliance, and will likely dominate in home and building automation applications. But there are many other protocols competing for sensor networking applications including: WirelessHART; DASH7; 6LoWPAN; and others. There are also dozens, if not hundreds of proprietary protocols like JenNet, DigiMesh, SNAP and Z-Wave.
Generally speaking, all of the suppliers of wireless ICs for sensor networking applications provide ZigBee and other popular stacks at no charge to customers who use their devices. But they also encourage the use of their own proprietary protocols, which are typically much simpler and easier to use, and don’t require membership in an industry alliance.
Whether proprietary or backed by a large industry alliance, every protocol has its strengths. DASH7 is one of the few non-profit alliance-supported protocols that use the 433-MHz ISM band, giving it a range advantage, and its open source protocol stack is small, needing less than 32 kB. The 6LoWPAN protocol adapts IPv6 packets to run on the small frame size of the IEEE Std 802.15.4 radio, giving IP addressing to individual sensors and enabling their visibility on a global scale.
While there is no ubiquitous sensor networking protocol, many of them rely on the IEEE Std 802.15.4 radio. It defines sophisticated MAC+PHY layers that support self-forming networks using mesh, star and cluster-tree topologies, with spread spectrum signaling in both the 2.4 GHz band and several sub-GHz bands. The 2.4-GHz band supports 16 non-overlapping channels, each with up to 250 kbps data rates. The various protocols that use this standardized radio define the upper protocol layers – the network layer up through the application layer, to suit their own specific needs.
ZigBee was the earliest protocol defined to run on the IEEE Std 802.15.4 radio, and has been widely deployed in sense and control applications like home/building automation, advanced metering, and health/fitness monitoring. Today there are two versions – ZigBee and ZigBee PRO, with most new development using ZigBee PRO. New variants of ZigBee include RF4CE – the emerging standard for RF-based remote controls for consumer electronics, ZigBee Green Power – a lightweight stack for energy harvesting nodes, and ZigBee IP – which replaces the network layer with 6LoWPAN for IP connectivity.
The ZigBee Alliance has also developed a variety of ZigBee application profiles (application layer protocols) for specific applications like home automation, lighting and smart energy. These profiles define the device types that participate in the application, their characteristics, and control interfaces simplifying the development of ZigBee-based products and ensuring interoperability at the application level. The ZigBee Smart Energy 2.0 profile, released in draft in July, 2011, is a coordinated effort with the Wi-Fi Alliance, the HomePlug Powerline Alliance, and others to define an IP-based application layer protocol for the smart grid’s Advanced Metering Infrastructure (AMI) and Home Area Networks (HAN).
Design trade-offs
One of the emerging trends in wireless hardware design is the growing abundance of pre-certified, integrated wireless modules. Modules are offered as radio-only modules which interface to existing processors, pre-integrated with onboard processors, or as host-less network processors in which case the protocol stack itself is also embedded in the module.
A serial-to-Wi-Fi module for example, presents the simplest way to integrate Wi-Fi connectivity for machine-to-machine(M2M) applications by using a common UART interface and simplified API that lightens the software effort of integrating the TCP/IP stack. Pre-certified modules can also alleviate the burden of RF design and test, FCC/ETSI/IC certification testing, and provide a significant time-to-market advantage.
Summary
When it’s time to design for the wireless model, the good news is that it’s easier than ever before to add wireless connectivity. Embedded systems developers have a diversity of networking protocols to choose from that are uniquely suited for M2M communications, automation, smart energy, and many other applications. And the growing abundance of pre-certified, integrated wireless modules give the hardware designer a straightforward path to wireless, even with little or no RF design experience.
About the author
Joe Tillison is a technology director at Avnet Electronics Marketing Americas. For the first 13 years of Joe’s career, he designed electronics for spacecraft and launch vehicles at Lockheed Martin Space Systems in Denver. For the last 13 years, Joe has worked in the semiconductor distribution channel, developing tools and technical training that helps design engineers shorten design cycles by using increasingly more complex semiconductor products. Joe has a BSEE from the University of Oklahoma and a MSE from the University of Colorado at Boulder.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
