2013 13th International Conference on ITS Telecommunications (ITST)

Multihop Data Transfer Service for Bluetooth Low

Energy

Konstantin Mikhaylov and Jouni Tervonen

RFMedia Laboratory
Oulu Southern Institute, University of Oulu
Ylivieska, Finland
Emails:{konstantin.mikhaylov.jouni.tervonen}@oulu.fi

Abstract-Bluetooth Low Energy (BLE) is one of the recently

developed protocols enabling energy-efficient short-range radio u..
r=.-
I
GAP AppIIc8IIon
communication. One of limitations of BLE is the support for data Profiles Profiles

transferring over only a single hop. In the paper, we suggest the GAP
GAn
mechanism enabling the multihop data transfers between the
nodes in BLE networks. To ensure portability, the suggested
� An

mechanism is designed as BLE service, which uses only the

I L2CAP

/
Host-co orn:oil� Interface
integral components of BLE stack. We discuss in details the '1l::19 lY
suggested multihop service, its implementation and present the
LL
results of evaluation, which confirm feasibility and reveal
features of the suggested solution. To the best of our knowledge, PHY
this paper reports the first implementation of the multihop data
transfer over the BLE networks. o - Application layers

D - BLE host layers

Keywords-Bluetooth Low Energy; BLE; multihop; network; D - BLE controller layers

service; implement; evaluate; test; Fig. I. BLE stack

GAP AD
I. INTRODUCTION
Structure
Bluetooth Low Energy (BLE) is the energy-efficient short­
range wireless communication protocol, which was introduced GAP
in 2010 as a part of Bluetooth Core Specification version 4.0 AdvData
[1]. The major purpose of BLE developing was to enable
products with lower current consumption, lower complexity, Advertising
and lower cost than the ones possible with the classic PDU (ADV_'ND,
ADV_NONCONN_IND
Bluetooth technology [2], [3]. During development of BLE and or ADV_SCAN_'ND)
shortly after its introduction, it was predicted that the protocol Advertising r=C7'r-'--r--r--'-�
will find wide application area and will dominate the Wireless Channel
Sensor Network (WSN) application market by 2015 [4]. PDU

Nonetheless, even today, i.e. three years after the PHY/

fmalization of the BLE specification and two years since the LL
Length:
appearance of the first commercial BLE transceivers, only a (bytes)
few real-life applications use BLE. One of the major reasons Data
for this is the imperfections in the current BLE hardware (HW) Channel
and software (SW) implementations (see, e.g., [2]). The other PDU �;;��
reason is the features and restrictions of the BLE protocol. L2CAP
Among the most serious BLE limitations compared to the other (C-frame)
protocols is the restriction of the supported network topologies
to the single-hop scenarios, i.e. point-to-point or star topologies Fig. 2. BLE frame formats (*-23 bytes is the minimum value to be supported as
[2], [5]. defined in [6], if a BLE transceiver supports higher payloads - it should implement also the
apropriate segmentation mechanisms)

To the best of our knowledge, the only previous attempt to

solve this issue and to enable multihop (MH) BLE networks single gateway. Nonetheless, Haatanen was unable to
was done in [6]. In [6] Haatanen proposed the mechanism implement and verify the suggested mechanism in practice due
enabling the MH BLE network for the specific scenario, when to the limitations of the BLE transceivers at the time.
data are transferred in one direction from multiple nodes to the

Authorized licensed use limited to: Harokopio University. Downloaded on May 05,2024 at 18:40:23 UTC from IEEE Xplore. Restrictions apply.
978-1-4799-0846-2/13/$31.00 ©2013 IEEE 319
2013 13th International Conference on ITS Telecommunications (ITST)

Therefore, in the paper, we introduce the novel mechanism,

which enables MH BLE networks where data are transferred
between any nodes, discuss its practical implementation and
present the results of its evaluation.

II. OVERVIEW OF BLUETOOTH Low ENERGY PROTOCOL

As revealed in Fig.l, like the classic Bluetooth, BLE
protocol stack consists of the two major components: a BLE
Controller and a BLE Host [1]-[3], [5]. The Controller is the
logical entity that is responsible for the physical layer (PHY)
and the link layer (LL). The BLE Controllers inherit some
features from the Controllers of the classic Bluetooth, but both
types of Controllers are not compatible [2], [5]. The Host
implements functionalities of the upper layers, which are
discussed below. Communication between a Host and a
Controller is standardized as the Host Controller Interface Anchor point
Connection
Anchor point
event closed n+1
(HCI) [5]. On a real BLE device the Host and the Controller
b) Data transfer in data channels
can either reside on the same physical device or on the
different devices. Fig. 3. Data transfer using BLE (number of bytes is given for the LL)

