Ble bluetooth low energy. Bluetooth Low Energy(BLE) in a Nutshell

Introduction to Bluetooth Low Energy / Bluetooth 5

In this lesson we will take a look at the Bluetooth Low Energy (BLE) protocol, its versions and architecture. The key information needed to get started with BLE on an nRF5x chip is provided per each layer of the architecture. We will also understand the main differences between Bluetooth Low Energy and Bluetooth Classic. Gaining fundamental knowledge about the BLE architecture will pay off, and will significantly help when we reach Lesson 4, and start diving into Nordic Semiconductor BLE Protocol Stack (SoftDevice) API. In the exercise section of this lesson, you will be introduced to the general structure of a connection-orinted BLE firmware, and the minimum nRF5 SDK modules needed to make a BLE device discoverable and connectable.

Bluetooth Low Energy vs Bluetooth Classic

Before we examine the BLE architecture, we will first compare it to Bluetooth Classic. Bluetooth Low Energy, which was initially advertised as “Bluetooth Smart”, is a light-weight independent branch of the original “now known as Classic Bluetooth ” and was introduced as part of the Bluetooth 4.0 core specification in 2010. It is a wireless communication standard for short range, ultra-low-power personal area network operated in the unlicensed 2.4 GHz ISM Band. The figure below shows the timeline of BLE and Bluetooth Classic, highlighting its major releases and main features introduced in each release. As can be seen from the figure below, prior to 2010, there was only one main type of Bluetooth, after 2010 we have BLE and Bluetooth Classic.

When people talk about Bluetooth nowadays, there are two main types. The first type is the Classic, which could be Bluetooth Basic Rate (BR), Enhanced Data Rate(EDR) or the High Speed (HS). The Bluetooth Classic is intended for short-range communication with a relatively higher throughput than BLE. This type of Bluetooth is still used in our cars, Bluetooth-enabled headsets, speakers and Smart printers to transfer files. This type of Bluetooth has no regard to power consumption. You typically can not efficiently operate a Bluetooth Classic device on a coin cell battery.

The second type is Bluetooth Low Energy (BLE), which emerged along with the Bluetooth specification 4.0 in 2010. BLE is a massive divergence from the Bluetooth Classic. BLE is not compatible with the Bluetooth Classic. It is different hardware, different architecture, different specification, and hence different target applications. BLE is intended for Ultra-Low-Power (ULP) low-bandwidth applications, like the IoT. The key features of the BLE protocol:

• Ultra-Low-Power(Coin-cell battery 1 year).
• Small packets size(244 Bytes payload max).
• Short receive (RX) and transmit TX Windows.
• Race to idle:

• Turn radio on as seldom as possible.
• Turn radio off as soon as possible.

Below are the architecture block diagrams for both Bluetooth Classic and Bluetooth Low Energy. We will only FOCUS on the architecture of BLE:

One important consideration to keep in mind is that a device could support one of these two types of Bluetooth or both. In the case of both the device is known as Smart Ready and it would contain both hardware for Classic and for BLE. Most modern Smart phones, workstations, and laptops have Bluetooth connectivity chips which support both Classic and Low Energy(Smart Ready). These chips are more commonly known as Dual-mode Bluetooth chips.

On the other hand, all Nordic nRF5x SoCs only support BLE. They do not support the Bluetooth Classic, and hence they are not Dual-mode Bluetooth chips. Nordic nRF5x SoCs are customized and tailored to ultra-low-power applications.

There are a number of short-range low power wireless protocols like ZigBee, and Z-Wave out there for engineers and product designers, but what makes BLE interesting is that, unlike the others, it’s natively supported in almost all smartphones and popular OS’s.

Bluetooth Low Energy Architecture

The BLE architecture is split into three main building blocks outlined below. We will examine each of these blocks individually starting from the bottom. The key essential information about each layer to get stared with BLE on an nRF5x chip is provided.

• Application: User application interfacing with the BLE protocol stack. Most of the time, this is the firmware of the nRF5x chip, that we will write as developers tailoring the exact needs and constrains of the product being designed. This is pure software, part of this code will be imported from the nRF5 SDK.
• Host: Upper layers of the BLE protocol stack. Usually we rely on a manufacturer library to interact with this layer. In our case of the nRF5x, it is the SoftDevice protocol stack. SoftDevice is covered in-depth in Lesson 4.
• Controller: Lower layer of the BLE protocol stack, including the radio. Seldomly we directly interact with this layer, instead the SoftDevice interact with the controller on our behalf. Most of this layer is implemented in hardware, the remaining part is implemented by the SoftDevice.

Controller

Physical Layer (PHY) : The physical layer(aka PHY) is responsible for the RF modulation and demodulation. The RF is operated in the 2.4 GHz ISM unlicensed Band, which is shared with several other popular wireless protocols like Wi-Fi and Classic Bluetooth. It contains the analog communications circuitry responsible for translation of digital data over the air. It is the lowest layer of the protocol stack, and provides its services to the Link Layer. The communication spectrum is divided into 40 RF channels on 2 MHz spacing from 2.4000 GHz to 2.4835 GHz, starting at 2402 MHz. It’s worth noting that channels 37, 38, and 39 are called advertisement channels. while the remaining channels are called data channels. Advertisement channels are used for: device discovery, during connection establishment, and for broadcasting. While the data channels are used for: bidirectional communication between connected devices, advertisement extensions (BLE 5 onward only). BLE uses a Frequency hopping scheme. This is intended to reduce interference of neighboring 2.4GHz based devices ( Like other Bluetooth-enabled devices, or even Wi-Fi devices), the scheme determines which channel should be used next for the next connection event(covered next), among the 37 data channels.

