IEEE 802.15.4 is a wireless communications protocol that runs at the seemingly unimpressive maximum speed of 250 kb/sec. That's bits, not bytes. Most people that have heard of wireless communications usually think of IEEE 802.11 or Bluetooth , since those are the most mass-market consumer protocols available. So why in the world would we need another wireless protocol that runs at a turtle's pace?
The reasons behind 802.15.4 lie in its application domain: short range wireless networking. One of the biggest obstacles to using wireless devices is power consumption, since there is usually no power cable available to a mobile wireless device. 802.11 was designed for large data transfers with a tethered device like a wireless router spewing out gobs of RF power. On the receiving end, the laptops with Wi-Fi connections usually have a large (ie: big-ass by consumer mobile standards) battery that can run an 802.11 transceiver for hours at a time.
Bluetooth was also not developed to be a power conserving protocol. The main focus is on multi-media communications and you can see that the largest market for Bluetooth is in those annoying little ear-pieces people wear when they look like they're talking to themselves. There is currently a movement for a modified Bluetooth protocol that is more power-aware and less of a drain on a battery and it will be interesting to see how that progresses.
The reason I mentioned 802.11 and Bluetooth is because it serves as an interesting contrast to 802.15.4. In December of 2000, the IEEE-SA officially sanctioned the creation of a new project to develop a low-rate wireless protocol that eventually became the IEEE 802.15.4 TG. The focus of the protocol was for applications that had relaxed throughput requirements but needed low-power and low-cost.
The low power goal was to achieve at least 2 years of activity per node on a single coin cell. That goal can be reached depending on the duty cycle of the node. The duty cycle is the ratio of time the node is active compared with the time that it is sleeping. So if a node only transmits data once per hour and sleeps the rest of the time, then the duty cycle is very low and it can achieve a long battery life. However it wouldn't be very useful except in data logging applications with slowly changing data (ie: weather).
The cost issue is still being worked out. From my experience, Bluetooth transceivers are still slightly cheaper than the 802.15.4 transceivers due to the large volumes that go into cell phone applications. However now that there is a fairly large uptake of 802.15.4 for a large variety of protocols, it looks like the cost of the transceivers is shrinking.
802.15.4 in the Context of Zigbee
But anyways, you didn't want to hear a bunch of marketing mumbo-jumbo from me, did you? The main purpose of this article is to discuss 802.15.4 in the context of Zigbee. What does this mean, you say? 802.15.4 is a large protocol and is somewhat complex, especially when you start getting into the different beacon modes and synchronization features. However if you're only interested in 802.15.4 from the point of view of Zigbee, then things become much easier. You just need to understand some of the basic PHY aspects and a small subset of the MAC layer.
It's probably best to start off with an explanation of the physical (PHY) layer of the 802.15.4 protocol. To understand the PHY, it will probably require some terminology that may be unfamiliar unless you've studied digital communications or your hobby happens to be HAM radio operation.
The 802.15.4 spec defines three frequency ranges that it's allowed to play in:
- 868 MHz
- 915 MHz
- 2400 MHz (2.4 GHz)
Of those frequency ranges, the 2.4 GHz is the most common frequency range because it's a worldwide standard frequency for industrial, scientific, and medical equipment. In other words, it's open and doesn't require a license to use. 868 MHz is an open band in most of the EU and 915 MHz is an open band in North America and some Asian countries. Zigbee is only defined for the 2.4 GHz bands so you technically don't need to understand the 868/915 MHz bands, however radios are starting to come out that address these lower bands. Since there is almost no software change to use these lower bands, and you get added benefits, I though it would be worthwhile to add them into this discussion.
One of the main differences between the 802.15.4-2003 spec and 802.15.4-2006 spec is how the PHYs are defined. In the 2003 spec, the bit-rate was directly tied to the frequency range of the PHY. For 868 MHz, the bitrate was a meager 20 kbps. 915 MHz got you 40 kbps, and 2.4 GHz had the highest bitrate at 250 kbps. That, coupled with the fact that 2.4 GHz is almost a worldwide standard frequency for the free ISM band, is one of the principal reasons why you see that most of the PHYs available now are at 2.4 GHz.
|Frequency (MHz)||Modulation||Bit Rate (kbps)|
| 868||BPSK ||20 |
| 915||BPSK||40 |
| 2400||O-QPSK||250 |
When the 802.15.4-2006 revision came around, one of the main changes they made was to the PHY definitions since there was such a low uptake of radios in the 868 and 915 bands. They modified the PHYs so that it was possible to use the same modulation (O-QPSK) and spread spectrum (DSSS) scheme in all bands. They also modified the bitrates so they were higher in the 868 and 915 bands. If using an O-QPSK DSSS transceiver, you could then get 250 kbps in either the 2.4 GHz or 915 MHz bands and up to 100 kbps in the 868 MHz band.
|Frequency (MHz) ||Modulation ||Bit Rate (kbps) |
| 868 || BPSK|| 20 |
| 915|| BPSK|| 40|
| 868|| ASK|| 250|
| 915|| ASK|| 250|
| 868|| O-QPSK|| 100|
| 915|| O-QPSK|| 250|
| 2400|| O-QPSK|| 250|
There were also modulation and spread spectrum schemes defined for other PHYs, but it's not likely that they'll catch on. Once a company develops the technology for one PHY (ie: a 2.4 GHz radio using O-QPSK and DSSS ), then supporting the other frequencies that use O-QPSK and DSSS is almost just a matter of changing the center frequency of the radio. Some 868/915 MHz radios are already on the market. According to early tests from the manufacturer, they are getting a significant boost in range at the lower frequencies than at the 2.4 GHz frequency due to the longer wavelengths.
Another reason that the lower bands are interesting is because there is an ongoing debate about using the 2.4 GHz band for wireless sensors due to the issue of coexistence. The 2.4 GHz band is noisy and everyone and their grandma's RF circuits use it for communications. The big monster in this band is 802.11 wireless networks which have a strong radio that can overpower the signals from an 802.15.4 radio.
Along with Wi-Fi, this band is also shared with cordless phones, Bluetooth, proprietary protocols, and microwave ovens. Yep, you heard it. There's a chance you can drop a connection by heating up that day-old coffee. Actually, the research into coexistence finds that the noise from microwave ovens is negligible, but hey, you never know.
Anyways, on the hardware side, the important information to know aside from the band of operation is probably the number of channels and the frequency of operation. Aside from that, the other important parameters that I normally keep track of is the Tx power, Rx sensitivity, and the power consumption of the chip. You can check out my 802.15.4 chip comparison sheet here .
802.15.4 PHY Services
The 802.15.4 spec defines a PHY interface that consists of two types of services: a data service and a management service. In reality, this interface is basically useless to software writers because the PHY interface will be defined by the radio that you are using. Hence it basically just ends up being taken care of by the hardware or in the very low, low, low level driver. In any case, I still think that it might be beneficial to add some verbiage on the basics of the PHY interface. s
The PHY data service consists of :
- Data Request:
- This is usually just a transmit function. Basically, you take the data that you want to transmit and you stuff it into the outgoing FIFO of your radio.
- Data Confirm:
- Most radios will give you some type of status indication after you transmit the data. The status information will tell you if the data was transmitted successfully, if you were jammed due to interference, or if some catastrophic failure occurred that rendered transmission impossible (ie: your transceiver blew up).
- Data Indication:
- This is going to be signaled from your Rx Data ISR. When data arrives into your radio's inbound FIFO, then it will trigger an interrupt. From your ISR, you will normally signal to the MAC layer that data was received and needs processing.
On the PHY management service side, there are just a few services that need to be taken care of:
- Clear Channel Assessment :
- Before sending a frame, the PHY needs to perform a clear channel assessment (CCA). This is part of the collision management protocol (CSMA/CA) and prevents sending a frame while another frame is in the process of being transmitted and thus corrupting it.
- Energy Detection:
- Energy detection (ED) should return the amount of noise detected over the media. It is principally used in the initial network scan if the device is starting its own network. When you do a network scan, you go through two phases of scanning. The first phase is the energy scan where you check the amount of energy on each channel. This is where the ED scan is used. The second phase of the network scan is where you count the number of networks on each channel and will be discussed in the MAC section.
- Set Tx/Rx State:
- This service allows the PHY transceiver to be enabled, disabled, set in Rx mode, or set in Tx mode.
- Get/Set Phy PIB:
- The PHY Pan Information Base (PIB) contains information related to the PHY configuration. Normally most of these will be either constants or the information will be held in the transceiver. I haven't seen too many stacks that actually discretely implement this structure since the information is usually redundant. The types of info that this structure defines are things like:
- Current channel
- Channels supported
- Transmit Power
802.15.4 PHY Frame Format
This is going to be a quick section. The PHY frame format just consists of a synchronization header to mark the start of the frame and a PHY header. The sync header is usually added by the hardware to mark the start of the frame so there's no need to worry about it. The PHY header consists of a single byte which holds the size of the frame. Told you it'd be quick.