Similar to the classic Bluetooth, BLE operates in the

license-free industrial, scientific and medical (ISM) band at 2.4
GHz. Nonetheless, in order to reduce price and energy
consumption, BLE uses binary frequency modulation with 1
Mbit/s over-the-air data rate [1], [2]. Unlike the classical
Bluetooth, which utilizes 79 I-MHz-wide channels, BLE uses
40 2-MHz wide channels. The three channels located between
the commonly used Wireless LAN channels are employed for
advertising and service discovery and are called advertising
channels [2], [3]. The remaining 37 data channels are used to
transfer data. The frequency hopping mechanism is used on the
data channels in order to handle the interferences and improve
the communication reliability. Formats of the BLE frames used
in advertising and data channels are depicted in Fig. 2. Fig. 2
reveals that BLE uses rather short packets with very limited
payload.
The data transfer between BLE devices is bound to the time
units called Advertising and Connection events (see Fig. 3) [2].
The Advertising events are used to broadcast the data on the
advertising channels. At the beginning of each Advertising
event the advertiser sends an advertising frame. To show
whether the advertiser can accept the connection establishment
Fig. 4. BLE connection establishing procedure
requests (i.e. CONNECT_REQ) or the requests for more data
(i.e. SCAN_REQ), the advertiser sets one of the four possible data channel while any of the devices has data to transmit or
Advertising event types. Out of those, three (i.e., ADV IND, until the current Connection event ends [2]. In the case if either
ADV _SCAN_IND and ADV_NONCONN_IND) are capable master or slave misses a frame or receives two consecutive
of transferring the data in the advertisement. frames with CRC errors, the current Connection event is
closed. According to the specification, minimum period
In the case if the advertiser sends the ADV IND or between two consecutive frames on a data channel should
ADV _DIRECT_IND frames, a device (referred as initiator), exceed the interframe space period (lFS), which equals to 150
which desires to exchange the data with the advertiser can send f..ls [1], [2].
the CONNECT_REQ frame. If the advertiser accepts the
request, the devices continue communication using the data The Host implements functionality of the upper layers,
channels (see Fig. 4). In this case, the initiator becomes the which include L2CAP, GAP, ATT, GATT and SM [2], [3].
master device and the advertiser - the slave. At the beginning The logical link control and adaptation protocol (L2CAP)
of each Connection event (referred to as the Connection event multiplexes packets of the upper layers, manages connection
anchor point) the used channel is changed following the establishment, configuration and destruction and can support
predefined sequence [2]. The communication in each packet segmentation [1], [2], [5]. In the current version of the
Connection event is initiated by the master device. The master specification [1], L2CAP of BLE supports only three types of
and the slave devices alternate sending the frames on the same traffic, which are distinguished using the L2CAP channel

Authorized licensed use limited to: Harokopio University. Downloaded on May 05,2024 at 18:40:23 UTC from IEEE Xplore. Restrictions apply.
320
2013 13th International Conference on ITS Telecommunications (ITST)