The nRF Connect – RSSI Viewer app will help us monitor these channels and estimate surrounding 2.4GHz interference. The app shows the Received Signal Strength Indicator(RSSI) in decibel-milliwatts (dBm) per channel in the 2.4000 GHz to 2.4835 GHz BLE bandwidth.

One important note to keep in mind is that depending on which nRF5x chip you are using, there could be up to three different types of physical layers(PHYS) available on the same chip die (As covered previously in the Foundation Level of this course). These PHYs are listed below :

• BLE_GAP_PHY_1MBPS. The standard BLE 4.x physical layer capable of a theoretical 1Mbps data rate. Available in all nRF5x devices(Both nRF51 and nRF52).
• BLE_GAP_PHY_2MBPS. The high speed physical layer capable of a theoretical 2Mbps data rate. Added in BLE specification 5 and available in all nRF52 devices only.
• BLE_GAP_PHY_CODED. The coded ( aka: Long Range, aka: full house coverage) physical layer which is capable of either a theoretical 500Kbps or a theoretical 125Kbps data rate. With this physical layer, BLE range is extended up to 1Kilomete line-of-sight. See this demo YouTube video by Nordic Semiconductor, where two nRF52840 DK communicate with each other using the coded PHY over a relatively long distance. This PHY is available in some nRF52 devices like the nRF52840. nRF52833, nRF52820, and the nRF52811. It uses a special encoding technique to encode the transmitted data called Forward Error-correcting Codes (FEC). and hence the name. With FEC, each bit is now either sent by the radio as two bits (S=2) or eight (S=8). This effectively increases the range by x4, of course, this is on the expense of the data rate.

Regardless of the PHY type, the transmitted power by the PHY radio on an nRF5x chip is configurable through the SoftDevice API. We will set the value of the transmitted power based on the needs of the application and use cases. The transmitted power have a significant impact on the device range. The allowable values are between.40dBm to 4dBm (8dBm exclusively in the case of nRF52840, nRF52833, and nRF52820). dBm stands for decibel-milliwatts, which references 1mw at 0dB. Therefore, a 0dBm means that the transmit power is 1mw, 4dBm = 2.5mw. while.40dBm = 0.0001 mw and so on.

Link Layer(LL) : This is the layer that interface directly with the physical layer. Most of this layer is implemented in hardware as it deals with the real-time requirements of the BLE specifications. The remaining part of this layer is implemented by the SoftDevice. The link layer is responsible for several core tasks:

• Advertising, scanning, and creating/maintaining connections.
• Encapsulating the date received from the uppers layers and generating BLE packets that are passed bit by bit to the PHY.
• BLE packets error-detecting(CRC).
• Optional Encryption/Decryption of the communication. The cipher algorithem used in BLE is AES-CCM 128-bits.
• BLE device address management.
• Defines the role and state of the device.

• Advertiser: A device sending advertisement packets.
• Scanner: A device scanning for advertisement packets.
• Master: A device which initiate a connection and manage it.
• Slave: A device that accepts a connection request and follows the master’s timing.

A device Link Layer(LL) role could change during various stages of discovery/connection(This is controlled through the GAP upper layer as we will see in-details in the next lesson). For example, Device X might start in a Scanner role indicating its interest to connect to a neighboring Device Y. Once Device Y advertisement is picked, handshaking(simplified in the diagram below) is performed and the Scanner becomes the Master and the Advertiser becomes the Slave.

Note that an nRF5x SoC can be configured to be in multi-role configuration as we will see in Lesson9.

BLE Discovery Phase

In the discovery phase of a BLE connection or when the devices are set to be only advertiser/scanner pairs. Every time a device advertises, it send the same advertisement packet in each of the three advertising channels(37,38, and 39). The advertiser does not sends these packets continuously. This goes along with the BLE philosophy of “Turn radio on as seldom as possible”. Instead, it sends its advertisement in intervals. This interval is called the Advertiser Advertising Interval. We will configure this parameter using the SoftDevice API to fit the application needs. Typical values for the nRF5x SoCs are between 20 millisecond ( high power consumption, better user experience) to 10.24 seconds ( low power consumption, high possibility of bad user experience).

On the scanner device side; which in most cases is a mobile device, a tablet or a host machine; the scanner does not scan continuously, again, this is in sync with the BLE philosophy of “Turn radio on as seldom as possible”. Instead, it scans for advertisements in intervals. This interval is called Scanner Scan Interval. During this interval, scanning will be active only in a portion of it. This portion is called the Scanner Scan Window. Both the Scanner Scan Interval and the Scanner Scan Window are to some extent configurable through the underlying library or OS. For instance, Android offers three out-of-the-box different schemes for scanning. each one varies in the Scanner Scan Interval and the Scanner Scan Window.

