Bluetooth for Internet of Things


With the increasingly rapid development of various communication technologies, more and more devices are able to access the internet and to interact with it. When considering a global network of smart objects of all kinds, such as comput­ers, appliances, clothes, sensors, interacting with each other through Internet protocols, the reference scenario is called Inter­net of Things (IoT). The devices that are part of the network of objects are called ‘‘smart objects’’ or ‘‘smart things’’, that unlike normal devices are able to interact within the communication system in which they are inserted since they have an active role. The devices can be identified by the following characteristics:

Thanks to the developments of wireless technologies and to studies about IoT, the ‘‘anywhere, any-time by anything’’ communication is no longer considered a true utopia. In fact, more and more devices, at any-time, even without receiving a physical input, can access the network and interact with the other connected devices. The practical significance of the IoT is made possible through enabling technologies such as Wireless Sensor Networks (WSNs), mainly used for sensing operations. The nodes of a WSN are sensors arranged within an environment, with the aim to detect certain data that are send to one central node in order to process them.
With the introduction of the IoT, the research and the implementation of home automation are getting more popular. In fact, built on connections between digital devices and nearly anything that can be monitored or controlled electronically, the IoT holds promise for making homes smarter. Home Automation (HA) refers to the mechanization and automatic control of various residential activities. Typically, HA provides a centralized control of electrical appliances, such as air conditioners, lighting and security systems and even the home theater. Adding intelligence to home environment it would be possible to obtain excellent levels of comfort, and another feature taken into account is the energy savings. Moreover, the integration of several electrical devices in the household is an open challenge because of the absence of a cheap and standardized commu­nication protocol between them. Anyhow, at present, a wireless network exists in almost all homes. Smart-phones and tablets are natural devices to enable the control of electrical ones. In such a situation, the wireless protocols become an easy avenue for self-installation of HA systems. Moreover, a smart home has to meet several requirements such as:

Several wireless technologies, such as Bluetooth Low Energy (BLE), IEEE 802.15.4/ZigBeeand IEEE 802.11/Wi-Fi, that can support the remote data transfer, the sensing and the control, have been proposed in order to embed various levels of intelligence for smart home. BLE is being adopted by the health care industry for portable medical and lifestyle devices. On the other hand, the battle between ZigBee and low-power Wi-Fi technologies for home control and automation has just begun. The manufacturers of wireless devices are urgently looking for new revenue streams, and machine-to-machine com­munication and location-based services seem to be good places to make a bet. Both can use existing infrastructure and are very much a part of the emerging IoT market.
Anyhow, there is a main requirement that make a wireless protocol ideal for use in the IoT, that is the energy efficiency. In many cases, the sensing nodes are battery-powered, so a low-power feature is a basic requirement. In the design of devices that implement a wireless protocol several mechanism can be adopted in order to reduce the power consumption, including low-leakage process technologies, best-in-class low-power non-volatile memory/flash memory technologies, architectural innovations and various clocking schemes. For battery-powered nodes, all of those techniques are needed in order to achieve the lowest possible power consumption.

To cope with this problem, this paper proposes a fuzzy logic based mechanism in a home automation environment. The core of the proposed architecture is represented by a wireless network, organized in Wireless Automation Cells (WACs), based on Bluetooth Low Energy Protocol and managed by a Master node. The Bluetooth Low Energy protocol has been chosen from the results of an analysis carried out in the Section Wireless protocols comparison of this paper. In each WAC there is a fuzzy module that aims at the energy saving of the network. In fact, the goal is to improve the low energy consumption of BLE through a fuzzy logic controller.

Bluetooth Low Energy support for IoT in home automation

In this section an analysis of wireless communication suitable for energy management in home automation applications is presented. In recent years, wireless communication technology has seen sudden growth and several approaches are also capable to support the energy management through widespread environmental sensing. This has been possible through the advancements of low-power and low-cost radio frequency wireless communication technologies, with smaller form factor, greater sensing density and longer functionalities lifetime.

In the IEEE 802.11/Wi-Fi family, the nodes compete for the medium access according to the Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) protocol. However, contention-based approaches are not able to guarantee an upper bound on the medium access delay, so they are not adequate for time-constrained traffic and for applications that require low power consumption. In fact, Wi-Fi does not possess intrinsically ubiquitous characteristics, but the explosion of laptops and mobile devices has driven widespread adoption. However, in the field of energy management this adoption seems unli¬kely. In fact, the native design of Wi-Fi does not have the energy management in mind and for many applications, particu¬larly environmental sensing, the IEEE 802.11 is considered too power hungry and in some cases the components are still too large. For this reason, other approaches have been developed.

ZigBee, a pure wireless technology, is based upon the IEEE 802.15.4 standard for WPANs (Wireless Personal Area Net¬works). It is intended to be a low-cost, low-power wireless mesh network standard allowing for secure communication with a data rate of up to 250 kbps. ZigBee was originally conceived as an alternative to Wi-Fi/Bluetooth Classic around 1998 as a solution for self-organizing ad hoc digital networks. ZigBee-based HA solutions operate in the 2.4 GHz range and have a range of 70 m indoors and up to 400 m outdoors. The networks are self organizing, and any member can be the controlling node. There are plenty of ZigBee home automation solutions already available in the market and also in the literature appli¬cations in industrial contexts have been proposed. Technologies such as Bluetooth Low Energy (BLE) came up in part due to the unsuitability of Wi-Fi, ZigBee and other such technologies in order to provide networking with low power consumption, low cost, simplicity and the ability to remain in a suspended state for extended periods of time. Most of the HA technologies have been developed when Bluetooth Classic was unable to satisfy all of these criteria. However, over the last few years, thanks to the new specifications of Blue¬tooth 4.0, the BLE has slowly, but surely, gained a significant foothold in the home automation industry. The rise of BLE’s role in home automation has primarily come about due to two factors.

