In the previous two articles from our IPv6 series, we have:

We’ve discussed in these articles that IPv6 has helped mitigate many of the issues presented by IPv4, and that it has and will continue to help the evolution of IoT applications and products. But IPv6 (and more specifically, 6LoWPAN—the IoT “version” of IPv6)  isn’t a “be all, end all” solution for machine-to-machine (M2M) wireless technologies. More specifically, 6LoWPAN isn’t always an adequate solution for LPWAN—or Low-Power, Wide-Area Network—connections and devices.

Before we discuss why 6LoWPAN falls short in this one specific area, let’s define both LPWAN and 6LoWPAN in more detail.

What Is LPWAN?

As previously stated, LPWAN is an acronym for a “Low-Power, Wide-Area Network.” It is ideal for sending a low-bandwidth message across a long range of space. LPWAN is used for sensor data telematics and control networks in a “star topology”—meaning they have an access point in the middle, and receive information from thousands of sensor inputs.

An LPWAN network is able to be long-range and low-power because of very slow modulation rates. In other words, when a data packet is sent very slowly, there’s more energy per symbol (and thus more energy per bit) in the transmission channel. This allows for the data packet to travel a long way.

What Is 6LoWPAN?

The range of a wireless communication device is often a make-or-break decision factor for IoT product developers. To that end, there are many different types of M2M wireless technologies—including those based on 6LoWPAN.

6LoWPAN is a choppy acronym for “IPv6” and “Low-Power Wireless Personal Area Network.” It is essentially the version of IPv6 made for IoT devices. 6LoWPAN (and ZigBee, one of its competitors) are an attempt at creating a more efficient low-power wireless network that would fix the primary aforementioned issue with IPv6 and LPWAN. In many uses, 6LoWPAN is a great solution.

The 1 Big Issue With IPv6 (6LoWPAN) & LPWAN

The reason why IPv6—and all TCP/IP routing schemes, for that matter—are problematic for LPWAN networks is because there’s still a great deal of header information—or supplemental data—that is involved with every data packet. In other words, the header compression capabilities of 6LoWPAN simply don’t make the supplemental data small enough to be carried over a wide distance.

Think of it this way: IPv6 and other TCP/IP routing schemes carry a lot of metadata related to source, destination, port, etc., and all of that needs to go over the air with each data packet. So, a lot has to be “said” before you get to the payload, or body, of the data packet. There are many people out there who are pushing to use 6LoWPAN as an edge routing protocol (wirelessly connected to an endpoint) using a TCP/IP stack, but in our opinion, that isn’t always necessary (or smart) in a managed system.

So what we’ve found is that even though 6LoWPAN is a great technology for short-range IoT devices and 802.15.4-type connections, it simply isn’t sufficient for decreasing or compressing the header to where it needs to be for any kind of low-power, low data-rate system. In addition, 6LoWPAN simply doesn’t have the capacity for range that many IoT products need.

In Conclusion

If you want to create a long-range IoT product and need it to run on a low-power, low data-rate system, then IPv6 and 6LoWPAN technology may not be the way to do it. You’ll need to be able to fit your messages into the 400 ms FCC Part 15 requirement in order to be compliant, and this may not be possible on the extreme edge of sensitivity and low modulation rates. Simply put, 6LoWPAN does not offer enough header compression to support this.

That being said, it’s not as important as you might think to use IPv6 or 6LoWPAN. There are plenty of stable, mature options on the market that act as a proxy for this type of technology that will work really well—including router based translation or server-side proxies.

Our hope is that, in the near future, the Institute of Electronics and Electrical Engineers (IEEE) 6LoWPAN working group adds an even more compressed version of 6LoWPAN that is suitable for LPWAN-type connections.


Written by Brian Ray

Brian is the Founder and CTO of Link Labs. As the chief technical innovator and leader of the company, Brian has led the creation and deployment of a new type of ultra long-range, low-power wireless networking which is transforming the Internet of Things and M2M space.

Before starting Link Labs, Brian led a team at the Johns Hopkins University Applied Physics Lab that solved communications and geolocation problems for the national intelligence community. He was also the VP of Engineering at the network security company, Lookingglass, and served for eight years as a submarine officer in the U.S. Navy. He graduated from the U.S. Naval Academy and received his Master’s Degree from Oxford University.

Related Blogs

Asset Tracking, BLE Asset Management healthcare, Asset Tracking, AirTag, RTLS, iiot, equipment and tool tracking, gps, manufacturing, logistics, cost effectiveness, Differentiation, Data Utilization

Recap: Why Choose Link Labs for Asset Tracking and Monitoring?

Asset Tracking, BLE Asset Management Scalability, Cloud Native Applications, containers, Flexibility, Resiliency, Dev Ops, microservices

Cloud Native Applications on the Rise

Asset Tracking, BLE Asset Management proof of delivery, logistics, efficiency, tracking, Omnichannel Tracking, Returnable assets, employee efficiency, sustainability, lower stock, production line shutdown

2022 IoT Logistics Trends

Subscribe to Link Labs' blog weekly update!


Subscribe to Link Labs' blog weekly update!