A Practical Study On Bluetooth Low Energy (BLE) Throughput: F. John Dian Amirhossein Yousefi Sungjoon Lim
A Practical Study On Bluetooth Low Energy (BLE) Throughput: F. John Dian Amirhossein Yousefi Sungjoon Lim
A Practical Study On Bluetooth Low Energy (BLE) Throughput: F. John Dian Amirhossein Yousefi Sungjoon Lim
throughput
F. John Dian Amirhossein Yousefi Sungjoon Lim
Dept. of Electrical and Computer Dept. of Electrical and Computer Dept. of Electrical and Computer
Engineering Technology Engineering Technology Engineering Technology
British Columbia Institute of Technology British Columbia Institute of Technology British Columbia Institute of Technology
Burnaby, Canada Burnaby, Canada Burnaby, Canada
john_dian@bcit.ca amir_yousefi@bcit.ca rlim55@my.bcit.ca
Abstract—the data rate of Bluetooth Low Energy (BLE) is indicates that the maximum application layer throughput is
1Mbps, and 2Mbps for BLE 4.2 and BLE 5, respectively. However, 58.48 kbit/s in a practical scenario. However, this method does
the throughput of a BLE system would be much lower since we not explain the exact implementation of the BLE device or any
need to account for various protocol overheads, adaptive RF attempt to increase the throughput performance of the device.
connection adjustments for maintaining robust links amid For instance, some BLE devices can be configured to maximize
interference, and protocol limitations based on BLE data the throughput or minimize the power consumption or perform
exchange strategy and operations such as connection intervals, optimization based on throughput and power. It is clear that if
packet size and packet acknowledgment scheme. In this paper, we the device is set to minimize the power, is not able to provide
practically investigate the maximum throughput achievable in a
maximum throughput. In [11], maximum application level
simple BLE 4.2 network of two nodes, used in a data logging
throughput of 64 kbit/s has been obtained in an application to
application. In this type of application, one node always has data
to transmit and the other node which collects the transmitted stream data between a BLE node and a smartphone. The
sensor data does not have any data to send. We will also consider methods proposed in [8-10] use identical modules for master and
the effect of BLE parameters in this study. The result of our study slave devices, while the method in [11] does not use identical
shows that the maximum amount of throughput is 221.7 kbps for modules. In this paper, we practically investigate the maximum
this application under the condition that the wireless link is error throughput achievable in a simple BLE 4.2 network of two
free and application always has data to transmit. nodes, used in a data logging applications, where the peripheral
or slave nodes always have data to send and the central or master
Keywords— BLE (Bluetooth Low Energy), IoT (Internet of node is collecting the data, but does not have any data to
Things), wireless sensor network, transmit.
The remainder of this paper is organized as follows. Section
I. INTRODUCTION II, briefly explains the BLE communication protocol stack. BLE
The BLE is an emerging low-power wireless technology data exchange methods are discussed in section III. In Section
developed and used by various applications including those IV, the result of our experiments are presented. Finally, Section
defined by Internet of Things (IOT). The BLE technology is V concludes the paper.
expected to be incorporated into billions of devices in the next
few years and has been the area of research in the recent years
for various type of applications [1-6]. It is clear that one of the
drawback of BLE technology is its relatively low throughput II. BLE COMMUNICATION PROTOCOL STACK
comparing with other wireless technology such as WiFi. Even The BLE protocol stack is composed of three main layers:
though, the throughput of BLE system for various application the Controller, the Host and the Application. The Controller
scenarios has been discussed in literature [8-11], but the comprises the Physical Layer and the Link Layer. The Host
maximum throughput reported varies from 58Mbps to 236Mbps includes upper layer functionalities, including the Logical Link
for BLE 4.2. In [8], an analytical model is presented which Control and Adaptation Protocol (L2CAP), the Attribute
estimates the BLE throughput with a calculated maximum Protocol (ATT), the Generic Attribute Profile (GATT), the
throughput of 236.712 kbit/s in an error-free environment. Security Manager (SM) and the Generic Access Profile (GAP).
However, the model presented in [8] does not account for BLE Communication between the Host and the Controller is
pre-processing and post-processing operations which take place standardized as the Host Controller Interface (HCI). Application
before and after packet transmissions. It also does not consider layer program can be used on top of the Host. Fig. 1 illustrates
the hardware and stack limitations which exists on real BLE the BLE protocol stack. The main responsibility of the L2CAP
devices. In [9], a BLE performance analysis is resented which layer is to multiplex and perform segmentation and reassembly
its results show a maximum experimental link layer throughput of the packets for the lower layers. The ATT defines the
of 122.6 kbit/s, but this work did not use the upper BLE stack communication between two devices playing the roles of server
layers and the achieved throughput considers also the packet and client. SM is responsible for device paring, authentication
overhead, which does not contribute to the application data and key distribution.
throughput [11]. The experimental tests reported in [10],
768
The data that needs to be transmitted by a BLE node and The GAP layer specifies device roles, modes and
received by another BLE node is placed in a database called procedures for the discovery of BLE devices which are in range
GATT server. The data from GATT server can be moved to and services, the management of connection establishment and
another database which resides in another node and called security. The BLE GAP defines four roles with specific
GATT client. The GATT role is independent from device role requirements on the underlying controller: advertiser, scanner
of master and slave. In another word, the GATT server or GATT or initiator, master and slave. Advertising, scanning, and
client can be placed on the master node or on the slave node initiating are among the modes used in discovery process to find
depending on the application. GATT layer defines a framework the BLE devices in the range. The device in the advertising
for interaction with the GATT server and GATT client
mode is referred to as the advertiser, while, the BLE devices in
databases. Conceptually, data are always located on the GATT
the initiating and scanning modes are called the initiators, and
server and accessed or potentially modified by the GATT client
using ATT layer. The GATT client can access the GATT the scanners, respectively. The functionalities of the scanner
server’s data by sending requests, which trigger response and initiator are the same, except that the scanner intends only
messages from the GATT server. For greater efficiency, a to discover the advertiser, but the initiator can request a
GATT server can also send to a GATT client two types of connection with the advertiser after receiving an advertising
unsolicited messages which are notifications, and indications. message. To discover its neighbors and receive the advertising
Notifications do not need acknowledgment while identifications messages, the scanner wakes up periodically. Connections
require acknowledgment. allow application data to be transmitted in a reliable and robust
manner, as BLE connections use CRCs, acknowledgements,
The data is structured on a GATT server based on a strict and retransmissions of lost data to ensure correct data delivery.
hierarchy, allowing the access and retrieval of information
After a connection is established the advertiser becomes the
between GATT server and GATT client in an efficient manner
as shown in Figure 1. The data is organized as profile-service- slave and the initiator becomes the master.
characteristics-attributes hierarchy. Attributes are the smallest
data entity defined by GATT. They are addressable pieces of
information that can contain relevant application data or the data
related to the GATT hierarchy structure. The whole set of
attributes contained in a GATT server as a GATT table. GATT
table is a relational database with each row representing a single
attribute and each column representing the different fields that
actually constitute an attribute. The attributes in a GATT server
are grouped into services represented by a service attribute, each
of which can contain zero or more characteristics.
Characteristics attributes are containers for application data.
These characteristics, in turn, can include zero or more
descriptors, which are defined attributes that describe the
characteristic values. A service can have one or more
characteristics and represented by a service attribute. Services
are used to break data up into logical entities. A profile is defined
collection of services.
769
With read requests, the update is done only when the GATT and 100ms, the number of packets in each connection event were
client requests the reading of that value. For long application 5, 68 and 103, respectively.
data, the application data needs to be segmented to smaller
pieces and will be sent over multiple packets. It should be noted
that by notification only 20 bytes of application data is
transmitted in each data packets, while requesting a read can
transfer 22 bytes of application data inside a packet. Transferring
data from the GATT client to the GATT server is allowed only
through write requests.
Each connection event contains at least one TX and one RX
event, allowing to send/receive data packets. As mentioned
earlier, the standard defines procedures for segmenting and
reassembling longer characteristics, which will result in more
than one TX/RX events. There is no imposed limit to the
maximum number of packets in each connection event, but in
practical applications limitations may occur.
IV. EXPERIMENTAL RESULTS Fig. 3a. Transmission of multiple packets with CI=7.5ms
For our experiment, we used BLE 121LR chips from
Bluegiga platform to build a two-node peer-to-peer network and
used a packet sniffer to monitor the data exchange between these
BLE nodes. We programed the BLE nodes in such a way that
the slave node is able to send multiple packets to master. We
measured the current consumptions pattern to see the BLE
packet exchange. We also used the wireless connectivity
development kit with our packet sniffer to observe the behaviour
of the communications between the two BLE chips and data
packet exchange during the connections for debugging
purposes.
A. Experiment Setup
For our test, the GATT server is located on the slave node
and GATT client is located on the master node. The master is Fig. 3b. Transmission of multiple packets with CI=50ms
set to find one slave and configure its characteristic to perform
based on notification attribute protocol. After the connection has
been established, the slave will write data to its characteristic
attribute and it will automatically send the characteristic value
changes to the master. It should be noted that sending multi
packets in a connection interval is only allowed for attribute
protocol operations that do not require an acknowledgment.
770
packet (M->S) is 447µs. The time that takes for the slave to send maximum throughput available for a data logging application is
a packet to the master (S->M) is 230µs as shown in Fig. 4. It 221.7 kbps.
should be noted that the duration of Inter Frame Space (IFS) is
around 150 µs. In the connection interval of 7.5ms, there was
TABLE I - Maximum throughput of various connection interval
enough time to send 6 more packets; however, it seems that the
radio needs this time to complete other tasks. Connection Number of
Throughput (kb/s)
Interval (ms) Packets
7.5 5 106.4
12.5 12 153.6
40 53 212
50 68 217.6
60 83 221.3
70 97 221.7
75 102 217.6
80 103 206
100 103 164.8
Fig. 4. M->S and S->M timing captured by a packet sniffer
771