Use case possibilities with Bluetooth low energy in IoT applications

1 Bluetooth low energy technology overview

1.1 General
Bluetooth low energy was introduced back in 2011as the hallmark feature of Bluetooth v4.0. Bluetooth low energy is ideal for applications requiring episodic or periodic transfer of small amounts of data. Therefore, Bluetooth low energy is especially well suited for sensors, actuators and other small devices that require extremely low power consumption. Works well with high numbers of communication nodes with limited latency requirements

• Very low power consumption
• Robustness equal to Classic Bluetooth
• Short wake-up and connection times
• Good smartphone and tablet suppor

1.2 Radio

Figure 1: In the 2.4 GHz band, Bluetooth low energy uses 40 frequency channels instead of the 79 channels used in Classic Bluetooth

Many features of Classic Bluetooth are inherited in Bluetooth low energy, including Adaptive Frequency Hopping (AFH). These inherited features make Bluetooth low energy easy to set up and makes it robust and reliable in
tough environments. To support simpler and cheaper radio chipsets, Bluetooth low energy uses 40 2 MHz wide channels while Classic Bluetooth uses 79 1 MHz channels.

1.3 Difference between dual - mode Bluetooth (Bluetooth Smart Ready) and single-mode Bluetooth low energy (Bluetooth Smart)
Figure 2 shows examples of Bluetooth modules (u-blox) and end products that are either single-mode Bluetooth low energy solutions or dual-mode solutions. In this example, Bluetooth Smart Ready (dual-mode) devices include the dual-mode Bluetooth module OBS421 and smart phones. Bluetooth Smart (single-mode) devices include the Bluetooth low energy module OLS425 and temperature sensors.

Figure 2: Single-mode and dual-mode module and product examples.

