Peripherals

A peripheral device is a device that announces its presence by sending out advertising packets and accepts a connection from another BLE device (the BLE central).

Another related term is a BLE Broadcaster. A broadcaster is a device that sends out advertising packets as well, but with one difference from a peripheral: the broadcaster does not allow a connection from a central device. On the other hand, an observer device only discovers advertising devices, but does not have the capability to initiate a connection with the advertiser.

A typical example of an application that involves a broadcaster is in Beacon technologies. Beacons are devices that have the sole purpose of advertising and broadcasting their existence, while not accepting connections from other devices. They are becoming popular in two main use cases: retail marketing and indoor location services.

The way a Broadcaster is differentiated from a Peripheral device is by the advertising packets that get transmitted by the device. There are different types of advertising packets:

• Some indicate the capability to accept a connection.

• Others are simply for broadcasting presence.

When the BLE central discovers the advertising packets of another BLE device (whether broadcaster or peripheral), it knows whether it can initiate a connection or not based on the type of advertising packets.

Once a peripheral gets connected to a BLE central, it also becomes known as the slave in that connection. The central device, in this case, gets called the master. These are roles defined within the link layer, whereas the peripheral and central roles are defined within the GAP layer.

Centrals

A Central is a device that discovers and listens to other BLE devices that are advertising. It is also capable of establishing a connection to BLE peripherals (usually multiple at the same time).

An Observer, on the other hand, is a similar type of BLE device, but one that is not capable of initiating a connection with a peripheral device.

Power Consumption and Processing Power Considerations

BLE is asymmetrical by design. Much of the heavy lifting regarding connection management, time management, and processing responsibilities lies on the central side. This helps reduce power consumption and processing power requirements on the peripheral side, thus, making it possible to integrate BLE into smaller and more resource-constrained devices (e.g., battery-powered devices).

A BLE central device can still be battery powered, but will usually have a relatively large battery thatʼs rechargeable. Most commonly, in a BLE system, the central device is a smartphone, tablet, or a computer.

A central device also supports connecting to multiple Peripherals at the same time. A typical example of this is a smartphone that maintains a connection to a smartwatch, a smart-home thermostat, and a fitness tracker, all at the same time.

Multi-Role BLE Devices

In some use cases, a BLE device would benefit from acting in multiple roles simultaneously. For example, a device may want to monitor multiple sensors (peripheral devices), and at the same time be able to advertise its presence to a smartphone to allow access to sensor data from a mobile app interface.

The Role of Smartphones in BLE

One of the biggest advantages of BLE over other competing low-power wireless technologies (such as ZigBee, Z-Wave, Thread, etc.) is its existence in the majority of smartphones in the market. Most smartphones already included Bluetooth Classic since the very early days, and most Bluetooth chipset vendors are now integrating BLE support along with Bluetooth Classic in their chipsets. The result is that the vast majority of smartphones nowadays support BLE.

Having the capability for a smartphone to interact and connect to BLE devices provides a couple of significant advantages:

• Smartphones provide a familiar user interface for consumers, offering a rich user experience when using a mobile app to interface with a BLE device (compared to interfacing with the BLE device directly).

• Smartphones are usually connected to the Internet. This means that the data transmitted from the BLE device can be sent up to the cloud and stored somewhere else for later access or analysis.

Challenges with BLE Development on Smartphones

There are two major mobile operating systems: Android and iOS. Android introduced native support for BLE APIs in Android 4.3 (released July 2012), while iOS provided native BLE support a bit earlier in iOS 5 (released October 2011).

One important thing to note is that this also depends on the hardware running the operating system. For iOS, this included all iOS devices starting with the iPhone 4s.

For Android, it is a completely different story: Android runs on devices manufactured by many different vendors, so there is no easy way to determine which devices first started supporting BLE. This Android fragmentation problem introduces a big challenge with developing Android BLE applications that behave consistently across the dozens of existing Android phones.