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.  

Physical 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:

  1. 868 MHz
  2. 915 MHz
  3. 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)ModulationBit Rate (kbps)

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)
Bit Rate (kbps)
 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.

Channel Occupancy at 2.4 GHz

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.


Speaking of getting hooked up, Dave Blissett at Telegesis just sent me one of their Zigbee Pro USB dongles. It's quite nice and you can use it to issue commands to your network, check out the neighbors, join a network, etc. Unfortunately, it doesn't have any other Zigbee Pro friends to play with, but when I start retrofitting the stack for Zigbee Pro (sometime next year I hope), it's going to be very useful. Here are some pics of the dongle:

I went to Wireless Japan 2008 last week to check it out. In general, I don't like trade shows much, since I think they're an inefficient use of time. However now that I have a blog, I feel obliged to seek out interesting things to post. Unfortunately, there wasn't a whole lot that interested me but  here are some things that kind of tickled my pickle:

  • The Zigbee pavilion was much more crowded than the Wi-Max pavilion, which was like a ghost town. I seriously felt bad for the vendors there. Go figure...
  • There was a huge crowd at the TI Zigbee booth and everyone was asking fairly knowledgeable Zigbee questions. I was also surprised to hear many people asking questions about the CC2591 which was just announced. I guess that means that people are actively following Zigbee news.
  • Renesas will be coming out with their first MCU + radio chip next year. This will be their first 802.15.4 chip and will probably be using the ZMD IP which runs at 900 MHz. Don't take my word for it, tho.
  • People seem to be excited about Japan opening up the 950 MHz spectrum soon. There's currently an 802.15.4 group working on a variant to support this. The variant is called 802.15.4d and was previously posted in this article.
  • This was the first time I saw Greenpeak with a booth in Japan. Looks like they opened up a Japanese office here now that they came out with their first silicon.
  • I thorougly questioned a representative from one of the major Zigbee test houses and he didn't know that Zigbee 2007 was different than Zigbee Pro. This implies that there aren't a lot of companies testing for Zigbee 2007 (or the compliance tests aren't finished yet). 
I guess that's about it. There wasn't anything really ground trembling to report and it pretty much was a yawner. In my opinion, it's best to stay glued to the internet for the latest and the greatest...

Here are some of the pix:

The Zigbee Smart Energy Profile has been getting a lot of attention recently, however there seems to be a lack of information on what the spec actually is. The info that I'm seeing in the press mostly deals with products that are coming out such as smart thermostats or perhaps the marketing research firms discussing the potential market size. There's no doubt that the smart energy market is potentially a very large market for Zigbee, but what exactly is it?

I should probably start with a small blurb on why smart energy seems to have such a large uptake in the US. The move to smart grids probably gained a lot of momentum from the Smart Grid Facilitation Act of 2007. The bill has passed through the committees and its currently on the legislative calendar. Here's a summary:

Smart Grid Facilitation Act of 2007 - Declares it is the policy of the United States:(1) to support the modernization of the electricity transmission and distribution system to incorporate digital information and controls technology and to share real-time pricing information with electricity customers; and (2) that electricity purchasers are entitled to receive information about the varying value of electricity at different times and places, and that states shall not prohibit or erect unreasonable barriers to the provision of such information flows to end users.

The implication of having some form of communications within the meters is that new applications can also be enabled. On the utilities side, automatic meter reading has the potential to save huge amounts since you won't need people to come by your house monthly and check your meter for usage data. All of this information would be available instantaneously via metering networks that the utilities could theoretically set up.

On the consumer side, it would be possible to get instantaneous pricing information on the electricity that is being used and to scale electricity consumption accordingly. I think if most people knew that their 500W PC that they leave on all the time is costing them an additional $100/month, they would be somewhat persuaded to turn it off every so often.

Basically, the Congressional bill, the recent focus on energy efficiency, and the buzz over wireless communication and wireless sensor networks has come together and made smart energy somewhat of a trendy thing. And in the middle of that is the Zigbee Alliance who is surfing the smart energy wave by coming out with the Smart Energy Profile to standardize wireless communications over 802.15.4 networks.

But probably most of you already know all about that. So let's dig into the details of the Zigbee Smart Energy Profile…

I spent the weekend looking over the binding functionality in the Zigbee 2007 spec. Right now, I'm basing all of my implementation on Zigbee 2007 since it doesn't make much sense to do a new implementation based on Zigbee 2006. Actually, while I'm on that subject, I don't think the Zigbee Alliance explained the whole Zigbee spec dichotomy clearly so why don't I harp on that a bit…

The Zigbee spec started out in 2004 and that was known as the original Zigbee spec or Zigbee 2004. In 2006, they revamped the spec based on the feedback they got and that version ended up being called Zigbee 2006. In late 2007, they announced Zigbee Pro which most people think of as Zigbee 2007. However they actually created two versions of the spec. One of them is Zigbee 2007 and one of them is Zigbee Pro. The Zigbee 2007 update didn't get a lot of press coverage so most people didn't even know that they updated the Zigbee 2006 spec.

There were actually many changes from Zigbee 2006 to Zigbee 2007 and unfortunately, they weren't clearly documented in the public version of the spec. In fact, there is only one Zigbee specification document which includes Zigbee and Zigbee Pro. To understand which features belong to Zigbee and which belong to Zigbee Pro, you have to turn to the feature set definitions documents.

I don't really want to get into the differences between Zigbee and Zigbee Pro right now, but I thought I'd highlight some of the major differences between Zigbee 2006 and 2007. Also, I'll complain a bit about how there is no changelist so we need to find a lot of the spec changes ourselves.