Single-mode devices are stand-alone Bluetooth low energy devices (also known as "Bluetooth Smart” devices) that are optimized for small battery-operated devices with low cost and low power consumption in focus. Typical
single-mode devices are, for example, sensors (heart rate sensor, temperature sensors, etc.) or other types of battery-operated accessories.

Dual-mode devices (also known as “Bluetooth Smart Ready” devices) use both Bluetooth low energy and Classic Bluetooth. Typical dual-mode devices are mobile phones, tablets, computers or –in this context– a gateway device.

1.4 Client and Server concept in Bluetooth low energy

Figure 3: The Client / Server concept.

Bluetooth low energy uses a Client / Server model. A Client (that "wants data") connects and accesses one or several Servers (that "has data”). The Client typically operates in the Central role and the Server operates in the Peripheral role. Typically, a sensor or an accessory is the Server / Peripheral and a computer, phone, or tablet is the Client / Central device. In the gateway context, the gateway typically takes on the, Client / Central role.

1.5 "Advertising" is how devices are found in Bluetooth low energy
Since the devices are in sleep-mode until an advertisement is initiated, the advertising feature enables Bluetooth low energy to keep the power consumption to a minimum.

Figure 4: The advertising feature of Bluetooth low energy.

The slave device (now having the Broadcaster role) is "advertising" when he wants to connect. The Client is scanning for new devices (acting in the Observer role). When the Observer finds a device it wants to connect to, it initiates a connection. The advertisement may contain broadcasted data.

1.6 Bluetooth low energy connections

Figure 5: Connected Device.

When connected, the Client / Central controls the communication by sending data and "polling" the Server / Perphral for data at regular intervals (called connection intervals). The selected interval is application dependent and can be speifically set.

1.7 Bluetooth low energy software stack

Figure 6: The Bluetooth low energy software stack

• L2CAP (Logical Link Control and Adaptation Protocol). This is a stack layer responsible for multiplexing data between various higher layer protocols as well as segmentation and reassembly of data packets.
• GAP (Generic Access Protocol) . This profile defines the generic procedures related to device discovery and link management when connecting to Bluetooth devices.
• GATT (Generic Attribute Protocol). Provides profile and service discovery for Bluetooth low energy. The described procedures show how to use the ATT (Attribute Protocol) for service discovery as well as how to read and write attributes (data). Services and profiles are developed on top of GATT.
• 6LoWPAN (IPv6 over Low power Wireless Personal Area Networks). An alternative to GATT is to use TCP/IP based communication with 6LoWPAN. 6LoWPAN technology can be used to compress the IP messages sent over Bluetooth low energy to save on size requirements and power consumption.

 

2 Internet of Things (IoT) overview
With yearly shipments of more than 10 billion microcontrollers that all can exchange information locally or through the Internet, a huge variety of so called “intelligent devices” are enabled. These devices include motion
sensors, pool pumps, gas/electric meters, street lights, and many other types of devices. A ll these devices can be accessed over the Internet thanks to the rapid increase in infrastructure coverage and Internet access. This
evolution is often called the Internet of Things (IoT). Other names include Internet of Everything (IoE), Web of Things, Embedded Web and Industrie 4.0. The goal is to establish an Internet connection for the small "things"
you carry with you or use in a factory, hospital, in a city or in a home. Companies such as Ericsson and Cisco have visions of more than 50 billion connected devices within the next 10 years.

Figure 7: Internet of Things (IoT).

A key requirement in the IoT vision is an easy-to-deploy and cost-efficient low power wireless solution. Connecting all small devices and sensors directly to the fixed or cellular networks would be too costly. An easy-to-deploy,
cost-efficient, and low power solution is a key requirement in IoT. Radio technologies such as Bluetooth, Bluetooth low energy, 802.15.4 / Zigbee or similar may be used to connect widely distributed small devices. The sensor
s are connected to a gateway that in turn is connected to Internet services (see figure 7 above). The gateways can be powerful–typically Linux-based–systems with high computing capacity. The gateways can also be RTOS platform-based when there is a need for small, cost-efficient but still powerful wireless gateways.

3 Use cases for Bluetooth low energy in IoT
Below follows several examples of IoT use cases using Bluetooth low energy. All of the use cases assume the use of a gateway connected to the Internet using TCP/IP related protocols.

3.1 GATT-based device and service / profile-aware gateway

Figure 8: Service / profil-aware gateway.

In this use case, there are devices connected to the gateway implementing one or more GATT-based services. The gateway interprets the service / profile and then exposes an "xxx" Internet API (e.g a RESTful API) or contains an "xxx" application that sends and receives data from the Internet. In this use case, the gateway can be a dedicated fixed device or a portable device.

The use case can be applied in, for instance, connected sensors in a building (home automation or home care), body-worn health or fitness sensors and various metrology or industrial devices.

A portable device (e.g. a smartphone or tablet) may use its "xxx" -aware GATT app to access a Bluetooth low energy device directly or – when the network is connected – use an Internet - aware app to access the "xxx" RESTful API or data originating from the Bluetooth low energy device stored in the cloud service or cloud database.

"The cloud" can be a Wide Area Network (WAN) or a Local Area Network (LAN) such as a LAN within a factory.

3.2 GATT-based device and gateway using the GAP/GATT RESTful API
GAP/GATT RESTful APIs are generic methods used to access GATT-based Bluetooth low energy devices via the Internet. The APIs allow for both reading and writing of data as well as subscribing for indication or notification
events (when the GATT-based service in the Bluetooth low energy device supports indications and notifications).

Figure 9: Gateway using GATT/GAP REST APIs.

In this use case, Bluetooth low energy devices are connected to a gateway with support for the GAP and GATT RESTful APIs. The gateway is completely generic and transparent and does not need to contain information about the "xxx" service / profile.

The use case can be applied in, for instance, connected sensors in a building (home automation or home care), body-worn health or fitness sensors and various metrology or industrial devices.

A network connected portable device (e.g. phone or tablet) app or a cloud service use the GATT RESTful API to access the Bluetooth low energy device data via the gateway. The app or service need to be aware of the apabilities of the "xxx" service / profiles.

A portable device (e.g. a smartphone or tablet) can also use its "xxx" GATT app to access the Bluetooth low energy device directly.

"The cloud" can be a Wide Area Network (WAN) or a Local Area Network (LAN) such as a LAN within a factory. The Bluetooth SIG has developed white papers (see https://www.bluetooth.org/en-us/specification/reference-publications/wh…) describing GAP and GATT RESTful APIs.

3.3 Using an Internet Service
The Internet service is a GATT-based service that resides in the gateway and allows for Bluetooth low energy devices to access the Internet by using standard Internet protocols such as HTTP. The gateway is generic and can
be used by any connected device that has implemented the Internet service client.

Figure 10: Gateway using an Internet service.

In this use case, the gateway has the Internet service implemented. The gateway connected Bluetooth low energy devices typically use the Internet service to write data to and read data from a cloud service, database or similar. For example, if the cloud database or service implements a RESTful API (common approach today) the device may issue an HTTP GET or PUT command to access the service / database data.

This use case is best applicable when the Bluetooth low energy device needs to control the data transfer. A good example is a metering application when the meter pushes its value to an Internet service.

By accessing data stored in the cloud service / database, a network connected portable device (e.g. a smartphone phone or tablet) app or a Web service can also indirectly access the Bluetooth low energy device data.

In this use case, the gateway can be a dedicated fixed device or a portable device e.g. a smartphone assuming that the smartphone runs an application that implements the Internet service (see more on this later in the document).

"The cloud" can be a Wide Area Network (WAN) or a Local Area Network (LAN) such as a LAN within a factory.

3.4 Using the Serial Port Service
The Low Energy Serial Port Service is a custom Bluetooth low energy GATT-based service developed by u-blox. This service offers transparent serial communication between a device with an embedded u-blox Bluetooth low
energy module and the gateway. This gateway in turn offers further connectivity to the Internet / cloud.

Figure 11: Gateway using the u-blox Low Energy Serial Port Service.

In this use case, the gateway uses the u-blox Low Energy Serial Port Service to transparently transfer data from devices to and from the "Internet Connection Software" (see figure above). Several scenarios are possible
including the following:

1. An IP address and port are configured in the gateway and the data received from this port is sent to the device. Data received from the device is the configured IP address and port.
2. An Internet service opens a WebSocket and the transparent data is transferred between the device and the WebSocket.
3. The "Internet Connection Software" assumes that data received from the device is a TCP/IP command (such as an HTTP PUT or GET command). This scenario is similar to the Internet service described in a previous section.

This use case is best suited when the connected devices already have a serial connection and need to send data transparently to an Internet service.

"The cloud" can be a Wide Area Network (WAN) or a Local Area Network (LAN) such as a LAN within a factory.

3.5 IPv6 on Bluetooth low energy transport
For IPv6 support on Bluetooth low energy, one has to deploy the Bluetooth Specification v4.1 or newer and the Bluetooth SIG has just released IPv6 services and profiles. Since IPv6 support requires the use of the 6LoWPAN
protocol, there is an IETF draft (see http://datatracker.ietf.org/doc/draft-ietf-6lowpan-btle/) where the 6LoWPAN protocol is added directly on top of the Bluetooth low energy L2CAP protocol layer. With this implementation,
the 6LowPAN / IPv6 operates in parallel with the GATT profile. With this approach, IPv6 can be used end-to-end from the local Bluetooth low energy device to an Internet service.

Figure 12: Gateway using IPv6 over Bluetooth low energy.

In this use case, there are devices connected to the gateway that implement their applications as Internet applications. Typically CoAP is used as the method to send data to the gateway in order to minimize overhead. The gateway is completely unaware of the application and conversion takes place between CoAP and HTTP. There might also be use cases where HTTP is used all the way down to the device although this will be more resource consuming than CoAP.

This use case is flexible and can be used independently of the connected device type. In particular, this implementation is useful for devices that want to comply with an IP-based standard such as when devices using the Smart Energy 2.0 standard want to use Bluetooth low energy instead of 802.15.4 which is the current standard.

Through IPv6 on Bluetooth low energy, an Internet device (computer, phone or tablet) or cloud service can access the Bluetooth low energy device application transparently via standard Internet functionality e.g. using an HTTP REST API or other IP-based protocols.

Although not the main intention, an application in a portable device can also access the Bluetooth low energy device when connected point-to-point and still fully utilize the Internet functionality.

"The cloud" can be a Wide Area Network (WAN) or a Local Area Network (LAN) such as a LAN within a factory.

3.6 Combined use cases
There can also be local Bluetooth low energy devices that use two or more of the above mentioned use cases in parallel. For example, a Bluetooth low energy device may implement both IPv6 and a GATT-based service or
support the Internet service as a client and at the same time implement a GATT service.

A gateway can support several or even all of the above access methods in parallel.

3.7 The use of a smartphone as gateway

Figure 13: Using a smartphone as a gateway.

In several of the described use cases, a smartphone can act as a gateway and access the cloud through its GSM, 3G, 4G or Wi-Fi connection. The gateway can be a temporary installation such as when an app is running and
accessing a certain Bluetooth low energy accessory. The gateway can also be more or less permanent such as  when the smartphone is connected to a body-worn Bluetooth low energy sensor.

Some use case examples:

• A smartphone connected as a user interface to a Bluetooth low energy device while the phone app simultaneously reads service related data from the device and transfers the data to an Internet service.
• A body-worn health / medical Bluetooth low energy sensor sends data to a phone app and the data is transferred to an hospital connected Internet service.
   

3.8 Extending the covered range with gateways
When using Bluetooth low energy for IoT applications, the range can become a limitation as Bluetooth low energy implements a star topology. Competing technologies using the 2.4 GHz ISM band (e.g. 802.15.4 based technologies) often support meshing and routers to extend the coverage; however, such solutions are currently not possible in Bluetooth low energy.

Figure 14: Example of how to extend the Bluetooth low energy range via gateways.

Figure 15: Gateways as range extenders.

Figure 14 and 15 show a possible solution to extend the wireless range by using interconnected gateways. The upstream link can be a cable (Ethernet) or a wireless link (Wi-Fi or Classic Bluetooth) and the downstream can be
a Bluetooth low energy link. In the examples, Wi-Fi upstream links are used.

Since the upstream connection in all the examples above is based on Internet protocols, the IP protocol contains all the necessary mechanisms to support traffic routing to cloud services and in some cases also between the
local Bluetooth low energy devices (e.g. when IPv6 over Bluetooth low energy is used).

In this scenario the gateway can be a small light-weight gateway consisting of a low-cost, low-power microcontroller (MCU) in combination with a multiradio solution(a radio chip with built-in support for Bluetooth, Bluetooth low energy and Wi-Fi). The gateway will thus be cost-efficient, physically small and consume a minimum of power.

3.9 Security
Security is always of great importance and so also in IoT scenarios. This white paper does not detail the security options; however, as a summary, the three main strategies that would apply are the following:

1. No security. This will only be used in very specific use cases where security is not required.
2. Link layer security between Bluetooth low energy devices as well as Internet security between the gateway and the Internet / cloud service.
3. Internet security end-to-end. This is valid for the IPv6 use case only.