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.

download

Jennifer Halstead

Written by Jennifer Halstead

Jennifer Halstead, MBA, CPA brings more than 20 years financial industry experience to Link Labs. She began her career in finance within the pharmaceutical industry and has continued in both public accounting and private companies. She passed the CPA exam with the 3rd highest score in the state and completed her MBA with an accounting concentration (summa cum laude). Jennifer has worked with several software companies and has led multiple venture financing, merger and acquisitions deals. She has helped companies expand internationally and has managed the finance department of a startup to 33 consecutive quarters of growth prior to acquisition. After the acquisition, she served as the Controller of Dell Software Group’s Data Protection Division where she managed a portfolio of multiple hardware and software products to scale and achieve over triple-digit growth worldwide in 18 months. Jennifer brings a depth of finance experience to the Link Labs team.

Related Blogs

Asset Tracking, BLE Asset Management Election Integrity, RTLS, asset tracking system, automation, Elections, legal concerns, chain of custody, mail-in ballot

How Counties Can Avoid Public Scrutiny During Elections

Asset Tracking, BLE Asset Management RTLS, supply chain, remote assets, gps, satellite, automation, Satellite GPS tracker

How Satellites Optimize Supply Chains and Logistics

Asset Tracking, BLE Asset Management Asset Tracking, RTLS Solution, RTLS, asset monitoring, rtls asset tracking, Utilization, process efficiencies, manufacturing, Downtime, historic data, predictive data

Why Monitoring Utilization Improves Process Efficiencies

Subscribe to Link Labs' blog weekly update!

Subscribe

Subscribe to Link Labs' blog weekly update!