Bluetooth Low Energy protocol

Classic Bluetooth is used for short range wireless communication among devices in networks where nodes can easily come and go. It uses 79 channels with a bandwidth of 1 MHz on the 2.4 GHz ISM band with a pseudo-random frequency hopping sequence. In a Piconet each Master device establishes the frequency hopping sequence and can have up to 7 Slave connections. A device can be in more than a single Piconet and overlapping Piconets are Scatternets. However, in the literature, several optimization approaches have been proposed in order to improve Classic Bluetooth, especially to make it usable even in industrial context.

Bluetooth 4.0, or BLE, implements an entirely new protocol stack along with new profiles and applications. Its core objec¬tive is to run for a very long time on a coin-cell battery. It also enables devices to connect to the internet, where traditionally they have not been able to, in an efficient way through its client/server architecture. BLE is designed to be easy to develop for at a cheap price.

Bluetooth Low Energy operates in the 2.4 GHz ISM band with only 40 channels spaced 2 MHz apart (Fig. 1). It is capable of transmitting at a rate of 1Mbit/s using GFSK modulation. Like Bluetooth Classic, it uses frequency hopping, but it uses adap-tive frequency hopping and at a slower rate. BLE uses 3 of the 40 channels to advertise which allow for device discovery. After a device is discovered and connected the remaining 37 channels are used to transmit data.

There are 4 basic modes through which a BLE device can operate, that are master device mode, slave device mode, adver¬tising mode, and scanning mode. The advertising mode is used by the device to periodically advertise information that can be used to establish a link. It can also use this mode in order to respond to additional queries that another device might make. The scanning mode is used to capture advertise packets. Slave and Master Modes are used once a link has been established between 2 devices, and their primary functions are to allow the devices to read, to write and to query each other. The device that starts out in advertise mode will assume the slave device mode and conversely the device that is initially scanning mode will assume the master device mode.

Regarding to the packet format, there are 2 types of packets, Data and Advertise, each with variable lengths (Fig. 2). BLE Data packets consist of an 8 bit preamble, 32 bit access codes that are defined by the radio frequency channel used, a variable protocol data unit (PDU) ranging from 2 to 39 bytes and a 24 bit CRC. This means that the shortest packet can be as small as 80 bits or as long as 376 bits. It also means that a transmission time can range from 80 ps to 0.3 ms. Advertise packets on the other hand, have protocol data unit containing a 16 bit header and up to 31 bytes of data.

There are three ways through which two devices can associate, Just Works, Out of Band, and Passkey Entry. An advertising device transmits packets on the advertise channels with a PDU containing the device address and up to 31 bytes of additional information. A scanning device is able to see the address and depending on the advertiser, additional information may be sent upon request. This means that a good amount of information can be obtained about the device without even establish¬ing a connection.

1Bluetooth Low Energy radio links: channels in green are used for advertising. (For interpretation of the references to colour in this figure legend, the reader is refered to the web version of this article.) Figure 1

Bluetooth Low Energy data packet format Figure 2

Advertising is done sequentially on all available channels at a rate from 20 ms to every 10 s depending on configuration. On the other hand a scanner device is configured with a scan window and a scan interval. Once a connection is made, the scanner will supply the advertiser with 2 critical pieces of information, that are the connection interval and the slave latency. The connection interval is used to determine the start time of connection events. A connection event is the exchange sequence of data packets. The other parameter, the slave latency, is the amount of connection intervals that a slave can ignore without losing the connection. This is done in order to optimize the power consumption. After a link is established the communication is carried out over the 37 channels. The PDU’s have up to 37 bytes of payload, along with a packet header, and a Message Integrity Check of 4 bytes. A communication event is initiated by a Master device, alternating between mas- ter/slave until one of them stops the transmission.

The BLE protocol stack (Fig. 3) is partitioned into a Controller and a Host. The Controller handles the lower layers of the stack responsible for capturing physical packets and the radio frequency used by the radio. The Host handles the upper layers of the stack that include the application, the attribute protocol, and the L2CAP. The Host and Controller can be either collo¬cated or the Host can run in the application processor with the application. In the second option, a host Controller Interface (HCI) is used by the Controller and the Host to communicate. The BLE protocol stack consists of:

Regarding to the power consumption, it is necessary to note that Bluetooth 4.0 achieves an increased power efficiency. First, it uses a lower duty cycle, this means it goes to sleep for longer periods of time and wakes up less frequently to send or receive packets. Second, using the GATT profiles BLE is able to send smaller data packets in short bursts in order to save power. The data transmission can be triggered by a local event and is available for a client to access at any time. Lastly, BLE does not maintain links with devices whenever are not communicating. Whereby, the device goes to sleep and ends the link once the exchange is complete. A link is re-established rapidly upon the next communication exchange. The transmit time of Bluetooth Classic is 100 ms whereas that of BLE is 3 ms. Moreover, the current consumption peak of BLE is 10 mA less than Bluetooth Classic and in best case scenarios has a power consumption that is 1/100th than that of Bluetooth Classic.

BLE 4.0 is not designed to stream large amounts of data; it is designed to periodically send short bursts of data. There are 2 types of BLE 4.0 devices, dual mode which is backwards compatible with previous BT versions, and single mode which only supports BLE 4.0. Dual mode devices that perform high data rate streaming do not benefit from the low power consumption of BLE 4.0, which is only accomplished when BLE low data rate mode is used.