Skip to main content

14.8 IEEE 802.15.4 and 6LoWPAN

In the previous section, we enjoyed the conveniences of the Bluetooth "Personal Area Network." In this section, we are heading into a much stingier, more demanding world.

There is no bandwidth to spare here—every single bit must be carefully budgeted. Devices spend most of their time sleeping, and are only allowed to speak during the brief moments they are awake. This is the world of the Internet of Things (IoT), starring IEEE 802.15.4 and 6LoWPAN running on top of it.

In this world, standard Internet protocols (IPv6) run into huge trouble. MTU mismatch, addresses too large to fit, no multicast support—each one is a fatal flaw. But engineers not only solved these problems, they also managed to cram IPv6 into microcontrollers that cost only a few dollars.

This section is essentially about "how to stuff an elephant into a refrigerator"—and doing it elegantly.

8.1 What is IEEE 802.15.4?​

Let's lay out the standard first: IEEE 802.15.4 defines the MAC layer and Physical Layer (PHY) for Low-Rate Wireless Personal Area Networks (LR-WPANs).

Its design goals boil down to just two words: low cost and low power.

To achieve these goals, it makes quite a few compromises:

  • Low data rate: Up to 250 kb/s (in the 2.4GHz band), with even slower options available.
  • Short range: Usually hovering around 10 meters.
  • Small frames: The Physical Layer Maximum Transmission Unit (MTU) is only 127 bytes (IEEE802154_MTU).

Where do these devices typically come from? Wireless Sensor Networks (WSN), security sensors, and industrial automation switches. The standard is maintained by the IEEE 802.15 working group.

Sitting above this protocol layer are usually two major players: one is ZigBee (a proprietary protocol, though open standards like ZigBee IP exist), and the other is the star of today's show—6LoWPAN.

8.2 Why must we use IPv6?​

Some people might ask: With such terrible network speeds, wouldn't a proprietary protocol be much easier?

It is indeed easier, but not free. If we want our sensors to connect directly to the Internet without deploying a massive pile of gateways for protocol translation, we have to use IP.

IPv6 is the only choice here, for three reasons:

  1. Plenty of addresses: The IPv6 address space is astronomical, capable of assigning a public IP address to every grain of sand on Earth. For sensor networks that easily scale to hundreds or thousands of nodes, this is a hard requirement.
  2. Simpler header: The IPv4 header has a variable length, making it cumbersome to process; the IPv6 header is fixed-length, and its extension headers are also simpler to handle than IPv4 Options.
  3. Auto-configuration: IPv6's Stateless Address Autoconfiguration (SLAAC) is perfectly suited for these unmanaged, low-end devices.

But the problem is that IPv6, a "noble protocol," was never designed for the "slums" of IEEE 802.15.4. To make it run, we need an adaptation layer, and that is 6LoWPAN.

There is a whole pile of related RFCs. We're listing them here just to give you a sense of the activity in this field—you don't need to memorize them all:

  • RFC 4944: Defines how to transmit IPv6 packets over 802.15.4 (the old standard).
  • RFC 4919: The overarching 6LoWPAN blueprint.
  • RFC 6282: The core. Introduces the much more efficient LOWPAN_IPHC encoding format, replacing the old-school HC1 and HC2.
  • RFC 6775: Neighbor Discovery optimizations.
  • RFC 6550: The RPL routing protocol (designed for Low-Power and Lossy Networks).

8.3 Adaptation Layer Challenges: Three Mismatches​

Now let's look at the exact pain points the adaptation layer needs to solve. If these three problems aren't solved properly, the network simply won't run.

Challenge 1: The Massive MTU Gap​

  • IPv6 requires: A link MTU of at least 1280 bytes. This is IPv6's bottom line; below this value, the standard dictates that you must handle fragmentation at the network layer yourself.
  • IEEE 802.15.4 provides: An MTU of only 127 bytes.

What does this mean conceptually? It's like trying to mail a thick book (1280 bytes) using a small envelope (127 bytes). The adaptation layer has to tear this thick book into over a dozen tiny fragments, send them over, and have the other side reassemble them.

This is the first core task of the 6LoWPAN adaptation layer: transparent fragmentation and reassembly.

Challenge 2: Addresses Too Long to Fit​

  • IPv6 address: 128 bits.
  • IEEE 802.15.4 address: Either a 64-bit extended address (IEEE802154_ADDR_LONG), or a 16-bit short address (IEEE802154_ADDR_SHORT) assigned upon joining the network (unique only within the PAN).

If we don't do any compression, just the two IPv6 addresses (source + destination) alone eat up 32 bytes. Add the header, and what data can actually fit in this packet?

Solution: Leverage the 802.15.4 short addresses and link-local prefix for extreme compression. 6LoWPAN has a complex compression mechanism (IPHC) that can compress a 40-byte IPv6 header down to just a few bytes.

Challenge 3: Multicast Disappeared​

IPv6 relies heavily on multicast, especially ICMPv6 and the Neighbor Discovery Protocol (ND), which entirely depend on multicast to function.

But IEEE 802.15.4 does not support multicast. It only supports broadcast (using the 0xFFFF short address).

