Understanding Bluetooth Internet Gateways for IoT Solutions
Based on some work carried out by the Bluetooth SIG relating to the integration of Bluetooth devices with the Internet and IoT architecture, here are some interesting results.
According to the research organisation ABI, Bluetooth technology is in 38 per cent of all IoT devices while WiFi and cellular are in 32 per cent and 19 per cent respectively. As they have different strengths and weaknesses, these are not necessarily mutually exclusive technologies and are often used together in IoT solutions.
But there is a problem! Bluetooth and TCP/IP are not compatible. (IoT implies the use of protocol like TCP/IP.)
As it can be seen, TCP/IP spans only two layers of the Bluetooth stack. Other protocols are also used within the stack TCP/IP and friends (Figure
1). However, Bluetooth LE cannot talk directly with TCP/IP and vice-versa.
Wide standards range
Although some standards that relate to IoT and Bluetooth have been defined by the Bluetooth SIG and others, it is unlikely that all aspects of IoT can be covered using them alone. Currently, the following standards are defined:
RFC7668: An Internet Engineering Task Force (IETF) standard for communication, which defines how IPv6 6LoWPAN packets can be adapted to be sent over the lower layers of the Bluetooth LE stack. Not all aspects of TCP/IP are supported but Bluetooth LE devices using this can have IP addresses and can communicate with each other using 6LoWPAN IPv6 packets.
Internet Protocol Support Profile (IPSP): This is a Bluetooth Low Energy (LE) profile that allows devices that support IP over Bluetooth to be discovered. It defines how the Bluetooth LE stack is used to send and receive IPv6 packets in RFC7668.
HTTP Proxy Service (HPS): This is useful for devices like sensors and allows a Bluetooth sensor or similar to work with a gateway device, which supports both Bluetooth LE and TCP/ IP and can act as an HTTP client. So, the gateway sends an HTTP request to a remote Web server on behalf of and when requested by a Bluetooth device. Any data received from the Web application server gets sent back to the Bluetooth device.
Some useful standards exist. But if you want to drive interactions with
Bluetooth devices from the Internet for general IoT use cases, then you need a gateway, which has some kind of adaptation scheme (an API) so that requests can be expressed using a TCP/ IP based protocol and then translated by the gateway into the appropriate Bluetooth requests and sent to a connected Bluetooth device.
To use Bluetooth in an IoT context, you usually need something which can convert between some application protocols that run over TCP/IP and the Bluetooth protocols. That is generally called a Bluetooth Internet gateway (Figure 2) (BIG), which is classified as middleware.
Bluetooth Internet gateway requirements
These days we have the older Bluetooth BR/EDR and the newer Bluetooth LE to choose from (Figure 3). Bluetooth LE can be used in various ways including connection oriented communication and connectionless and also for creating large mesh networks of Bluetooth devices. Therefore, one has to first consider what type of Bluetooth technology needs to be supported.
For this project, Bluetooth LE was used since support for Bluetooth mesh was not the priority and there was no intention to support the older Bluetooth BR/EDR either.
Bluetooth LE devices can work in various ways. Connectionless communication involves a procedure known as advertising where small packets of data are broadcast and received by a device in range (scanning). This mechanism is used for facilitating device discovery. Typically, scanning devices like smartphones find and choose a device with a little help from the user and then establish a connection. After this, communication takes place over the connection. And this is required to be done by the gateway on behalf of a TCP/IP client of some sort.
Connectable devices that advertise are called peripherals. And those that scan and request connections are called central devices.
So, it was decided to support connectable LE devices that act as peripherals with a Bluetooth Internet gateway acting as the central device that would do scanning and connection.
Bluetooth Internet gateway architecture
Adapter components handle requests, which are encoded in TCP/IP
protocols. The Bluetooth LE API helps drive the requested Bluetooth procedures that the Bluetooth stack implements.
It was decided to use Linux on Raspberry Pi as the platform having both TCP/IP and Bluetooth support required for a gateway. It was also decided to use HTTP and WebSockets for the TCP/IP protocols with HTTP requests and responses used for all operations except the delivery of streams of Bluetooth characteristic notifications (which were delivered over a WebSocket).
For HTTP support, the Apache Web Server was chosen as it has a wide collection of modules and the open source websocketd was used for Web socket support. A webcam was also plugged into the gateway to observe remote actions.
The adapter code was written in Python. To integrate the Python script with the Web server in HTTP, the common gateway interface (CGI) was used.
BlueZ is the name of the
Bluetooth stack you will find on Linux. It provides a language-agnostic API, which uses the Linux d-bus service that allows inter-process communication to take place.
Bluetooth Internet gateway implementation
HTTP GET: Requests which do not change the state of remote objects with an HTTP query string used to pass associated parameters.
HTTP PUT: Requests which do change the state of remote objects with JSON objects in the HTTP request body used to encode and transport associated parameters.
RESPONSES: HTTP status and JSON object.
Here’s an example that concerns device discovery (Figure 7).
The above shows a response generated by an adapter script called do_discover_devices.py. It’s invoked using HTTP GET and the scan time parameter is passed into the query string. This indicates how long the gateway should spend performing Bluetooth scanning in milliseconds. The response is an array of objects representing the devices discovered in JSON format.
In this example, HTTP PUT was used (Figure 8) for writing to a Bluetooth characteristic. Here the Bluetooth device address is assigned as the first parameter and identifies the device to interact with.
The handle parameter is a unique identifier for a specific instance of a Bluetooth characteristic, which belongs to a particular Bluetooth service.
Bluetooth Internet gateway security
Anything that allows access to your device over the Internet needs to be secure. A review of the security (Figure 11) of the initial gateway design and implementation identified numerous security issues.
For example, there was no authentication mechanism and therefore no control over who may or may not access the gateway.
The gateway at this stage used three different TCP/IP ports: port 80 for HTTP, 8081 for the webcam streaming service, and 8082 for websocketd.
The more ports exposed directly to the Internet, the greater is the security risk.
Data over TCP/IP is not encrypted at this stage either and nor is data over Bluetooth necessarily.
It was also considered desirable that there be some way to grant access to specific Bluetooth devices only rather than all devices that happened to be in range of the gateway. Further, it would be advantageous to be able to grant access to only specific device capabilities rather than all things that a device can do over Bluetooth.
Reverse proxying
There were three services running on the gateway, each listening to a different port. But the installed IP firewall was configured to only allow port 443 access. The Apache Web Server was set up to act as a reverse proxy and forward port 443 packets to another port directed by the URL patterns (Figure 13). This limited the number of ports exposed to the Internet.
In addition, the concept of a Bluetooth firewall was invented for the project. This allowed control over which Bluetooth devices could be interacted with via the gateway and which of their services, characteristics, and descriptors could be accessed. The configuration file for the Bluetooth firewall is shown in Figure 14.
Bluetooth Internet gateway scalability
Whilst the Bluetooth specifications do not stipulate a limit to the number of concurrent connections that a central device can establish with a peripheral device, there is always a limit in practice, and it can be quite low.
So here are some options if you want to support a large number of devices that are concurrently connected to and controlled by the Bluetooth Internet gateway.
1. Adding multiple adapters: You can add multiple Bluetooth adapters (Figure 16) to your gateway. Some adapters come in the form of USB dongles, so physically that will be easy to implement; some tweaks to your code will be needed but that wouldn’t be hard.
2. Horizontal scaling: This was the approach taken in this project. Multiple instances of gateway services (Figure 17) were run on multiple Raspberry Pi devices and requests distributed across them by a software load balancer. All client requests went to the node running the load balancer.
Using horizontal scaling, in theory, a large number of Raspberry Pi nodes could have been added to the gateway cluster and very-high concurrent Bluetooth device support achieved. The only issue to be aware of here was that there is a load balancer concept known as stickiness. Once a Bluetooth connection has been established from one of the gateway nodes to a particular Bluetooth device, all subsequent requests from the clients that relate to that Bluetooth device must be handled by the same gateway node since it holds the Bluetooth connection.
The HAProxy load balancer has excellent support for stickiness, allowing one to configure the behaviour.