From the screenshot above of the source code of the Android Scanner Manager. We can see that for the SCAN_MODE_LOW_POWER, the scan window is 512ms while the scan interval is 5.12 seconds.

In few cases, the scanner side could also be an nRF5x chip(As we will cover in-depth in Lesson 11 ), for example two nRF52840 DK boards. one will act as a scanner, and the other will act as an advertiser in the discovery phase of the connection. In such case, both the advertiser and scanner parameters are set through the SoftDevice stack protocol. In general, if we have a scan window equals to the scan interval, then the radio will be ON about 100% of the scan time( Very high power consumption). There will be a short period of a few hundred microseconds (For SoftDevice internal handling) after each scan interval where it will hop frequency to the next advertisement channel(37, 38, and 39) during this transition period, the scanner can not receive any advertisement packet.

The scan window and scan interval must be set in great consideration to the power consumption requirements of the application. The figure below illustrates these important parameters on both the scanner and advertiser sides.

Note: The Scanner and the Advertiser are two different devices that are not synchronized together. To increase the chance that the scanner will pick the advertiser signal, the Scanner Scan Interval must be at least the double of the Advertiser Advertising Interval.

BLE Connection Phase

Once a Scanner (Ex: Device X) has collected sufficient information about a connectable Advertiser of interest, it initiates a BLE connection process. The Scanner will be the Master(Link Layer Master) of the connection and the Advertiser will be the Slave of the connection(Link Layer Slave). The Slave can negotiate the following parameters related to the BLE connection with the Master:

• Connection interval: This is the time between two consecutive connection events. Typical values are between 7.5 millisecond (High data throughput, High power consumption ) to 4 seconds (Low data throughput, low power consumption).A Connection event is the time when the devises exchange data. On a connection event, both devices are transmitting and receiving data sequentially. Each connection event starts with the master transmitting and the slave receiving. Then the opposite, the slave transmits and the master receives. This periodic exchange of data happens regardless of whether the master or the slave has any useful data(user data) to send to the other end. This exchange happens periodically to maintain the status of the connection.
• Number of BLE packets per connection event: How many BLE packets are sent per connection event. This highly depends on the Library/OS used (Android, iOS, SoftDevice, etc.), and the underlying BLE hardware. For Nordic Semiconductor BLE stack (SoftDevie) it is up to 6, however, the connection master have the final word on this. The master always has the final word on all negotiable parameters.
• Slave Latency: The number of connection events that a slave can chose to skip without the risk of losing the connection. Slave latency allows a slave device to skip connection events if it does not have any useful data to send. This can help reduce power consumption on the slave side only(On the expense of lower slave responsiveness). Typical values are between 0 and 499. The slave latency must still be quicker than the Supervision Timeout covered next.
• Supervision Timeout: Length of time the master will wait for a response from the slave before the connection is marked for termination. Typical values are between 100 millisecond and 32 seconds. Supervision Timeout, of course, has direct relation with the Connection interval and Slave Latency, it should ≥ (2Connection interval (Slave Latency 1)) and 32 seconds.
• Data-Packet Length: This depends on the version of BLE used. See this figure for the comparison between the data packet length for the different BLE versions.

We will practice connection parameters negotiation with the help of the Connection Parameters Negotiation library in Lesson 3 – Exercise 1, where we will specify a range of acceptable connection interval value, when to invoke the negotiation process, how many attempts, in addition to specifying what to do when the negotiation fail/succeed.

These parameters heavily impact the throughput of a BLE connection and the power consumption as illustrated below.

Effect of connection parameters on throughput:

Effect of connection parameters on power consumption:

As for the power consumption, the following figures shows the massive effect of the Connection Interval on the nRF5 SoC overall power consumption as calculated statically using the Nordic Semiconductor Online Power Profiler. Play with the other parameters to see their effect on the total power consumption.

We will configure all of these parameters through Nordic Semiconductor BLE protocol stack (SoftDevice) on the Advertiser/Slave side, and the Scanner/Master side through the appropriate software API.

BLE packets:

The BLE packets generated by the LL has only one structure and fall under two types : Advertisement packet or Data packet.

Advertisement packets size:

• For BLE 4.0 : 31 byte payload plus optional additional 31 bytes in scan response.
• For BLE 5.0 and above: 255 byte payload through advertisement extension.
• For BLE 4.0: 27 byte payload. Only 20 available for the user data.
• For BLE 4.2 and above: 251 byte payload. Only 244 available for the user data.

The Preamble is used to lock the PLL of the receiver with the PLL of the sender. In other words. it tries to align the transmit and receive Windows on the two connected devices. The Access Address is mainly used to identify a connection. Examine the Data packet content, there is no MAC address sent(neither for the master nor for the slave). The only way to distinguish a connection from another is through the Access Address. The Access Address is randomly generated per BLE connection. This ensure that two connections happening on the same data channels have a very low probability to collide(1/2^32). On the other hand, in Advertisement packets, the Access Address is simply set to the fixed value of 0x8E89BED6. We will examine the Advertisement PDU(Protocol Data Unit) and data PDU in-depth in the upcoming lessons. As for the CRC (Cyclic Redundancy Check), it enables the receiver to detect if there were an error in the received packets over the air. Basically, It provides data integrity check in the Link Layer.