identifiers (CID) in the L2CAP packets (see Fig. 2). The TABLE T. GATT CHARACTERISTICS OF MH TRANSFER SERVICE
supported types of traffic are: the signalling traffic
Characteristic Permissions Size, Description
(CID=Ox0005), the traffic for attribute protocol (ATT) bytes
(CID=Ox0004) and the traffic for security manager (SM) route_entry Write 14 Used to transfer data about the routes.
(CID=Ox0006) [1], [3]. The SM manages authentication and Includes address of the target node,
pairing of devices, bounding, and encryption [2]. The attribute address of the next-hop node and the
protocol ATT defines client-server mechanisms, which enable total number of hops to the target node.
discovering, reading, and writing of the attributes. The generic own addr Read 6 Address of this node.
dst addr Write&Read 6 Address of the final target device for the
attribute profile (GATT) is based on ATT and provides the
block of data.
framework for discovering the various characteristics (i.e. the data Write >20 Part of data to be sent to dst addr.
data units) and the services (i.e. sets of characteristics and
references to other services) [2], [5]. The actual user BLE TABLE 11. FORMAT OF MH SERVICE INTERNAL STRUCTURES
application usually operates on top of GAP and GATT layers
Structure Structure b Description
(see Fig. 1). Note that although the general structure of the Size ,
a
name entries bytes
stacks for BLE and classical Bluetooth is similar, the
SeekTbl SeekAdr 6 Address of the node to which the route
functionality of the layers differs dramatically. Also the
should be found
specification prescribes each Bluetooth device to have a unique NumHops 2 Maximum number of hops
48-bit IEEE 802-2001 address for distinguishing and SeekTime 2 Remaining time to seek route to SeekAdr
addressing the device [1]. RouteTbl FinalDstAdr 6 Address of the final destination node
NHAddr 6 Address of the next-hop node towards
As one can see, the BLE only enables the communication FinalDstAdr
between the devices located within direct communication range HumHops 2 Number of hops up to FinalDstAdr
and does not support any MH data transferring [2], [5], [7]. DataBuf FinalDstAdr 6 Address of the final destination node
c
Data var Data to be transmitted to FinalDstAdr
The number of entries in each structure depends on implementation
III. SUGGESTED MECHANISM FOR MULTTHOP DATA b.
For a single entry.
TRANSFERTNG TN BLE NETWORKS
Depends on the implementation.

To enable transferring the data over multiple hops in a BLE

network two mechanisms are required. The fonner one should
handle discovery and establishment of connections with the Maximum
time to seek
neighboring nodes and handle discovery of a route to the
distant nodes. The latter one should handle storing of the 2

transferred data on the intermediate nodes and handle the

Fig. 5. Format of GAP advertising data (see Fig.2) for MHTS
transmission of the data further towards the destination node.
GATT write (GATT_WR) command (i.e., at least 22 bytes
There are two major ways, how the MH data transferring according to [1]). Also we consider that there is an internal
for BLE can be implemented. The first option is to introduce mechanism, which informs the application layer implementing
the MH traffic as a novel BLE L2CAP traffic type using one of the MHTS that GATT characteristics were modified by a
the currently reserved CIDs (similarly to what has been distant node.
suggested for transferring the IPv6 traffic over BLE in [8]).
Although this would enable one to develop a completely new Besides four GATT characteristics, the MHTS has three
protocol, which can be optimized for MH data transferring, the internal structures, which are depicted in Table 2. The first
protocol cannot be used in the real-life applications until the structure is named SeekTbl and stores the addresses of the
standardization and official CID assignment by Bluetooth SIG. nodes, the routes to which are currently being discovered, and
Therefore, we chose the other option and implemented the MH the parameters of the search. The second structure is called
transferring as a special "Multihop Transfer" service (MHTS) RouteTbl and stores the data about routes to all known nodes.
on top of the GATT layer. The table stores the address of the final destination, the
address of the next-hop node and the remaining number of
A. General Architechture
hops. Note, that the first entry in RouteTbl is added during the
service initialization and contains the address of the node
The MHTS has four characteristics (see Table 1). The first itself. The last structure is the DataBuJ The DataBuJ stores as
one is the write-only characteristic route_entry, which is used well the data to be transmitted using the MHTS and the
by nodes for transferring the data about the routes. The second address of the final destination node.
characteristic is the read only own_addr, which stores the 6-
byte address of current device. The third characteristic is the The format of the GAP advertising data (AD) used by
6-byte fmal destination address dst_addr, which can be both MHTS is depicted in Fig.5. The brief state diagram of MHTS
read and written. The last characteristic is the write-only data, is presented in Fig.6. The operation of the MHTS is illustrated
which is used for transferring the data and should be capable in Fig.7 and discussed in Sections III.B and III.e.
of storing the maximum payload one can put into a
Note that we assume that the note initiating the MH data
transferring always knows the address of the destination node.

