The Industrial Internet of Things is predicated on large-scale, distributed sensor/control networks that can run unattended for months to years with very low power consumption. The characteristic behavior of this type of network entails very short bursts of message traffic over short distances using wireless technologies, often described as a low-rate, wireless personal area network (LR-WPAN). We keep the data frames short to lessen the possibility of radio interference forcing the need to retransmit. One such LR-WPAN approach uses the IEEE 802.15.4 standard. This describes a physical layer and media access control that are often used in the industrial control and automation applications referred to as Supervisory Control and Data Acquisition (SCADA).

Figure 1.IEEE 802.15.4 Frame Format

In the IoT, local “edge” devices, typically sensors, collect data and send it to a data center — “the cloud” — for processing. Getting the data to the cloud requires communicating using the standard IP protocol stack. This can be done by directly connecting the edge devices via the Internet to the data centers — the “cloud model.” Or, we can communicate from the edge devices to a collection point known as a border gateway to have the data relayed from there to the data center — the “fog model.”

This article will describe characteristics of IEEE 802.15.4 networks, specifically the Internet Engineering Task Force (IETF) IPv6 over Low-power Wireless Personal Area Networks (6LoWPAN) implementation. This implementation supports both the cloud and fog models.

IEEE 802.15.4 PHY Layer

The IEEE 802 standards family is broken out into a number of task groups including 802.3 (Ethernet) and 802.11 (Wi-Fi), as well as 802.15 (Wireless PAN). In particular, IEEE 802.15.4 (15.4 for brevity) is the responsibility of Task Group 4, which is responsible for various characteristics of the protocol including RF spectrum and the physical layers. The 15.4 standard has been expanded to include Radio Frequency identification (RFID) PHYs, ultra-wideband (UWB) PHYs, and is also being discussed as a possible solution for both car-to-car and car-to-curb communications.

802.15.4 only addresses the physical (PHY) and media access control (MAC) layers — in the OSI network model, layers one and two. It leaves the upper layers to the implementer. At layer three and above, there are a plethora of offerings including Zigbee, Z-Wave, Thread, and 6LoWPAN. Each of these implements the remainder of the OSI protocol model to deliver services such as routing and discovery as well as APIs for user applications.

Figure 2. Topology Options

In general, 15.4 supports data transfer rates at 20 Kbit/s, 40 Kbit/s, 100 Kbit/s (soon), and 250 Kbit/s. The basic framework assumes a 10-meter range at 250 Kbit/s. Even lower data rates are achievable to further limit power consumption. In spite of the 10-meter (32-foot) range specification, in the 2.4GHz ISM band, typical achievable ranges for IEEE 802.15.4 radios are on the order of 100 feet indoors, and 200 – 300 feet outdoors. In the sub-GHz frequencies, practical implementations of the protocol have been demonstrated at ranges of over 6.5 km (4 miles) with appropriate antennas in the 900 MHz ISM band.

At the physical layer, IEEE 802.15.4 manages the RF transceiver and channel selection, as well as energy and signal management facilities. There are six PHYs currently defined, depending on the frequency range and data performance required. Four of them use Direct Sequence Spread Spectrum (DSSS) frequency hopping techniques. Chirp spread spectrum (CSS) is in use in the Ultra-Wide Band (UWB) and 2450 MHz frequency bands. Parallel Sequence Spread Spectrum (PSSS) is available only with the hybrid binary/amplitude shift keying modulation technique found in the European 868 MHz band.

The frame size for 15.4 is 133 bytes including PHY, MAC, and the data payload. The format for this frame can be seen in Figure 1. By keeping the frame relatively short, we can limit the amount of time needed to transmit it while simultaneously limiting the probability of radio interference due to the normal operation of industrial equipment.

IEEE 802.15.4 MAC Layer

The IEEE 802.15.4 MAC layer (OSI Model layer two — data link layer) is responsible for:

  • Joining and leaving the PAN;
  • Carrier Sense Multiple Access with Collision Avoidance (CSMA-CA) for channel access;
  • Guaranteed Time Slot (GTS) transmissions;
  • Establishing a reliable link between two peer MAC entities;
  • Beacon transmissions for a coordinator;
  • Synchronization to the beacons.

In addition, the MAC layer supports the use of symmetric encryption using the AES-128 encryption algorithm. There are also options for SHA-based hashes and access control lists to limit the transfer of sensitive information to specific nodes or links. Finally, the MAC computes a freshness check between frame receptions to help minimize the potential for old frames that may have been traveling over a circuitous path from being delivered late to the upper-layer protocols.

