The current state of 6LowPan connecting Bluetooth IoT devices to the internet

By Peter Dons Tychsen, Bluetooth geek-galore, freelanceconsultant TechPeople


All is not what you think when IoT devices get connected: One of the more curious things about IoT devices is that most of them are not actually a part of what we today loosely describe as the “Internet”.  The “Internet” is usually defined as a global network consisting of TCP (Transmission Control Protocol) combined with protocols like IPv4 and IPv6, and various other supporting protocols.

Despite the name “Internet Of Things”, IoT devices rarely have support for any of these protocols, making a direct link to (or from) them impossible. Based on the idea that the Internet Protocol could and should be applied even to the smallest devices, 6LowPan is now entering the arena. This article offers a look into the inner workings of 6LowPan, together with assessing the current state of adoption of the standard. And although many difficulties lie ahead, one thing is for sure: 6LowPan over Bluetooth is not standing still.


Gateways provide connectivity

Instead of a direct link, a steady stream of proprietary gateways of many shapes and forms are used to connect to IoT devices or to collect data from them. This holds true for low-power radio systems like Bluetooth LE, ZigBee, Z-wave and similar technologies. This is in contrast to other technologies like WiFi (IEEE 802.11) which are often accompanied by a TCP/IP stack, which can make them a part of a local or global network.

The problem with the current approach is that you need proprietary software on an intermediate device like a phone, server or router to be able to talk to your IoT device. This makes sense if your device is one device of many in a larger farm of devices, where only the combined data from all the devices is of interest. However, if your device is a low-power, self-contained device, you might want to simply talk to the device directly. That way you can avoid all the other data pit-stops, which makes your product more complex and requires constant maintaining. Keeping an IOS, Android or Linux server applications working over time is far from free, and can lead to unnecessary complexity. Security can also become more tricky, and peer-to-peer security can be harder to achieve, as all the pit-stops might need some kind of awareness of the data being transmitted. Even if this is not the case, it would be optimal, if existing and proven security protocols like “TSL” and “SSL” (which are used for e.g. secure web browsing) could be used directly to connect to the device over IPv6. Bluetooth LE is a fairly young technology, while the fundamentals that make up for the security on e.g. the Internet are old, mature and well proven.


Bluetooth IoT, simplified

So what would a typical example look like in the real world? Let’s take an example, where a user wants to query a specific Bluetooth IoT device for some data via a browser. To do this currently it would involve a web-server to process the requests and a proprietary application on e.g. a mobile phone which has a Bluetooth link to the device. But what if the IoT device was the web server? This would eliminate the need for an external web server all together, and would reduce the mobile phone to a simple TCP/IP router with no knowledge of the device’s application or the data. You could also keep the web server, and only eliminate the phone application, if the server needed to process the data.

This typology is something we already take for granted, when it comes to other technologies. People would e.g. find it very odd, if they needed a special app on their WiFi router for their TV to work. Normally you would assume that any WiFi device that is connected directly to your home network is on the “internet”. This is not empirically true, but merely a result of standards and protocols having evolved this way. To help Bluetooth and other protocols evolve to this step, 6LowPan enters the arena.

6LowPan stands for “Low-Power Wireless Personal Area Networks”, and is like other internet standards defined by the “Internet Engineering Task Force”, via the “RFC 6282” document, and further defines “RFC 7668”, which details how specifically TCP/IPv6 is mapped on top of Bluetooth Low Energy with regards to addressing and such.

Further, to incorporate it into to world of Bluetooth, defines the “IPSP” standard, which maps the 6LowPan protocol into L2CAP on a fixed port number. With all this in place, the IoT device can now talk directly to a TCP/IPv6 network, such as the “Internet” as we know it.


What protocols make the magic work?

Combining all the mentioned standards and protocols makes up a complete protocol stack from application to physical transport. The protocol stack ends up looking like this:

To avoid having to introduce new addresses to the system, the Bluetooth address (which is a 6 byte MAC address issued by IANA) is mapped directly into a reserved range of IPv6 addresses, which will therefor not collide with any existing IPv6 addresses. This is a clever trick, as this means that you can deduct the address of your remote IPv6 device, simply by knowing its Bluetooth address.

In the end the whole point of this is the application. This means that existing TCP/IPv6 applications and protocols can now be placed directly on top of the protocol stack. This could give life to older TCP based protocols like “FTP” and “Telnet”, which are fairly bandwidth effective, but could also be used with newer protocols like “HTTP”.

Looking at the entire protocol stack, one might deduct that this is all a bit too much for a small microcontroller to handle, as this requires processing of additional packet check sums and protocol handling. However, in practice, an efficient and minimal implementation of this can be done in a couple of kilobytes of code on a microcontroller like the ARM Cortex M0, which is an entry-level controller at the time of writing. It goes without saying that for high data throughput, larger controllers will be needed. Bluetooth 5 introduces new, faster packet types that can hold more data and transmit faster.


Making large packets fit inside small containers

One of the largest challenges of using TCP/IPv6 on devices with limited resources is the fact that IPv6 was initially designed for large systems with large payload sizes. An original IPv6 and TCP header is usually around 48 bytes. As the hardcoded payload area for a Bluetooth LE can be as low as 27 bytes, this is a challenge. Furthermore, you would not like to see all your battery power and bandwidth go up in smoke because of excessive headers. To remedy this, 6LowPan utilizes something called “Header Compression” to vastly reduce the size of the problematic headers. The compression of 6LowPan datagrams is specified in standards such as “RFC 6282”.

One of the most significant compression mechanisms is the “LOWPAN IPHC“ which defines how IPv6 headers can be reduced to a few number of bytes by using some carefully defined logic that causes much of the information to become implicit. Other schemes define how TCP/UDP and other internet protocols can be compressed in a similar fashion.

If you have a bandwidth limited link, this will make a world of difference. For a 10 byte payload sent inside a 27 byte MTU (Max Transmission Unit) physical link, it would look like this without any compression:






Via header compression this can be reduced to:

Great Scott! This means 3 times less power, and 3 times less bandwidth is used. That is a significant reduction and makes the technology much more appealing.

The things that are compressed are usually addresses and port numbers. As an example, because the Bluetooth address is mapped directly into the IPv6 address, the remote address can be deducted to zero, if the receiver of the IPv6 packet is the same entity as the device receiving the Bluetooth LE packet. In a similar fashion, other fields can be eluded by using implicit knowledge to deduct the values.


With great protocols comes great power

One thing to always worry about is power. Contrary to the name, Bluetooth Low Energy is not very low energy if you are sending a lot of data frequently. So you really want to keep your IoT device in a sleeping state as much as possible. One way to do this is simply to apply reasonable values for Bluetooth LE related parameters such as the “connection interval“, which limits the number of slots  used for detecting incoming traffic.

But when IPv6 is introduced into the mix, a new problem arises. Apart from the information you want to send, the gateway itself could be sending vast amounts of broadcast information, which is not necessarily useful for your device. As an example, many networks utilize discovery protocols to detect which devices and what services are available on the network, such as the IPv6 “neighborhood discovery”.

To battle one of these problems the “RFC 5741” introduces optimizations to what “neighborhood search” requests are sent to the 6LowPan enabled device. Another, more simple approach, is to simply make sure that the network devices on your network are only setup to route the most necessary packets to the device. This can typically be controlled via firewall and routing rules. However, as the gateway might be an off-the-shelf phone, that might not be an option.

Power consumption will always be in focus, and 6LowPan will not change that. However, we might  see new challenges in existing protocols along the transition towards IPv6 (if we are going that way), as many of them were simply not designed with such power critical devices in mind. However, standard extensions like “RFC 5741” seems to ratify this rather nicely. And it will likely not be the last.


Playing around with 6LowPan in the Penguin’s sandbox