Authorized licensed use limited to: Harokopio University. Downloaded on May 05,2024 at 18:40:23 UTC from IEEE Xplore. Restrictions apply.
321
2013 13th International Conference on ITS Telecommunications (ITST)

Initialization
AddMyAdrto RouteTbll start �� s�n�� I Scann ng
N i
Advertising [New MH data arrived]
Add those to DataBufl

Selecting next state

StartAdv=falseJ

[DataBuf is empty]
[else]
get SeekAdr,
NumHops and
Time from
SeekTbll

[StartAdv is false]

Connected as master

r-_____-" "''-j
I fail]
GAIT Discover MH service

connection

[have dst addr in R ou t Tb bu t DataBuf is

e l
u sen Insu IClen resources response

do not have dst addr in RouteTbl

[DataBuf contains more send efTOf response/

[else] wrile dala 10 DataBufl

[ N ew MH data arrived]
Add lhose 10 DataBufl

Fig. 6. State diagram of the suggested BLE MH service (Note: MyAdr is the address of the current node)

B. Nodes and Routes Discovery

Once MHTS has data for a distant node and does not know
the route, the discovery procedure is started. The MHTS adds
MH("C","D",O,8,6)
the address of the target node in the SeekTbl and defines the
parameters of the search (i.e. maximum number of hops and
��������=t��M�H�(�"B�'� )
Oi'Ci'i O�'O�� ������-l
the time for seeking) based on the priority of the data. After
this, the node starts sending the advertising frames, which
Data
include the data from the SeekTbl (see Figs. 5-7). The "ansf.,
__

neighboring BLE nodes with active MHTS, which currently phase

listens at the advertising channels, receive the advertising

packet. In the case if a node does not have the data about the
sought node in its RouteTbl- it adds the data from the received
advertising packet into its SeekTbl (if both remaining time and
L egen ds:
Time
Q
�
�
N � M
packetHadvUto nodeM
Time
a dv _f..":\ -node N sends an advertisement
� - nodeM establishes the connection
� wt
FormatMof the advertising frame:
H . UUIO of MHTS
(" L", h<l$ag����i�:et�M:����hiCh
Time

number of hops are non-zero). If a node knows the route to the

sought node, it establishes the connection to the node from .
�
®N GATT_WR(S,",a)/GATT_RO(S,"1
r;::>.� GA;.TT�
_W;.R;;; " '�
{S ';;;;
e- •- M i h node N and starts as master
node N discovers service S on nodeM and its
characteristic)[and reads it/writes a toit.
Connection remains active.
D{ Sh l � - node � d�scovers service S on nodeM and its
II ;.GA;.TT",,_R.;.
11M"
e
"N", t��hi�$ ���'l.r�
X,-
f t��u�ftce route to
, �hrc�dl�e�i�g
u
���l�����vJ�t,
remaining numberofhop$fo r$eek
which the advertisement was received and starts as connection � •l>l� charactenstlc)[and reads it/writes a toit.
y)- remainingtimelo5eek
�
master. Once the connection is established, the master Connection is dosed.

discovers the MHTS on the slave and writes in the slave's Fig. 7. lllustration of MH Service operation. Node A discovers the route and
sends data to node D through nodes B and C.
route_entry characteristic the data about the route to the sought
node (see Table 2). The slave node inserts the data received in all, the service obtains the address of the next-hop node from
the route_entry in its RouteTbl and excludes the address of the the RouteTbl. The address is then included in the special field
found node from its SeekTbl. of MHTS's advertising data (see Figs. 5 and 7). Once receiving
the advertising frame, the node with this address establishes
C. Multihop Data Transfering connection with the advertiser. The slave node (i.e., former
Once the MHTS has data to send to a distant node and advertiser) discovers the MHTS on the master and reads the
own addr from the master to ensure that the connection has
knows the route, the data transfer procedure is initiated. First of

Authorized licensed use limited to: Harokopio University. Downloaded on May 05,2024 at 18:40:23 UTC from IEEE Xplore. Restrictions apply.
322
2013 13th International Conference on ITS Telecommunications (ITST)

TABLE TIT. MAIN CHARACTERISTICS OF CC2540 SoCS & RADIO IV. IMPLEMENTATION AND EVALUATION OF THE MULTIHOP
MODULES USED IN TESTS [9 ] DATA TRANSFERING SERVICE
Device type System-on-Chip (BLE transceiver +
8051 microcontroller)
For evaluating the feasibility and the features of the
Microcontroller specification Clock: 32 MHz suggested BLE MHTS, we have implemented and tested it in a
Flash: 256 kB real-life experiment. The service was developed on top of the
RAM: 8 kB Texas Instruments' (TI) BLE stack (version l.3.1), which was
Radio protocol and stack version BLE (TI-BLE v1.3.1) running on the TI CC2540 systems-on-chips (SoCs)[9]. The
Operating radio band 2.4 GHz main characteristics of the CC2540 SoCs are summarized in
Modulation GFSK
Table 3.
Spectrum spreading FHSS
Over-the-air data rate, kbitls 1000 Table 3 reveals that the CC2540 SoCs combine both the
Transmit power range, dBm -23..4 8051-based microcontroller core and the BLE-compatible radio
Receive sensitivity, dBm -87 (standard mode)
transceiver. The TI BLE stack provides the solution, which
Supply voltage, V 2-3.6
enables the microcontroller core to control the BLE transceiver
Sleep current consumption ., IJ.A 0.9
WIth actIve tImer.
and implements the functionalities of both the BLE Host and
the Controller (refer to Fig.l). The suggested MHTS was
implemented on top of the GATT and GAP layers provided by
the stack.
To test the MHTS we used four hardware modules based
on the CC2540 SoCs (see Fig. 8). The nodes were placed at a
distance of around one meter from each other. The frame
source filtering was used to force the nodes to transfer the data
over the three hops (see Fig.7: e.g., node B is accepting the
packets only from nodes A and C, but not from node D). For
broadcasting the MHTS's advertisements (see Fig.5) we used
the ADV_IND events with the minimum allowed advertising
.-e-:.....- ... �-

interval (i.e. 20 ms [1], [2]). Also, for transferring data on the

. . :::-. ,:::- . . . - - data channels we have used the minimum possible value for
• �
• to

. � . . ,<-� . the connlnterval (i.e. 7.5 ms [1], [2]).

In the beginning of the test we have placed on the first node
Fig. 8. Hardware modules used for the tests (left to right): two CC2540EMK (node A on Fig.7) the block of data destined for the last node
boards (used as the first and the last node) and two CC2540DK-mini boards (node D on Fig.7). As the routing tables of all nodes were
(used as intermediate nodes) cleaned prior to the start of the test, the nodes firstly had to
been established correctly. Then the slave writes the address of discover the route and then to transfer the data over the three
the [mal destination node for the transferred data in the hops. The successful reception of the data was signalized by
dst_addr characteristic of the master. After successfully the light-emitting diodes on the last node.
writing the dst_addr, the slave starts getting the data for the
dst_addr from its DataBuJ and writes those in the data V. DISCUSSION AND LESSONS LEARNED
characteristic of the master. The data are written in the blocks The most significant challenges during the implementation
not exceeding the supported by the master maximum GATT of the BLE MHTS were:
characteristic size (see Section III.A). In the case if the master • the realization of switching between the roles of
does not have sufficient resources to store the received data in advertiser and scanner for a node;
its DataBuj, the node sends the "insufficient resource" • the deficiency of the RAM memory available on the
response. Otherwise, if the data was successfully written to nodes.
DataBuj, the node acknowledges the reception of the data. The
The TI BLE stack was developed in the first place keeping
slave continues sending the data to the master while it has in in mind the applications where a node acts all the time either as
the DataBuJ the data to be transferred to the nodes, for which the advertiser/connection slave or as the scanner/connection
the master node is the next-hop node, and while the master master. Meanwhile, as discussed in Section III and revealed in
node has sufficient resources to store the data. Fig. 6, the MHTS requires a node to periodically switch
Note, that immediately after the reception of a new between the roles of advertiser and scanner. To implement the
route_entry (see Section III.B), the slave node checks whether role switching we had to rethink the node's initialization
it has the data that might be forwarded via the master node (see procedures and the architecture of the application of the TI
operation of node A in Fig.7). BLE stack.

As one can see in Fig. 5, the advertising data of the MHTS One of the consequences of supporting both the
can contain simultaneously two different addresses - the one of advertiser/connection slave and the scanner/connection master
a node the route to which must be discovered and the address roles for the same node is the high consumption of the
of a neighbouring node, through which the advertising node resources. The total size of program code of the BLE stack
wants to send the data. (with maximum code optimization by the compiler) was
around 136 kB, which is around 52% of the total available

Authorized licensed use limited to: Harokopio University. Downloaded on May 05,2024 at 18:40:23 UTC from IEEE Xplore. Restrictions apply.
323
2013 13th International Conference on ITS Telecommunications (ITST)

code memory (see Table 3). Also, while supporting both roles, transfer in the BLE networks. To the best of our knowledge,
the BLE stack and the underlying OSAL operation system the suggested MH service is the first solution enabling MH
(OS) reserved around 7.6 kB of the random access memory data transfer between any nodes in BLE networks. Also, to the
(RAM), which is 95% of the total RAM. Even though the extent of our knowledge, the suggested solution is the first one,
2772 B of RAM is reserved for OS's memory heap and around which has been implemented and tested in practice.
1100 B can be further reused by the MHTS, one can see that
The suggested MH service is designed as a service, which
the total amount of data memory available for the service is
uses only integral components of the BLE stack. The service
rather scarce. Therefore, for our tests we limited the maximum
can be implemented on any BLE device, which can act as a
number of the entries in the SeekTbl and RouteTbl to five and
scanner and as an advertiser, and can establish the connections
the maximum size of data buffer to one kilobyte. Nonetheless,
in the data channels. To prove the feasibility of the MH data
we do not consider this issue to be critical because the
transfer using the suggested solution, we have implemented
available for a node RAM can be easily increased by adding an
and tested the service using the CC2540 SoCs from Texas
external memory chip.
Instruments. In our experiments, we successfully used the
Although our experiments confirmed the feasibility of MH developed MH service implementation to transmit the data
data transferring in BLE networks in general and specifically over two and three hops. Nonetheless, the presented in the
the suitability of the suggested MH service for this purpose, paper results show that the MH data transfer in the BLE
those have revealed one significant limitation for MH data networks requires quite significant time.
transferring in BLE. Even though in our experiments we used
Although we have proved that MH data transfer in BLE
the minimum possible values for advertising and connection
networks is possible and have introduced a solution for this,
intervals, the total time for finding the way and sending one
there are still many open problems. First of all, in our test we
data block of 13 bytes over three hops in practice ranged from
could use only four nodes, which is definitely not enough to
20 to 30 seconds (25 s in average). Note that the time for
reveal all possible networking effects. To reveal those, the
sending more than one packet does not increase significantly.
extensive study including the simulation of the multi-node
E.g., the average time for fmding the way and sending 40
BLE networks is required. One of the major challenges here is
I3-byte packets was 28 s. Meanwhile, once the route is known,
the absence of simulators capable to simulate BLE at the time.
the time for sending the data over the three hops is between 6
Another very important issue is how it is possible to provide
and 9 seconds. There are two major reasons for this. First of
sufficient security during MH BLE communication and how to
all, once two nodes establish the connection, those have to use
handle mobility of nodes. Finally, as energy efficiency is one
the appropriate ATT mechanisms firstly to discover the MH
of the major targets for BLE, it is necessary to study how
service and then to fmd the associated with the service
efficient the suggested approach is and how the sleeping nodes
characteristics. This requires sending back and forth multiple
in the BLE networks will affect the MH data transfer.
frames. Meanwhile, as discussed e.g., in [2], [5], the TI BLE
stack can send only a few frames in one connection event. Nonetheless, we suppose that even in the current form the
Therefore, e.g., the transmission of the route_entry over each suggested MH data transfer mechanism for the BLE networks
hop requires as many as 12 connection events (i.e. 90 ms for can be used in practice and can enable the development of
minimum possible connlnterval value) after the connection novel and exciting applications.
establishment. The transmission of data over each hop requires
2l+2*n connection events (i.e. I57.5+I5*n ms), where n is the REFERENCES

number of the packets (up to 22-byte payload). As easy to see, [1] Bluetooth Specification.Core Package version 4.0, 2010.
if not to consider the time spent for advertising, the discovery [2] K. Mikhaylov, N. Plevritakis, and J. Tervonen, "Performance analysis
and comparison of Bluetooth Low Energy with IEEE 802.15.4 and
of a route and transmission of a single data block of up to 22
SimpliciTT," J. Sens. Actuator Networks, vol. 2, no. 3, pp. 589-613,
bytes over the three hops will require at least 787.5 ms. Aug. 2013.
[3] R. Heydon, Bluetooth LolV Energy: the developer's handbook. Upper
Nonetheless, in our experiment the major time the nodes
Saddle River, NJ: Prentice Hall PTR, 2012.
were spending in the advertising mode. It could require up to [4] "WTRS Wireless Sensor Network Technology Trends Report," West
ten seconds from the start of advertising up to the Technologies Research Solutions, Mountain View, CA, USA,
establishment of connection between an initiator and an WT062510CNTS, Jun. 2010.
advertiser. We suppose that the major reason for this is the [5] C. Gomez, J. Oller, and 1. Paradells, "Overview and Evaluation of
Bluetooth Low Energy: An Emerging Low-power Wireless
specifics of the implementation of these procedures in TI BLE
Technology," Sensors, vol. 12, no. 9, pp. 11734-11753, Aug. 2012.
stack (some features of the stack are discussed e.g., in [2], [5] ). [6] M. Haatanen, "Self-organizing routing protocol for Bluetooth Low
Energy sensor networks," B.Sc. thesis, Oulu Univ. Appl. Sc., Oulu,
VI. CONCLUSIONS Finland, 2012.
Bluetooth Low Energy (BLE) is the novel energy-efficient [7] E. Mackensen, M. Lai, and T. M. Wendt, "Performance analysis of an
Bluetooth Low Energy sensor system," in Proc. 1st into Symp. Wireless
short-range wireless communication protocol. The previous Syst. (iDAACS-SWS'12), Offenburg, Germany, 2012, pp. 62-66.
studies (e.g., [2]) have shown that compared with the other [8] H. Wang, M. Xi, J. Liu, and C. Chen, 'Transmitting IPv6 packets over
technologies, BLE provides an inexpensive and power-efficient Bluetooth low energy based on BlueZ," in Proc. 15th Int. Conf. on Adv.
solution for wireless communication. Commun. Technol. (lCACT'13), Pyeongchang, ROK, 2013, pp. 72-77.
[9] "2.4-GHz Bluetooth Low Energy system-on-chip," Texas Instruments,
In the paper, we have suggested, discussed the practical 2013.
implementation, and presented some evaluation results for the
special multihop (MH) service, which enables MH data

Authorized licensed use limited to: Harokopio University. Downloaded on May 05,2024 at 18:40:23 UTC from IEEE Xplore. Restrictions apply.
324