Node Types and Network Topologies

Figure 3. IP Header Compression of IPv6 Header

IEEE 802.15.4 identifies two different types of network nodes: reduced function devices (RFD) and full-function devices (FFD). FFDs can talk to other FFDs or to RFDs and can even create their own networks. However, RFDs can only talk to FFDs. This implies a hierarchy that leads to two possible network topologies: a star topology or a peer-to-peer topology such as a mesh. These are depicted in Figure 2.

The star topology is the easiest and least expensive to implement, it only requires a single FFD. The rest of the devices can be either RFDs or FFDs, depending on the implementation. The downside of the star topology is that the coordinator represents a single point of failure. This can result in a total failure of the network and should be avoided in all but the simplest of applications.

The use of a mesh topology provides for multiple, redundant, communication paths to ensure the delivery of messages. When running in mesh mode, the network is essentially an ad hoc, self-organizing entity. Connectivity can therefore be continued despite changing RF propagation characteristics such as multi-path or effects from foliage. The use of a mesh topology also provides for moving nodes, such as found in industrial robotics. A “lossy mesh” is one where not all links are reliable, so a higher-layer routing protocol is used to reroute message traffic based on connectivity at any given point in time.


Owing to the exhaustion of the IPv4 address space, there is considerable interest in transitioning to IPv6, which provides layer three (network) and layer four (transport) and sits on top of the MAC layer. Normally, IPv6 uses a forty-byte header and provides 128 bits of address space, which can deal with even the largest estimates for IoT-connected devices.

Figure 4. Raspberry Pi Border Router with 6LoWPAN Module

However, when coupled with AES-128 encryption overhead, the use of a default-sized IPv6 header would leave only thirty-three bytes for user payload in the frame. IP header compression (IPHC) was introduced to address the problem. This can reduce the size of the IPv6 header to a mere ten bytes, including routing for Internet traversal. This IPHC can be seen in Figure 3.

This combination of IPv6, IPHC, and standard TCP/UDP sitting on top of the 15.4 PHY and MAC layers is what is known as 6LoWPAN. When coupled with the use of POSIX-style sockets, the developer can have end-to-end packet delivery anywhere in the world using normal Internet protocols.

Implementing 6LoWPAN for the IoT

There are many existing implementations of 6LoWPAN. One is sub-GHz 6LoWPAN for the advanced metering infrastructure (AMI) currently implemented in power meters for residential use. These meters provide utilities a means of both reading and controlling power usage across the electrical grid. They rely on a lossy-mesh routing facility to ensure the delivery of meter measurements regardless of multi-path or atmospheric effects such as rain or snow.

6LoWPAN code size is moderate. The typical implementation is on the order of about 30KB and is often implemented directly in the radios from companies like Texas Instruments, Silicon Labs, and others. This approach provides a UART-style interface between the sensor microcontroller and the radio, thereby offloading the protocol overhead to the radio unit.

Alternatively, many operating systems such as Linux, already implement 6LoWPAN on a number of radio platforms. This provides for the use of Linux-based border gateways to provide security for the edge devices using a fog model via hardened kernels, next-generation firewalls, and more. The border gateway can also be used to provide data filtering and compression to reduce overall communication costs.

Since 6LoWPAN is compatible with normal Internet protocols, the developer is free to leverage higher-level protocols such as MQTT, CoAP, and HTTP for communications from application to application. A border router that interfaces to 6LoWPAN on the southbound side and standard IPv4 or IPv6 on the northbound side can easily provide network address translation (NAT) automatic translations from the internal 6LoWPAN packet format to standard IPv6 or via a NAT64 to standard IPv4. This makes the edge device's addressing completely transparent to the cloud and to the developer. A Raspberry Pi-based border router with a 6LoWPAN module attached is shown in Figure 4.


The IoT is all about connectivity and the IEEE 802.15.4 standard provides a means that is ideal for implementing it — low-power operation across a lossy mesh. The use of 6LoWPAN on top of IEEE 802.15.4 provides for secure, transparent connectivity with the cloud and significantly reduces the burden on developers and system designers by providing standard IP-compatible protocols and readily available libraries.

This article was written by Mike Anderson, CTO/Chief Scientist, The PTR Group (Ashburn, VA). For more information, Click Here .

Sensor Technology Magazine

This article first appeared in the September, 2017 issue of Sensor Technology Magazine.

Read more articles from this issue here.

Read more articles from the archives here.