Host Controller Interface(HCI) : The HCI layer is a thin layer which transports commands and events between the host and controller layers of the BLE protocol stack. The HCI is implemented through a transport protocol such as SPI or UART. This can be utilized for dual-chip implementation, where the host and application runs on another platform. The nRF5x chip. in this case, acts purely as a controller. This style is followed by the zephyr RTOS by the Linux Foundation. In our course, we follow a single-chip implementation approach where the hostcontroller (implemented by the SoftDevice/hardware) application are all implemented on a single chip (nRF5x chip).

Host

Logical Link Control and Adaptation Layer Protocol (L2CAP) : The L2CAP provides multiplexing for the higher layers. This enables protocols like the Attribute Protocol (ATT) and the Security Manager Protocol (SMP) to share the same BLE Controller(Link Layer and PHY). This layer is also responsible for segmentation, and reassembly operation for packets exchanged between the upper layers and the BLE Controller. Through the segmentation/reassemble feature. the L2CAP allows higher-level protocols and applications to transmit and receive upper layer data packets (L2CAP service data units, SDU) up to 64KB long.

Security Manager Protocol(SMP) : responsible for enabling security for applications running over BLE. It provides the following types of services:

• Device Authentication.
• Device Authorization.
• Device privacy.
• Data Integrity.
• Data Confidentiality.
• Data privacy.

Attribute Protocol (ATT): We rarely interact with this layer directly, instead we use the structured and abstracted GATT (covered next and thoroughly in Lesson 2 ). ATT is a simple client/server protocol based on attributes presented by a device. It defines how to transfer a unit of data (attribute). Usually, a client requests data from a server, and the server then sends data to the client. A server can also initiate a data transfer using what is known as indication and notification. Each ATT server contains data organized in the form of a flat table of attributes. An Attribute is the basic unit of data in both ATT, and hence GATT. It is a pretty much a key-values pair, similar to Python dictionaries, and associative arrays in C.

An Attribute has four components (aka fields) :

• Handle: This is the key of the attribute that we can address the attribute with. It is a 16-bit value (0x0001 – 0xFFFF) assigned by the SoftDevice to an attribute to uniquely identify it among other attributes in the table.
• UUID: A Universally Unique Identifier, this is used to specify the type of the attribute. The UUID is either a standard Bluetooth UUID ( 16 bits, aka BLE_UUID_TYPE_BLE ) or a vendor-specific UUID (128 bits, aka BLE_UUID_TYPE_VENDOR_BEGIN ).
• Permissions: As the name implies, this field dictates the access permissions and the security level of the attribute. This enables fine-grained security enforcement.
• Value: The actual data content of the attribute.

The following two layers GATT(Data) and GAP(Control) are the layers we interact the most in the Bluetooth Low Energy stack(SoftDevice), as they provide thorough abstraction for the underlying layers. They are the FOCUS of the next lesson, however, a brief introduction is provided here.

Generic Attribute Profile (GATT): This is one of the most frequently interacted with layer of the BLE stack. It further simplifies the process of exchanging data over a BLE connection. It is implemented on top of the ATT and uses it as its transport layer. Attributes in GATT are no longer laid out flat, instead they are now organized hierarchically as follows.

• Service: Group of characteristics.
• Characteristic: The actual data containers. Ex: heart rate value.
• Descriptor: Additional optional metadata of the characteristic. Ex: the unit of the characteristic (Beats per minute).

In other words, each service contains one or more characteristics, and each characteristic is a union of user data along with descriptive information(metadata).

We will study GATT. including services, characteristics, and descriptors in-depth in the next lesson.

Generic Access Profile (GAP): This layer defines procedures on how devices discover and connect. It also provides an upper simplified layer to the SMP for pairing. creating bonds and ensuring privacy. Through this layer we can configure the link layer to define different device roles as we will see in-depth in the following lesson :

• Peripheral (Link Layer Slave).
• Central (Link Layer Master).
• Broadcaster(Link Layer Advertiser).
• Observer (Link Layer Scanner).

Note that these roles rely on the LL roles covered previously, but they are not the same. In general, a GAP role is fixed in the design stage of the device and it imposes the other end to be in a complement pair(Broadcaster/ Observer or Central/Peripheral) to be able to communicate.

Lesson 1 – Exercises

Enroll to the Intermediate course to access full content.

Bluetooth Low Energy(BLE) in a Nutshell

BLE stands for Bluetooth Low Energy. It is a wireless communication protocol which operates over 2.4 GHz frequency Band. Bluetooth version 3 and below are called as Bluetooth Classic whereas Bluetooth 4.0 and above are classified as BLE (or Bluetooth Smart). The range of a BLE device is up to 400m( for BLE 5.0) and up to 100m(for BLE 4.0). Power consumption also varies widely. It depends on the implementation of the application, the different BLE parameters, and the chip-set used. The peak current consumption of a BLE chip-set during radio transmission is typically under 15 mA.

Communication options in BLE

There are 3 main communication options when it comes to BLE namely point-to-point communication(1:1) which is a connection oriented communication, Data broadcast( 1 to many) which is a connection-less oriented communication and the final type BLE Mesh (many to many) which is also an connection-less oriented communication.