It's as if everyone is used to shouting "Hey, specific group (multicast)," but the underlying hardware only understands "Hey, everyone (broadcast)." The adaptation layer has to figure out how to "translate" IPv6 multicast requests into something the hardware understands, or simply rewrite the Neighbor Discovery Protocol (which is exactly what RFC 6775 does).

8.4 Frame Types and Device Classifications​

IEEE 802.15.4 defines four frame types. We will frequently see their macro definitions in kernel code:

  • IEEE802154_FC_TYPE_BEACON: Beacon frame (used for network synchronization).
  • IEEE802154_FC_TYPE_MAC_CMD: MAC command frame.
  • IEEE802154_FC_TYPE_ACK: Acknowledgment frame.
  • IEEE802154_FC_TYPE_DATA: Data frame.

IPv6 packets can only ride in the fourth vehicle (data frames). Although ACKs aren't mandatory, anyone who uses them knows that turning them on makes things much more stable.

There is also the distinction between HardMAC and SoftMAC here (just like with Wi-Fi):

  • HardMAC: The hardware handles the entire protocol on its own, and the driver only cares about receiving data.
  • SoftMAC: The kernel (MAC layer) does most of the heavy lifting, and the hardware only handles the radio signals. Linux's mac802154 is responsible for this.

Three Roles in the Network​

In a 6LoWPAN network, not all nodes are created equal. The RFCs divide them into a hierarchy:

  1. 6LoWPAN Node (6LN):

    • Definition: Can be either a host or a router.
    • Characteristics: Relatively "dumb" with limited capabilities; spends most of its time sleeping (to save power).

  2. 6LoWPAN Router (6LR):

    • Definition: Can send and receive Router Advertisements (RA/RS) and forward data packets.
    • Characteristics: A bit smarter than a 6LN, with slightly more memory and CPU, responsible for hauling data around within the network.

  3. 6LoWPAN Border Router (6LBR):

    • Definition: The gateway node. It stands at the boundary between the 6LoWPAN network and a regular IP network (like Ethernet).
    • Responsibilities:
      • Handles data forwarding between the two worlds.
      • Manages IPv6 configuration for 6LoWPAN nodes.
      • Maintains context information.
      • Must almost always be online (cannot sleep).

You can think of a 6LBR as a hardworking translator. On one side is a sensor network speaking a dialect; on the other is the Internet speaking standard protocol. It has to keep watch 24/7 and cannot sleep.

8.5 The "Hack" on the Neighbor Discovery Protocol​

Standard IPv6 Neighbor Discovery (ND) has two major pitfalls in the IoT world:

  1. Multicast dependency: As mentioned earlier, the hardware doesn't support it.
  2. Power anxiety: The ND protocol assumes devices are always awake and listening for router multicast advertisements at any time. But 802.15.4 devices spend most of their time dozing off; waking up just to receive one packet is too power-hungry.

Therefore, RFC 6775 introduced targeted optimizations to the ND protocol.

Optimization 1: Stop Shouting Periodically​

In standard IPv6, routers periodically send out multicast advertisements. RFC 6775 says: Stop. Instead, it shifts to host-initiated requests. When a host wants to know if a router is present, it sends a unicast message. The router doesn't need to shout for no reason.

Optimization 2: Simplification of Duplicate Address Detection (DAD)​

If the IPv6 address is generated based on EUI-64 (globally unique), theoretically there is no need to perform Duplicate Address Detection (DAD). Saving a step is saving a step.

Three New Options Added​

To support the above optimizations, RFC 6775 added three new options to ICMPv6:

  • Address Registration Option (ARO, Type 33):
    • When a host sends a unicast NS message to a router, it includes this option, meaning "Boss, I'm registering this address."
    • If it wants to deregister, it just sends an ARO with a lifetime of 0.
  • 6LoWPAN Context Option (6CO, Type 34):
    • Carries prefix information used for header compression. Similar to the standard IPv6 PIO, but used by the compression layer.
  • Authoritative Border Router Option (ABRO, Type 35):
    • The Authoritative Border Router option. Used to propagate information about "who the real boss (6LBR) is" across the network, along with network context.

Two New ICMPv6 Message Types Added​

To handle address conflicts, two new messages were also added:

  • Duplicate Address Request (DAR, Type 157)
  • Duplicate Address Confirmation (DAC, Type 158)

8.6 Linux Kernel Implementation: A Three-Layer Structure​

The Linux kernel has included 6LoWPAN in the mainline since v3.2 (contributed by the Siemens team). The code structure is clearly divided into a typical three layers:

  1. Network Layer: net/ieee802154
    • Contains the 6lowpan module, Raw Sockets, Netlink interfaces, etc.
  2. MAC Layer: net/mac802154
    • This is a soft MAC implementation responsible for handling 802.15.4 MAC layer logic, used by SoftMAC drivers.
  3. PHY Layer (Driver Layer): drivers/net/ieee802154
    • Various specific chip drivers.

Supported Hardware​