When 6LowPan was developed, an open implementation was needed to test and verify it with. As Linux is widely accepted as the de facto standard for embedded open source development, implementing 6LowPan as a module for Linux was obvious. So since kernel 3.17 (from 2014) this has been possible to some extent. As the standard evolved, so did the kernel module, so a newer version of the kernel is recommended. Additionally, the kernel module will need to be enabled, and the documentation on how to do this is available several places online. Searching for the keywords “Linux” “Bluetooth” and “6LowPan” should get you started.

For Embedded or Windows usage, a proprietary stack is needed, as Windows does not currently support 6LowPan out of the box. This can be obtained from various sources, including the author’s own “DTBT – DonTech BlueTooth”, which has support for 6LowPan on Windows, MacOS and embedded targets. Some embedded targets, like Texas Instruments 2630, natively support 6LowPan and IPv6.

To help the developers along, the sniffers and packet tracers used for Bluetooth and networks have adopted support for these new protocols as well. Sniffers from Wireshark, Frontline and Ellisys have gained support for parts of the 6LowPan stack.

Below is an example trace of the classical “IP ping” being sent from a Linux device to a Bluetooth connected Windows implementation with DTBT:

Who is on the 6LowPan train, and where is it going?

There are many backers of the 6LowPan standard, including the biggest producers of Bluetooth controllers such as “Texas Instruments” and “Nordic Semiconductor”.  Other companies are also pushing 6LowPan for other low-power network types. The thing they have in common is that they are chipset manufacturers and not end product manufacturers. The biggest challenge with the 6LowPan is not the standard, the producers of chipsets or the specific implementations. The big hurdle is adoption.

IoT is currently a very hot subject, but various companies want to make their own IoT ecosystem, where they can sell more of their own products. This is a classical problem. In the early days of the Internet, many companies like Microsoft, AOL and CompuServe tried to push their own version of the “Internet”, so they would have complete control over devices and services sold on it. Today, people would hardly accept a solution where e.g. your TV only worked with a specific Internet connection.

Companies like Apple and Google still seem to be interested in this philosophy. On one hand they present things as an open-ish platform, so other manufacturers can participate, but on the other hand they do not wish to employ open standards to accomplish their goals. They still want control, and this bait-and-switch tactic can be something that keeps consumers and companies from fully embracing the technology.  However, if history is to repeat itself, technologies like 6LowPan could change all that.

So for now, there is no 6LowPan on Android or IOS. Actually, Linux is the only platform supporting it out-of-the-box. As Android is based on Linux, they could of course suddenly announce its arrival, if they felt it did not get in the way of any of their own visions of deploying devices like “Google Home”.

One thing is for sure, though. 6LowPan over Bluetooth is not standing still. The more recently released “Bluetooth Mesh Profile” for Bluetooth LE has already gotten a new sister RFC called “draft-ietf-6lo-blemesh-00”. As the name indicates, it is still in draft. But the goal is to extend 6LowPan to cover mesh networks using Bluetooth. So companies that are looking into Bluetooth mesh might also want to take a look at topping if off with IPv6 connectivity.

Bluetooth™, Linux™, Windows™, IOS™ and MacOs™ are trademarks of their respective owners.

We use cookies to give you the best online experience. By agreeing you accept the use of cookies in accordance with our cookie policy.

Privacy Settings saved!
Privacy Settings

When you visit any web site, it may store or retrieve information on your browser, mostly in the form of cookies. Control your personal Cookie Services here.

These cookies are necessary for the website to function and cannot be switched off in our systems.

In order to use this website we use the following technically required cookies
  • wordpress_test_cookie
  • wordpress_logged_in_
  • wordpress_sec
  • ct_checked_emails
  • ct_checkjs
  • ct_fkp_timestamp
  • ct_has_scrolled
  • ct_pointer_data
  • ct_ps_timestamp
  • ct_screen_info
  • ct_timezone

Decline all Services
Accept all Services