• Point-to-point(1:1)-this is the most commonly used method, it is used in applications like fitness monitors Smart watches toys or even PC peripherals like bluetooth keyboard and bluetooth mouse. Two important terms in this type of communication are BLE Central and BLE peripheral.BLE Central is usually a device with a relatively high computational memory and power capabilities, For example PC tablet or smartphone. BLE peripheral is usually a device with a relatively low computational, memory and power capabilities example heart rate monitor strap, delete mouse. bike speed monitoring device.
• Data broadcast-in this type of communication once a device broadcast its data to all the neighboring devices in the RF range. This type of communication is broadly used in in indoor navigation ,way-finding and BLE beacon.
• BLE Mesh-this configuration enables the creation of complex large scale device networks and is literally suited for monitoring control and automation systems by tens and hundreds of devices need to reliably and security communicate with each other. BLE mesh increases the total coverage area and it also helps in avoiding building and physical obstacles.

The Generic Access Profile (GAP)

It provides a full standard framework for controlling a BLE device in the Point-to-Point(1:1) and Data Broadcast(1:Many) communication methods. It defines how BLE devices can discover and connect with one another and how they can establish security including privacy over the connection. It also details how devices can be broadcasters and observers and transfer data without being in a connection state(Data Broadcast). In addition to that, GAP sets the address of the device as per the design privacy constraints.

GATT (Generic Attribute Profile)

GATT is responsible for the data exchange in the connection-oriented method of communication of BLE. It defines two device roles(GATT Server and GATT Client), which a BLE device can choose to implement either or both at the same time. GATT Server is usually implemented on the embedded device side. The server implements the attributes table structured in the form of Services and Characteristics. In other words, it holds the useful data to be accessed by a remote client. A GATT server contains one or more GATT services. A service encapsulates zero or more functionally-related user data containers called characteristics. For example the Heart Rate Service can have two characteristics: the Heart Rate Measurement and the Body Sensor Location. The Heart Rate service is part of the Heart Rate Sensor GATT Server, which contain other services.

• Profile– It enable interoperability between products from different vendors. The software has to provide a predefined set of capabilities and data access points to conform to the profile, and this guarantees that the device can operate with another one that supports the same profile. over, every operation or data representation is described using the ATT Protocol attributes and methods, and this consistency allows part of the software to be reused and minimize memory footprint and development effort, while at the same time improving software maintenance. Typical device use cases are standardized into profiles. For instance, a common BLE profile is the Human Interface Device (HID) Profile, which is widely used by devices such as mice and keyboards.
• Service– A service is a grouping of one or more attributes, some of which are characteristics. Itʼsmeant to group together related attributes that satisfy a specific functionality on the server.For example, the SIG-adopted battery service contains one characteristic called the battery level.
• Characteristics– A characteristic is always part of a service and it represents a piece of information/data that a server wants to expose to a client. For example, the battery level characteristic represents the remaining power level of a battery in a device which can be read by a client. The characteristic contains other attributes that help define the value it holds:

• Properties: represented by a number of bits and which defines how a characteristic value can be used. Some examples include: read, write, write without response,notify, indicate.
• Descriptors: used to contain related information about the characteristic Value. Some examples include: extended properties, user description, fields used for subscribing to notifications and indications, and a field that defines the presentation of the value such as the format and the unit of the value.

Attribute Operations

The ATT protocol provides different methods by which data can be read or written from a BLE device.

• Commands: Sent to a server by a client and do not invoke a response
• Requests: Sent to a server by a client and invoke a response
• Responses: Sent to a client by a server when a request is received.
• Notifications: Sent to a client by a server without invoking a response. They are sent without the client requesting them.
• Indications: Sent to a client by a server and they invoke a response. They are sent without the client requesting them.
• Confirmations: Sent to a server by a client as an acknowledgment to an indication.

Security

The security architecture of Bluetooth has five distinct features: pairing, bonding, device authentication, encryption and message integrity.

• Pairing is the process for creating one or more shared secret keys
• Bonding is the act of storing the keys created during pairing for use in subsequent connections in order to form a trusted device pair.
• Device authentication is the verification that the two devices have the same keys
• Encryption is the process that provides message confidentiality
• Message integrity protects against message forgeries.

Authentication

Before the devices begin to communicate securely, we need to make certain that the other end is indeed the one we expect. BLE is a protocol intended for embedded devices and in many cases these devices can’t interact with a user or that means of interaction are very constrained. During the pairing phase each device informs the other end about its I/O capabilities and, based on this information, they agree on a association model for the identification, bearing in mind the I/O capabilities of the most constrained device.

There are four association models defined:

• Out of Band (OOB): This is designed for scenarios where both devices have a communication module operating in another Band, like NFC. The information exchanged includes discovery information (such as the Bluetooth Device Address), as well as cryptographic information. In order to be effective from a security point of view, the Out of Band channel should provide different physical properties in terms of security compared to the Bluetooth radio channel. In the NFC case, eavesdropping on the communication link is extremely difficult because of the weak signal that can be only received in very short distances, and in effect the key exchange process would be made very reliable.
• Numeric Comparison: In this scenario both devices have a display unit capable of displaying a six-digit number and are also capable of having the user enter “yes” or “no”. Both displays output the same number and the user is asked to confirm that these numbers match. This association model is only applicable in the LE Secure Connections architecture.
• Passkey Entry: Sometimes also called “PIN Entry Method”, the Passkey Entry is primarily intended for the case that one device has a keyboard but no display unit, and the other device has at least a display unit, for example a PC and a BLE keyboard scenario. The user is shown a six digit number (from “000000” to “999999”) on the device with a display, and then is asked to enter the number on the other device. If the value entered on the second device is correct, the pairing is successful. Although similar to the numeric comparison method, the Passkey Entry can also be used in LE Legacy Pairing.
• Just Works: This model is primarily intended for the most constrained devices in terms of I/O. The Just Works association model uses the Numeric Comparison protocol but the user is never shown a number and the application may simply ask the user to accept the connection. This method doesn’t offer protection against a MITM attack, but it offers the same protection level against passive eavesdropping as the Numeric Comparison.

Source of Information-Dialog Semi website

Bluetooth® Low Energy Technology

Since the release and growing popularity of Bluetooth Low Energy (LE), Renesas has been a participant in the Bluetooth SIG to contribute to the continuing evolution of the Bluetooth LE specification. As a result, Bluetooth LE is supported in a wide range of Renesas MCUs such as RA, RX, and RL78 and integrated into module products like RYZ012. Renesas is committed to supporting the future of Bluetooth LE with next-generation MCU development supporting Bluetooth 5.3.

Bluetooth LE Product Portfolio

Renesas’ whole aspect of commitment to Bluetooth Low Energy is summarized in our portfolio. The portfolio contains information related to Bluetooth LE, MCUs, and solutions for each Bluetooth LE MCU, so please download and use it.

Device Solutions

RX 32-Bit Bluetooth LE MCU

The RX23W 32-bit Bluetooth LE MCU offers the full functions of Bluetooth 5.0 LE and the built-in security functions essential to IoT devices, as well as rich peripheral features such as touch keys, USB and CAN. As a result, system control for devices and wireless communication can be realized on a single chip. The RX23W also provide a dedicated library that complies with the Bluetooth Mesh Networking specification for multipoint-to-multipoint communication. Renesas also has a lineup of the world’s smallest module products with built-in antennas and oscillators.RX23W Bluetooth LE Solutions Page

RA 32-Bit Bluetooth LE MCU

The RA4W1 32-bit Bluetooth LE MCU incorporate Bluetooth 5.0 LE, a secure crypto engine and low power functionality essential for any IoT application. The RA4W1 also features a rich set of peripheral features such as a capacitive touch sensing unit (CTSU) and a segment LCD controller (SLCDC), making it ideal for wireless applications that use a human machine interface (HMI).RA4W1 Bluetooth LE Solutions Page

RL78 16-Bit Bluetooth LE MCU

The RL78/G1D low-power 16-bit MCU support Bluetooth LE and enable reliable connections with current consumption levels among the lowest in the industry. We also have a beacon stack that pursues low current consumption. We also provide a module that can use the abundant function pins of the RL78/G1D as it is, with a built-in antenna and RF circuit.RL78/G1D Bluetooth LE Solutions Page

RYZ012x1 Bluetooth LE Module

The RYZ012x1 is a highly integrated wireless communication module that provides a pre-certified solution for Bluetooth 5.0 Low Energy. The network stack is executed inside the module, so there is no need for external stack operation.RYZ012x1 Solutions Product Page

Bluetooth LE Wireless Technology

Bluetooth LE wireless technology is designed for very low power operation and is optimized to short burst data transmission. In order to achieve reliable communication in the 2.4GHz frequency Band, it employs a robust frequency hopping spread spectrum method that transmits data over 40 channels.

The Bluetooth LE wireless technology provides great flexibility to developers with data rates from 125Kb/s to 2Mb/s, multiple PHY options that support power levels from 1mW to 100mW, and multiple high-level security options required by government agencies.

LE supports multiple network topologies such as Point-to-Point used for data transfer, Broadcast used for location services, and Mesh used for building large-scale device networks.

The benefit of Bluetooth LE is that it can communicate with applications for smartphones or tablets. Bluetooth LE is already used in many applications such as for healthcare and fitness, home electric appliances, home automation, gadgets, accessories, and location systems. With the growth of the IoT market in the future, it is expected that the number of products that support Bluetooth LE wireless technology will increase at an accelerating rate.

The Bluetooth wireless technology includes the LE standard and the BR/EDR standard that supports the Basic Rate and Enhanced Data Rate that are the classic standards.

Devices are classified into types that support LE only, BR/EDR only, and both LE and BR/EDR.

Renesas devices (RX23W, RA4W1, RL78/G1D) are the types that support only LE.

Applications using Bluetooth LE wireless technology have spread from healthcare devices and continue to expand into a wide variety of fields such as sports and fitness, Smart homes, industrial equipment, and beacon applications.

Bluetooth Qualification

The Bluetooth Special Interest Group (SIG) oversees the development of Bluetooth standards and the licensing of the Bluetooth wireless technologies and trademarks to manufacturers.