Although the protocol standard is quite grand, the Linux kernel actually doesn't support that much hardware (compared to Wi-Fi):

  • AT86RF230/231: Atmel (now Microchip) transceivers.
  • MRF24J40: From Microchip.
  • Fakelb: A virtual loopback driver used to test the protocol stack when no hardware is available.
  • atusb: USB dongles based on the AT86RF231 (some are in mainline, some are still being worked on).

Most of these devices are connected to the main controller board via SPI, though there are also serial connections (experimental).

8.7 Initialization and Data Reception: A Code Perspective​

Let's look at how the code actually runs.

Registering the Protocol Handler​

The initialization function lowpan_init_module() mainly does two things:

  1. Initializes the Netlink socket.
  2. Registers the protocol handler.

It defines a packet_type structure lowpan_packet_type, telling the kernel: "Any packet of type ETH_P_IEEE802154 (0x00F6) should be handed over to me."

static struct packet_type lowpan_packet_type = {
        .type = __constant_htons(ETH_P_IEEE802154),
        .func = lowpan_rcv,
};

static int __init lowpan_init_module(void)
{
        . . .
        dev_add_pack(&lowpan_packet_type); // 把这个 handler 挂到内核协议栈上
        . . .
}

This lowpan_rcv is the 6LoWPAN main Rx entry function. When a data packet comes up from the physical layer and is processed by the MAC layer, it ultimately calls this function.

Linux implements a very clever "virtual link" mechanism to adapt the MTU:

  • One end (6LoWPAN Interface): MTU = 1280, speaking standard IPv6.
  • The other end (WPAN Interface): MTU = 127, speaking the 6LoWPAN dialect.

The incoming packet flow (lowpan_rcv):

  1. Determine: Is this a compressed packet or an uncompressed one (Dispatch Type)?
  2. Decompress: If it's compressed, call lowpan_process_data().
    • Inside, it calls lowpan_uncompress_addr() to decompress the addresses.
    • It calls lowpan_uncompress_udp_header() to decompress the UDP header (if it's UDP).
  3. Deliver: Once decompressed, it is restored into a standard IPv6 skb.
  4. Pass up: It calls lowpan_skb_deliver() to hand this packet over to that virtual 6LoWPAN interface with an MTU of 1280.

Once it reaches this interface, the kernel's IPv6 protocol stack claims it, just like handling a normal Ethernet packet. This achieves the seamless translation from the "underlying dialect" to the "upper-layer standard language."

8.8 Regarding Contiki and Other Resources​

It's worth mentioning that a portion of the Linux 6LoWPAN implementation (such as UDP header compression) was actually ported from Contiki OS.

Contiki is an open-source operating system specifically designed for the IoT, developed by Adam Dunkels. It holds a high status in the embedded world, having implemented not only 6LoWPAN but also the RPL protocol stack. The Linux community stood on the shoulders of giants and brought this layer of technology into the kernel.

If you want to dig deeper, you can check out:

  • 6LoWPAN: The Wireless Embedded Internet (Shelby & Bormann)
  • Interconnecting Smart Objects with IP (Vasseur & Dunkels)

On the management tools side, there is a lowpan-tools package that can be used to manage Linux's LoWPAN stack.

Chapter Echoes​

From Bluetooth to 6LoWPAN, we've seen two extremes of wireless networking.

The Bluetooth in the previous section was like setting up conference rooms in a modern office building—plenty of bandwidth, and while the devices are small, they are quite capable. The 6LoWPAN in this section, however, is like setting up a walkie-talkie network in the wilderness—resources are extremely scarce, and the cost of transmitting every single bit must be calculated.

But the greatness of the Linux kernel lies in its use of a unified network stack abstraction, bringing all these radically different physical layers under the struct net_device and TCP/IP protocol families. Whether it's the soft Bluetooth or the hardcore industrial wireless, their final appearance in /dev is simply a network interface.

However, IEEE 802.15.4 and 6LoWPAN are, after all, "short-range" wireless technologies. In the next section, we will encounter a true "ultra-short-range" technology—so close that two devices must practically be pressed together to communicate. That is NFC (Near Field Communication).

If your mouse won't connect, just run btmon, and everything will be clear at a glance.

Chapter Echoes​

We have completed the full journey from the underlying hardware drivers to the upper-layer IP protocol.

On the surface, this section was about "how Bluetooth connects to the Internet," but in reality, we were looking at how a complete network subsystem collaborates across layers.

  • The HCI layer shields hardware differences (USB, UART, SDIO).
  • The L2CAP layer provides multiplexing and basic transport services.
  • The BNEP layer disguises the heterogeneous Bluetooth link as a standard Ethernet device, allowing the existing TCP/IP protocol stack to run without modification.

Remember the "office building" analogy from the beginning? Now you should understand why the Linux Bluetooth subsystem is so complex: it not only has to manage the building's front desk (HCI), but also the mailroom (L2CAP), and even lay down dedicated freight lines (BNEP) between buildings. Each layer has its own independent state machine and protocol, yet they tightly interlock.

In the next section, we will jump from the Personal Area Network (PAN) to a broader, but more low-level wireless domain—IEEE 802.15.4 and 6LoWPAN. That is the world of the IoT, where protocols are more streamlined and resources are more tightly pinched, but the design philosophy shares striking similarities with Bluetooth.