By Jon Adams

In my idle moments I’ve been perusing my copy of the IEEE 802.15.4g draft standard document, which is now out for comment within the IEEE group. Last time, I noted the highlights of the proposal – the many new modulation methods, the different approaches to spread spectrum, the multiplicity of frequency bands, licensed and license-free, and more. The more different ways there are to perform a specific function, the more opportunities there are for interoperability challenges, testing issues, and potential misinterpretation of the specification. All this can lead up to what I call “Smart Gridlock”, where the data can’t flow easily in any direction. This time, I thought I’d look at the frame (packet) structure, and see what are the similarities and differences to “plain-old” 802.15.4. Let’s see what we find.

First, remember that at its heart, 802.15.4 is a protocol developed for low-duty-cycle, mostly sleeping devices, with potentially thousands of these devices in a single network, all sharing the same channel. In 15.4 (2006), there are four Media Access Control (MAC) frame types: Beacon, Data, Acknowledgment, and MAC Command. Let’s see how this draft impacts that!

The Beacon frame is a special feature of 15.4, and can enable all sorts of sleeping networks.  If every routing device in a 15.4 network uses a beacon, all the other devices can align themselves to the beacon generated by their closest router, and then go to sleep, waking only to hear the next beacon and see if there’s a message for them. Used properly, it’s easy to get a device to average  just a few microwatts of power. Running on a CR2032 coin cell, that can mean battery life that goes way beyond the shelf life of the battery itself. Absolute maximum length of the Beacon frame, from preamble through the trailing checksum, and depending on the payload, can be 133 octets (bytes). However, it’s usually much less.

The Data frame is the workhorse. When a device needs to send data through the network, the Data frame is the method. The maximum length  is 133 octets. Depending on the overlaying network protocol and the use/non-use of local addressing, there can be as much as 118 octets of data in the payload. Practically, the usual payload capacity is between 80 and 100 octets due to routing instructions, higher-level protocol overhead,  and the like. That’s still plenty of room for saying what needs to be said, especially if you’re a light switch.

The Acknowledgment (ACK) frame adds robustness and reliability. Node A sends Node B a Data frame, and Node B replies to Node A with an ACK frame that contains the same “sequence number” as the received Data frame. That way, Node A knows that the Data frame it transmitted was received successfully, and it’s not required to transmit it again. Total length is 11 octets – it’s a very brief message.

The MAC Command frame handles all MAC peer entity control transfers. This is a way for individual nodes to send MAC commands between one another. These commands include association/disassociation, beacon GTS, and data requests, and a variety of notifications. In theory, the MAC Command frame can be as long as 133 octets.

The big difference in this draft is that the frame length is no longer restricted to the 133 octets specified in (2006).  There, the frame length counter was 7 bits in size, but now it’s defined as 11 bits (2047 octets). This implies that an entire standard ethernet packet (around a 1500 octet MTU) can fit into a single 15.4g frame. That’s a huge change from before. Another interesting change is that the preamble, which used to be strictly defined as 4 octets of alternating 0′s and 1′s, now has a possible range from 4 to 1000 octets in size.  Not sure why one would want a thousand repretitions of “01010101″, but perhaps there’s a good reason for that.

In IEEE 802.15.4(2006) the Frame Check Sequence (checksum function) was 2 octets long; now there’s the ability to select a 4 octet CRC instead. There’s a data whitening bit as well, which can come in handy when long strings of ones or zeros are sent, which can happen often in telemetry systems. Data whitening adds a psuedorandom function that breaks up those long sequences, making it much easier for the receiver demodulator to stay in lock. And there’s now forward error correction (FEC) specified, in addition to the FCS. While FEC adds some level of complexity to the receiver side, it can prevent a retry when RF channel capacity is precious.

It’s obvious that there’s a whole lot more functionality proposed in this draft of IEEE 802.15.4g, far more than what was in IEEE 802.15.4 (2006). With so much optionality comes the real challenge of maintaining interoperability. I think the industry can sort out these challenges. If not, we could be looking at “Smart Gridlock”! What do you think?