Refer to the Bluetooth LE microcomputer / module Bluetooth qualification acquisition application note for how to register a product using the Qualified Design Identification number (QDID) of our qualified design when selling a device equipped with a Renesas Bluetooth LE microcomputer or module as a Bluetooth product.

Common Tools Applications

The following common tools and applications can be used by Bluetooth LE MCUs.

QE for BLE － Development Assistance Tool

The QE for BLE is a dedicated tool for developing embedded software in systems which support the Bluetooth LE protocol stack. This solution toolkit runs in the e² studio integrated development environment (IDE). The combination of the e² studio and QE for BLE makes it easy to test the communications features of Renesas Bluetooth LE MCUs, thus reducing development periods for products being placed on the market. The standard profiles for RX23W and RA4W1 are generated from this tool. It can also design and generate the custom profile. Please refer to the QE for BLE: Development Assistance Tool for Bluetooth Low Energy page for more information.QE for BLE: Development Assistance Tool for Bluetooth Low Energy

GATTBrowser － Generic Data Communication Application

The GATTBrowser is a generic data communication application for checking the operation of Bluetooth LE. You can experience data communication with Bluetooth LE by scanning Bluetooth LE devices operating in the vicinity and connecting to those devices. It can be used not only for checking the operation of sample applications provided by Renesas Electronics, but also for debugging development products that implement Bluetooth LE MCU and module.

The GATTBrowser supports various operating systems (iOS, Android, Windows). The GATTBrowser for iOS and Android can be downloaded from the App Store and Google Play respectively.

Download GATTBrowser for iOS and Android:

Download GATTBrowser for Windows:

TryBT － Smartphone Application Example

TryBT is a smartphone application example that supports both Android and iOS, equipped with the functions required to communicate with Bluetooth LE products, and can be downloaded from the Apple App Store and Google Play. You can check communication with the firmware preinstalled in the Evaluation Board. In addition, icon images as well as a project file (can be imported into Android Studio or launched with Xcode) and source code are provided, so you can use this application example as a base for developing Bluetooth LE communication application in a Proof of Concept (PoC) phase.

• Bluetooth Low Energy Smartphone Application Example TryBT for Android. Sample Code (ZIP | English, 日本語) (PDF document A set of projects for Android Studio)
• Bluetooth Low Energy Smartphone Application Example TryBT for iOS. Sample Code (ZIP) (PDF A set of projects for Xcode)
• TryBT for iOS (App Store)
• TryBT for Android (Google Play)

Windows 10 Bluetooth LE Application － Windows Application Example

The Windows 10 Bluetooth LE application is an application example for Windows 10 that communicates with an evaluation board equipped with a Renesas Bluetooth LE MCU or module.

• RX23W, RA4W1

• Communicates with the firmware pre-installed on the evaluation board for each Bluetooth LE MCU, controls the LED blinking interval on the evaluation board and counts the number of times the switch is pressed.

• Communicates with the Virtual UART application that operates on the RL78/G1D evaluation board, and sends and receives character data.

In addition, a set of projects that can be launched and used in Visual Studio 2017 are provided, so you can use this application example as a base for developing Bluetooth LE communication apps that run on Windows in a Proof of Concept (PoC) phase.

Download Windows 10 Bluetooth LE Application: Bluetooth LE microcomputer / module Windows 10 Bluetooth LE Application Rev.1.00. Sample Code (ZIP) (PDF set of projects for Visual Studio 2017)

BTTS － Windows Application

In the survey/evaluation phase of the development process, new Bluetooth LE functions, API execution procedures and parameters of API can be learned by evaluating the functions and performance of Bluetooth LE supported by the Bluetooth LE MCU using the Bluetooth Test Tool Suite (BTTS). In the certification phase of the device, it can be used as a GUI tool to operate the device under test (DUT) in the Radio Law certification test.

Related Links

The Bluetooth ® word mark and logos are registered trademarks owned by Bluetooth SIG, Inc. and any use of such marks by Renesas Electronics Corporation is under license. Other trademarks and trade names are those of their respective owners.

What is Bluetooth Low Energy (BLE)?

Bluetooth Low Energy (or Bluetooth LE, Bluetooth Smart, or Bluetooth 4.0) is the power- and application-friendly version of Bluetooth that was built for the Internet of Things (IoT) devices.

And really, Why is Bluetooth called ‘Bluetooth’? The guy on the right is King Harald Blåtand Gormsen, the second King of Denmark and Norway. He ruled in the 10th century, uniting Scandinavia and converting his lands to Christianity. The Danish word ‘Blåtand’ means ‘dark tooth’ or ‘bluetooth’ as some translators started to represent the King Harald in historical chronicles. English-speaking countries started to call Harald ‘Bluetooth’.

In 1994, the Scandinavian company Ericsson started to develop a new way of wireless communication. Ericsson paid tribute to the memory of King Harald and their own heritage by naming the new tech Bluetooth, hoping Bluetooth would unite the PC and cellular industries with a short-range wireless link as Harold did for Scandinavia.

How the Bluetooth Smart appeared

In 2001, Nokia found contemporary wireless technologies did not address many applications. The company began developing a wireless technology which would use less power. The results were published in 2004 in a paper called Low end extension for Bluetooth. After 2 years, Nokia and partners began using the name Wibree. Wibree was presented as short-range, wireless technology that is 10 times more energy-efficient than Bluetooth.

In 2010 the Bluetooth Special Interest Group (SIG) announced the formal adoption of the Bluetooth Core Specification Version 4.0 with low energy technology. The first smartphone to implement the 4.0 specification was the iPhone 4S, released in October 2011. A number of other manufacturers followed suit with Bluetooth Smart Ready (just another name for BLE ) devices in 2012.

BLE vs BR/EDR vs Smart Ready: How are they different?

BLE has many names, including Bluetooth Smart and as similar term used: ‘Smart Ready’, where the device support both Classic (BR/EDR) Bluetooth and BLE.

The key differences between LE and BR/EDR is the channel numbers (40 as opposed to 79) and types of radio connections. Bluetooth LE allows for short bursts of long-range radio connection that prolong battery life. Classic Bluetooth (or Bluetooth BR/EDR) establishes a short-range, continuous wireless connection, which makes it ideal for use cases such as streaming audio. Dual-Mode (or Smart Ready) chipsets are available to support single devices such as smartphones or tablets that need to connect to both BR/EDR devices (such as audio headsets) and LE devices (such as wearables or retail beacons). []

Differences between Classic, LE and Dual mode Bluetooth architectures []

Comparison size of Bluetooth LE and Classical modules. []

How BLE Works

There are a numbers of clear and detailed explanations of BLE fundamentals, including “Getting Started with Bluetooth Low Energy” by Kevin Townsend. But how do we answer the practical question: How could the BLE chip work for years without charging?

How is low power achieved?

The easiest way to avoid consuming precious battery power is to turn the radio off as often as possible and for as long as possible. The BLE chip is programmed for:

Lower standby time

• Bluetooth low energy technology uses only 3 advertising channels
• Classic Bluetooth technology uses 16 to 32 channels
• Radio frequency (RF) is on for 1.2 ms instead of 22.5 ms

Idle current is dominated by deep sleep current

• Sensor type of applications send data less often (0.5 s to 4 s intervals)
• RF current is negligible due to low duty cycles
• Protocols optimized for this communication model

How do devices find each other?

This process is termed ‘Device Discovery’ and is the responsibility of another part of the Bluetooth architecture called the Generic Access Profile (GAP).

Such devices are looking, or scanning, other devices, receiving and processing advertising packets and filtering them. The scanning period is tunable between 2.5 ms and 10.24 s.

At the same time, another device advertises, emitting small packets of data periodically, from 20 ms to 10.24 s. These packets contain information about the advertising device. It should be kept in mind that the power consumption in BLE advertising mode is higher than in connection mode.

The device which advertises is called a Bluetooth Peripheral whereas the one doing the scanning is a Bluetooth Central device.

One device can do scanning and advertising simultaneously. And one can be in a connection with a central or peripheral and can do advertising at the same time.

A single node can “talk” to several hundred nodes simultaneously as the theoretical limit is about 500 nodes, according to this post in Nordic Semiconductor. Nordic Semiconductor. How the advertising packet and scan response packet is sent. []

Limitations of Bluetooth LE

BLE is used for applications that do not need to exchange large amounts of data. Its low-energy nature dictates the following key limitations.

BLE Data Throughput

The theoretical upper limit is 1 Mbps. In practice, a typical scenario assumes 5-10 Kb per second. But even transmitting at these relatively modest data rates, 10 KB/s will quickly drain any small coin cell battery. That means, BLE should not be used to transfer media data, for example.

BLE Operating Range

A typical operating range is between 2 to 5 meters, given a conscious effort to reduce the range and save battery life. The best way to use BLE devices is to send short messages, like the examples in the image below.

Sending short messages and then returning to sleep is a key BLE feature. []

Security on BLE devices

Security on BLE devices is implemented using several levels. Key generation is implemented on the Host level, while the Controller level performs the encryption function. The third security level supports the ability to send authenticated data over an unencrypted transport between two devices with CSR. Also, BLE supports a feature that reduces the ability to track a LE device over a period of time by changing the Bluetooth device address on a frequent basis. For information protection Bluetooth utilizes features against MITM, Passive Eavesdropping and Privacy/Identity Tracking. Optionally, transferred data could be encrypted by AES-128 with a CCM encryption engine.

BLE technology applications

There are a huge numbers of ways BLE technology can be applied. The intention is IoT, as it says on the official site: “Bluetooth is evolving from a smartphone and personal area network solution to a scalable, low-power wireless networking technology.” (ABI Research). “This development will unlock growth in beacons, home automation, building automation, lighting, and other Smart city applications over the next decade and beyond.”

Future posts will cover common and, especially, interesting cases for BLE technology.

The next generation of Bluetooth

At the 16 June SIG conference, the next generation of Bluetooth technology was announced: Bluetooth 5. It supports quadrupled range, doubled speed and increases data broadcasting capacity by 800%. Specification for Bluetooth version 5 available on official site.

Suggested note: Bluetooth devices, by nature, are still finicky to work with and different chips naturally vary in their transfer speed or range. Add to that different firmware attributable to each individual manufacturer and not a single source, and the variation increases. Numbers in this article are general estimates based on what developers have seen in practice and shared on the web.