Content uploaded by Madhusanka Liyanage
Author content
All content in this area was uploaded by Madhusanka Liyanage on Sep 20, 2018
Content may be subject to copyright.
Managing Mobile Relays for Secure E2E
Connectivity of Low-Power IoT Devices
Pawani Porambage, Ahsan Manzoor,
Madhsanka Liyanage, Mika Ylianttila
University of Oulu, Finland
Email: {firstname.lastname}@oulu.fi
Andrei Gurtov
Link¨
oping University, Sweden
Email: gurtov@acm.org
Abstract—The widespread Internet of Things (IoT)
ecosystems empower the deployment of various Bluetooth
Low Energy (BLE) sensor nodes in many ambient assisted
living (AAL) type applications. Regardless of their limi-
tations, these low-power IoT sensor nodes need pervasive
and secure connections to transfer the aggregated data
to the central servers located in remote clouds which
will perform further processing and storing functions.
The common practice is to use one or multiple dedicated
gateways to assist the communication between the sen-
sor and the cloud. This paper presents a mobile-based
relay assistance solution for establishing secure end-to-
end (E2E) connectivity between low-power IoT sensors
and cloud servers without using a dedicated gateway. The
performance of proposed solution is analyzed by using
the simulations and the prototype implementation with
commercial off-the-shelf devices. The prototype imple-
mentation and the described security features verify the
technical readiness of the proposed solution.
I. INTRODUCTION
With the proliferation of the Internet of Things (IoT)
technologies, in addition to the key purpose of using
a particular smart object, people are fascinated to ac-
cess or obtain multiple other services from the same
device [1]. Moreover, the seamless connectivity and
increased quality of experience are highly regarded for
better user experiences. Many IoT devices in health-
care and Ambient Assisted Living (AAL) applications
are equipped with unlicensed band short-range radio
access technologies, including Bluetooth Low Energy
(BLE), HaLow, ZigBee, and Smart Utility Networks
(SUNs). [2]. Among them, BLE is the best-known and
most used low-power communication technology that
supports connectivity for Body Area Networks (BANs)
and a large number of medical IoT devices which
operate with coin cell batteries [3]. Although the Low
Power Wide Area Network (LPWAN) radio technolo-
gies such as Narrow Band IoT (NB-IoT) and LoRaWAN
are recently becoming popular, they are not widely
deployed in medical and wearable IoT applications.
BLE is a stateless protocol where the requests are
independently transmitted and it allows a very flexible
topology which can be adjusted to fit into a large
number of use cases. The resource-constrained IoT
devices that use standalone BLE for communication
purposes require dedicated nodes that serve as local
gateways (GWs) to provide back-end connectivity with
the remote IoT cloud/data centers. In the typical AAL
applications the BLE wearables pair with the user’s
mobile phone which is acting as the GW to obtain
end-to-end (E2E) connectivity with the cloud servers.
Instead of using a committed single GW, if the wearable
can get the data forwarding services from unknown
relaying nodes in the closest proximity, it will provide
high user mobility even to foreign environments.
The exploitation of mobile-based relays for the back-
end connectivity of BLE devices is described for an
AAL use case in Figure 1. The elderly or the people
with chronic conditions may require continuous moni-
toring of their health records or localize with the help of
different BLE sensor wearables. The interested parties
(e.g., family or caretakers) can track their behavior
or examine the health conditions based on the data
retrieved from the remote central cloud. By using a ded-
icated mobile phone, the back-end connectivity between
the BLE wearable sensor and the cloud data center may
drop when the user is going beyond the comfort zone
or the phone-battery is dead. The uninterrupted E2E
connectivity can be maintained between the wearable
and the cloud data centers with the help of some random
mobile users who are performing as relays. In order
to keep the in-line with this mechanism, the unknown
mobile user needs to be rewarded by the remote cloud
for his relaying service.
Fig. 1. Usecase scenario
Our key contributions of this paper include the de-
sign and development of on-demand sharing network
instantiation for universal accessibility of BLE sensors
with the help of mobile relays. The simulation results
and the implementation with the commercial off-the-
shelf devices prove the the technical readiness of the
proposal. The security considerations of the protocol are
discussed along with the possible attack scenarios. To
the best of our knowledge, this will be the first attempt
of exploiting third-party unknown mobile relays for the
forwarding of medical data generated by BLE sensors.
The remainder of the paper is organized as follows:
Section II provides the related work. Section III and IV
describe the proposed network architecture and pro-
tocol. Section V and VI present the simulation and
implementation results, and the security considerations
of the protocol. Finally, Section VII concludes the paper
by drawing the future research directions.
II. RE LATED WO RK
BLE version 5.0 is the latest addition from the Blue-
tooth Special Interest Group [4]. It is a wireless personal
area networking technology that can be exploited in a
very broad range of applications including healthcare,
fitness and elderly care, smart homes, smart cities,
etc. BLE plays a vital role in many other short-range
wireless communication protocols such as Zigbee, Near
Field Communication (NFC), 6LoWPAN [5]. The coex-
istence of BLE with many varieties of devices ranging
from mobile phones to resource-constrained medical
sensors has proven its usability as an IoT technology. As
presented in [3], it is feasible to implement a complete
IP-based protocol stack on constrained BLE devices
and enable gateway operations covering global IPV6
connectivity and proxy-cache functionality.
The proposed relay-assisted E2E connection estab-
lishment for low-power IoT devices was initiated by
the idea behind collaborative on-demand Wi-Fi shar-
ing (COWS) appeared in [6]. The ubiquitous access to
the foreign private Wi-Fi network is mostly prohibited
since the private Access Points (APs) have no means of
authenticating foreign users before granting access to
their network. COWS comprehensively discover roam-
ing networks by opportunistically broadcasting connec-
tion requests and offers 802.11 authentications at private
APs by embedding user credentials. At the end of suc-
cessful authentication at private APs, the Internet traffic
is tunneled through the user’s Home Provider (HP).
Although COWS has a rather small footprint in terms of
communication, it is not really designed for resource-
constrained devices. Simply, we commenced this work
as an extension of COWS for IoT sensors. In our design,
we intend to adopt the message flow of COWS and
tailor it according to protocol specifications of BLE.
Instead of APs in COWS, the intermediary needs to
be the smartphone which supports BLE and has the
connectivity to the Internet.
In [7], Raza et. al. present a design of a novel open
hardware platform for BLE and discuss the possibil-
ity of implementing 6LoWPAN-connected Bluetooth
Smart. They use nRF24Cheep, the custom designed
BLE beacon platform, to perform experiments on ad-
justing BLE message formats. Moreover, they provide
Contiki operating system port to the same open BLE
broadcast platform. Although this work is in very ab-
stract form, it provides an initial guidance on how to
establish a BLE connected IoT setup and its prototyping
for a full open-source BLE stack.
The newly introduced edge computing paradigms
(E.g. Fog computing and Multi-Access Mobile Edge
Computing) leverage the low-latency requirements of
IoT applications. The work presented in [8] describe
the exploitation of smart e-health gateways, called UT-
GATE, at the edge of healthcare IoT in clinical environ-
ments. According to their proposed fog-assisted system
architecture, the smart e-health gateway provides an
intermediary layer of intelligence between sensor nodes
and cloud. The resource consuming tasks of the sensors
can be outsourced at the gateway and support ubiquitous
characteristics such as mobility, energy efficiency, scal-
ability, and reliability issues. They have demonstrated
the functionality of UT-GATE with different network
topologies such as mesh and star and using wireless
sensor technologies like 6LoWPAN, Wi-Fi, and BLE.
However, this solution still lacks the universal connec-
tivity in the roaming situations.
Another research followed by Haus et. al., in [9],
investigate the usability of an iConfig edge-driven
platform for IoT device management including BLE
beacons in smart cities. In this experiment, the user
with a smartphone running the iConfig edge module
will assist the BLE beacons, emitted by IoT devices,
in three phases namely registration, configuration, and
maintenance. The automatic configuration and further
processing are performed by the edge module with
the minimal user interaction. This particular work does
not address how the IoT sensors can maintain E2E
connectivity with back-end cloud data centers.
With the advent of technological upgrades, BLE
will no longer support only the monitoring and data
collecting applications. The researches are underway
to investigate its applicability for different areas such
as multimedia streaming [10]. However, in any case,
security is a mandatory property to guarantee in E2E
IoT communication scenarios [11].
III. USE CA SE , NET WO RK ARCHITECTURE AND
ASSUMPTIONS
This section describes the network architecture, key
assumptions, and prerequisites.
A. Network Architecture
The network architecture is illustrated in Figure 2.
BLE sensor advertises its availability of data. One or
many anonymous mobile phones may receive the adver-
tisement and accept to cooperate with further commu-
nication as a relay node. The best relay node is selected
based on the received signal strength indicator (RSSI).
The link between the mobile and the central server (CS)
in IoT cloud will be securely established over the Inter-
net in a conventional manner (e.g., Hypertext Transfer
Protocol Secured (HTTPS)). When the data is received
from the BLE device, CS will update the database which
is dedicated to that particular user (or device).
Fig. 2. The network architecture
B. Pre-requisites and Assumptions
The BLE device should undergo an initial registration
with the CS, which can be performed offline or via
a trusted third party (e.g., trusted GW). The sensor
should have the identity of the CS and the CS should
maintain the records of all the legitimate sensors and
their functioning databases. In order to maintain E2E
secure communication, the BLE device and CS should
share the cryptographic keys for data encryption and
decryption, and the authentication credentials (e.g., User
ID (UID) and hash chain).
Throughout the protocol, we consider the guaranteed
link quality for all the communication channels. Fur-
thermore, it is assumed that the connections remain
uninterrupted over the period of communication and
the mobile device will operate in the same proximity.
No mutual or transitive trusts are required between the
relay device and the other entities (i.e., sensor and CS).
However, the mobile phone can always proceed the
relaying functions (forwarding sensed data OR traffic)
as long as it is rewarded. For the sake of rewarding
mechanism, the mobile needs to be registered with CS
in advance and the secure links (i.e. Transport Layer
Security (TLS) protocol) should be established between
the two entities. The functionality of CS is utterly
trusted which will grant the incentives to the relay
device at the end of successful service.
IV. PROTOC OL
The message flow of the protocol is illustrated in
Figure 3 and described in this section.
Fig. 3. Message flow of the proposed protocol
1) Phase 1: When the data is available with the
BLE sensor it creates an advertising HELLO packet
and broadcasts to find a mobile as a relay node. This
HELLO packet includes device MAC address, appli-
cation ID (i.e., Universal Unique Identifier (UUID)
128bit) and timestamp. This step is the initiation of
non-connectable status to connectable status between
the sensor and the relay mobile.
2) Phase 2: Upon receiving the HELLO message
from the sensor, one or multiple mobile phones (i.e.,
which have the healthcare application) in the closest
proximity may respond. If the acceptances are received
by multiple mobile phones during a predefined time-out,
the best relay among them is elected based on the RSSI
value. If the sensor does not receive any connection
acceptance messages during that time-out, it will repeat
Phase 1 again.
3) Phase 3: Once the connection between the sensor
and the mobile is established, the sensor sends another
connection request (CR) message to the central CS via
the mobile relay. This message includes the CS address
as plain text and the connection request to CS in an en-
crypted format. Advanced Encryption Standard-Counter
with Cipher Block Chaining-Message Authentication
Code (AES-CCM) is used for symmetric encryption
whereas the keys are shared off-line between the sensor
and CS. A timestamp is also contained, in order to keep
the freshness of the connection request. Upon receiving
the connection request and sensor MAC address, the CS
will authenticate the sensor and validate its legitimacy
by decrypting the message with corresponding keys.
4) Phase 4: If the connection request has been
received by a legitimate user, and the message freshness
is encountered, the CS will continue the communication
and send back the connection approving the message.
5) Phase 5: Once the connection is established, the
BLE sensor sends the encrypted data packets to CS
via the mobile relay. When the buffered data is over,
the sensor will send a request to cease the connection.
After receiving this, the CS will reply with an acknowl-
edgment for ceasing the connection which ensures the
successful reception of data. Finally, the BLE sensor
will send the last Ack message and terminate the
connection. This final two-way handshake is performed
in order to guarantee the successful data transmission
from the sensor to the cloud and to validate the genuine
support from the mobile relay.
6) Phase 6: At the end of successful data forwarding
process, the mobile user has to be rewarded for his
service. The reward is automatically calculated by the
application depending on the amount of data uploaded
by the sensor. Based on the sensor acknowledgment
about the completion of data forwarding, the CS will
grant the computed reward to the mobile user. Due to
the rewarding mechanism, the initial user authentication
is important. Furthermore, we consider that the remote
CS is an entirely trusted entity where the final reward
is guaranteed to the mobile user for his service.
V. SIMULATION AND IMPLEMENTATION
A. Simulation
In order to justify the applicability and the reliability
of this protocol in a real environment, we performed
simulations in MATLAB. For that, we estimate the
probability for a successful meeting with at least one
mobile user who is willing to act as a relay. The BLE
sensor needs to meet a mobile user before its data buffer
overflows. The arrival of mobile users can be modeled
as a Poisson process with the expected value λ, the
number of mobile users arrive during ttime interval,
where t=B/λ0:Bis the data buffer size (KB) of the
BLE sensor and λ0is the data generating rate of the
sensor (Kbps). The probability (P) of meeting at least
one mobile user (i.e., the probability of successful data
transmission) during ttime period is expressed as eq. 1.
P= 1 −e
−λB
λ0/8(1)
In the first simulation, as shown in Figure 4, we illus-
trate how the probability distribution affects at different
mobile arrival rates with a constant data generation
rate of 0.2 Kbps (where λ0= 0.2Kbps) at varying
buffer size. We use CC2650 for the experimental setup
as it is a very common platform for BLE application
development. Since CC2650 has 128 KB Flash memory,
the maximum possible buffer size will be limited to that
value. When the buffer size is increased, the probability
of meeting a mobile user will reach to one with a less
mobile arrival rate. With the maximum buffer size of
128 KB, the probability of success Pwill be one if
three mobile users arrive per hour. When buffer size is
changed to 100 KB, Pwill reach one for the arrival of
five users per hour.
As shown in Figure 4, we illustrate how the probabil-
ity distribution affects at different mobile arrival rates
with a constant data generation rate (λ0= 0.2kbps).
For instance wearable sensors have the potential to
generate big datasets like 156 MB of data per day [12].
By varying the allocated buffer size of CC2650 Flash
memory, we plotted multiple graphs. Since CC2650 has
128KB Flash memory the maximum possible buffer size
will be limited to that value. When the buffer size is
increased, the probability of meeting a mobile user will
reach to one with a less mobile arrival rate. With the
maximum buffer size of 128KB, the probability Pwill
be one if three mobile users arrive per hour.
0 20 40 60 80 100
Mobile arrival rate (users per hour)
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Probability of meeting a mobile user
B=5KB
B=10KB
B=20KB
B=50KB
B=100KB
B=128KB
0246810
0
0.2
0.4
0.6
0.8
1
Fig. 4. Probability distribution of meeting a mobile user for varying
buffer size
Figure 5 illustrates the results of the second experi-
ment with the probability distribution for varying sensor
data generation rates. The buffer size is kept constant as
100 KB. Accordingly, if the data generation rate of the
sensor is low, the highest success rate can be achieved
with a low arrival rate of mobile user. For instance when
λ0= 0.2Kbps, the probability of success Pwill reach
one with arrival of five mobile users per hour.
In the third experiment, we try to find the proximity
requirement to hold the assumption of holding an unin-
terrupted communication link between the BLE sensor
and mobile relay. In order to maintain an uninterrupted
communication link between the BLE sensor and mo-
bile relay, the RSSI value should be above the minimum
detectable level throughout the data transmission time.
Consequently, the distance between those two should
0 20 40 60 80 100
Mobile arrival rate (users per hour)
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
Probability of meeting a mobile user
0.2Kbps
0.4Kbps
0.8Kbps
1.6Kbps
3.2Kbps
4.8Kbps
0246810
0
0.2
0.4
0.6
0.8
1
Fig. 5. Probability distribution of meeting a mobile user for varying
data generation rate
be less than or equal to the maximum threshold. This
distance is estimated using the signal attenuation of BLE
beacons that can be described by the commonly used
logarithmic path loss model [13] given by eq. 2.
RSSID=RSSID0+ 10nlog D
D0
+X(0, σ)(2)
The two values RSSIDand RSS ID0respectively
represent the RSSI (dBm) at the distance D(m) and the
reference distance D0(m). The path loss exponent (n) is
dependent on many environmental factors and obstacles
such as walls, objects, and people. The zero-mean Gaus-
sian noise with variance σ2is represented by X(0, σ).
According to the empirical analysis given in [14], for
BLE communication, the path loss exponent varies from
1.35 to 3 for indoor and outdoor environments. As stated
in [14], the reason for the lower path loss exponent
could be that the indoor environments could be acting
like a wave-guide, resulting in constructive interference.
TABLE I
PATH LOS S EX PO NE NT nVALU ES F OR BLE COMMUNICATION IN
INDOOR AND OUTDOOR ENVIRONMENTS [14]
Environment Category n
Indoor Line of sight 1.98
Non line of sight 1.35
Outdoor 0◦2.89
45◦3.00
90◦2.47
Considering the reference values observed from
CC2650, RSSID0value was measured as -72 dBm at
1m distance D0when the transmission power at the
sensor is adjusted to the minimum of -21 dBm. In
line with the manufacturer specifications of the CC2650
platform, the lowest identifiable RSSI is -100 dBm.
We use these values along with the path loss model
to estimate the distance between the BLE sensor and
the mobile phone in order to maintain an uninterrupted
service. As shown in Figure 6, the plots are drawn
by varying the path loss exponent which increases
with the growth of available obstacles between two
communicating entities. Accordingly, for an uninter-
-100 -90 -80 -70 -60 -50 -40 -30 -20
RSSI (dBm)
0
20
40
60
80
100
120
Distance between sensor and relay (m)
n=1.35
n=1.98
n=2.47
n=2.89
n=3.00
-100 -95 -90 -85 -80
0
20
40
60
80
100
120
Fig. 6. Distribution of distance with the RSSI for varying path loss
exponents
rupted data transfer in the indoor environments, the
distance between the sensor and the mobile needs to
be maintained less than 120 m during the entire time
which the connection is working. In contrast, at the
outdoor environments, the sensor and the mobile have to
keep at most 9m proximity to maintain the connection.
Thereby, we can conclude that our protocol will support
higher user mobility in the indoor environments than in
outdoors.
B. Implementation
In order to show the feasibility of this protocol,
we have accomplished the prototype implementation
on a testbed with a BLE sensor, mobile, and cloud
platform (Figure 7). The Internet access was achieved
by the general university WiFi network (i.e., PanOULU
network).
Fig. 7. Testbed setup
Texas Instrument sensor tag CC2650 and Samsung
Galaxy Note 8 were respectively used as the sensor
and mobile hardware platforms. In accordance with
the protocol, we slightly modified the BLE stack 2.2.1
on CC2650 using SmartRF Flash programmer 2. The
mobile application was developed on Android 7.1.1 op-
erating system using Android Studio 3.0 libraries. This
mobile application scans in the background to discover
devices and connects to the BLE sensors. This BLE
sensor is then paired with the mobile automatically,
using the passcode 0000. After paring, sensor initiates
data uploading directly to the Cloud platform. The last
part of the implementation was to deploy the cloud
server on Google Firebasewhere the user of the mobile
application can authenticate himself and the sensor can
upload the sensed data to a JSON database. The user
needs to login the application for authentication by CS
and the collection of rewards. The application monitors
the amount of data transferred from the sensor to the
cloud and after the confirmation from the CS, the
application automatically credits the reward to the user
account. In order to keep the reward mechanism simple
and profitable, for transferring every 1 KB of data, the
user gets one point which can later be used for different
purposes (e.g., convert into digital currency). Moreover,
Firebase uses HTTPS connection over TLS for secure
communications between the mobile and cloud server
along with real-time database security.
TABLE II
BLE CO NFIG UR ATIO N SE TT IN GS F OR CC2650
Attribute Configured values
Transmission power 0 dB
Number of running services 6 services
Periodic event 1000 ms
Advertising interval 100 ms
Connection timeout 1000 ms
Broadcast delay 500 ms
Packet size 18 byte
Under normal network conditions, we measured the
maximum response time of the mobile to discover a
sensor, authenticate the sensor from the cloud, establish
connection and discover one service, upload data, and
terminate the connection. Each experiment was per-
formed ten times and the average was taken. In order to
synchronize the clock time between sensor and mobile,
computer clock time was sent to sensor when flashing
the modified BLE stack. The application data inside
one packet, which is 18 byte, is equivalent to one data
reading. Figure 8 shows the distribution of timing values
for those five operations. Accordingly, the total response
time for the mobile was computed as 5.4 s.
The durations for connection initializing (2.8 s) (i.e.,
including sensor discovery, authentication, connection
establishment, and service discovery) and termination
(0.2 s) will remain constant, irrespective of the amount
of data transferred.
The power consumption for Android application run-
ning on the mobile was reported as 33 mAh. Therefore,
with 3.85 v nominal voltage, the power consumption of
Discovery
Authentication
Con. establishment
Data upload
Con. termination
0
0.5
1
1.5
2
2.5
Time (s)
Fig. 8. Time distribution for the protocol operations
the application on the mobile is 127.05 mW per hour.
It is only 1% of battery. Thus energy consumption is
quite low for our implementation. The distribution of
power consumption of CC2650 sensor was observed
from Monsoon power monitor tool , as depicted in
Figure 9. The average power consumption values of
the sensor during the connection establishment and data
upload to the cloud were recorded as 239 mW and
262 mW. On an average, the sensor uploads the data
to cloud server once every hour. We assume that every
transaction takes approximately 1 minute and the sensor
deactivates its BLE until the next transaction. With the
Cell capacity of 300mAh, the sensor uses approximately
0.5% of battery for each transaction and it can upload
data 200 times without recharging the sensor.
Fig. 9. Distribution of sensor power consumption
VI. SECURITY CONSIDERATION
Passive eavesdropping can be a critical issue in these
kinds of relay-based systems. Passive eavesdropper can
learn about users’ privacy information (e.g. location and
current health condition) from the sensed data. He can
also obtain the network parameters of the CS to perform
network-level attacks such as TCP reset attacks. In order
to eliminate the risk of passive eavesdropping, we use
AES-CCM for E2E data encryption. AES-CCM is an
authenticated encryption algorithm designed to provide
both authentication and confidentiality. In brief, since
the cryptography of the protocol takes ”authenticate-
then-encrypt” approach, the risks of eavesdropping at-
tacks are prevented. Furthermore, the establishment of
secure E2E connections between the source (BLE sen-
sor) and destination (CS) will eliminate the prerequisite
for the trustworthiness of the mobile relay.
MITM attacks can be imposed either on the link
between the BLE sensor and the mobile relay, or on
the link between the mobile relay and CS. In the first
scenario, a malicious relay mobile can collect the sensor
data, but it will not forward the collected traffic to the
CS. As explained in figure 3, the sensor node will not
delete the transmitted data until it receives an acknowl-
edgment from CS. If the sensor does not receive an
acknowledgment within a predefined timeout value, the
sensor will select another relay to transmit the data and
blacklist the malicious relay which is unable to complete
the transmission. Since we use E2E encryption between
the sensor node and the cloud server, it is not possible
for the mobile relay to generate an acknowledgement. In
the second case, a malicious relay can try to alter the
data or augment bogus data to receive extra rewards
from CS. Since we use E2E encryption between the
sensor node and the cloud server, it is not possible
for the relay node to generate new data or alter the
data without the consent of the cloud server. If the CS
notices such attempts by a relay node, it will blacklist
and remove the corresponding mobile relay from the
system. Furthermore, by including the timestamp values
to the messages generated by the sensor, the message
freshness is guaranteed and the CS will identify if there
is an attempt to impose replay attacks.
Identity tracking occurs when a malicious entity
associates the address of a BLE device with a specific
user and then physically tracks that user based on the
presence of the BLE device. These attacks are prevented
by periodically changing the BLE device address.
As the CS is responsible for storing sensor data
of different individuals, it becomes the most potential
attack point. The attackers will try to act as legitimate
sensors or relays. These kinds of impersonate attacks
can be also eliminated by using a strong authentication
process between the mobile and the CS. The application
running on the mobile should contain the login creden-
tials for authentication which are acquired during the
pre-registration phase with the CS. The pre-shared keys
between the sensor and the CS will also provide an
implicit authentication.
VII. CONCLUSIONS
Under the proliferation of low-power IoT technolo-
gies and their applications, universal accessibility is
a noteworthy attribute that needs to be possessed by
the sensors. Throughout this paper, we have addressed
how to provide such an ubiquity for the low-power
BLE sensors with the help of mobile relay nodes.
According to our experimental evaluations, the protocol
will successfully work even with the arrival of three
mobile users per an hour for the proximity of 120 m for
indoor and 9 m for outdoor environments. Finally, the
prototype implemented verified the technical readiness
of the proposed solution. Experiments revealed that
Texas Instrument sensor tag CC2650 can upload data
for 200 times without recharging the sensor. Moreover,
mobile phone uses only 1% battery power for one hour
of operation. As the future work, we intend to extend
the very same idea of exploiting mobile relay nodes
with drone technologies.
REFERENCES
[1] A. Al-Fuqaha, M. Guizani, M. Mohammadi, M. Aledhari, and
M. Ayyash, “Internet of things: A survey on enabling tech-
nologies, protocols, and applications,” IEEE Communications
Surveys & Tutorials, vol. 17, no. 4, pp. 2347–2376, 2015.
[2] N. Xia, H.-H. Chen, and C.-S. Yang, “Radio resource manage-
ment in machine-to-machine communications-a survey,” IEEE
Communications Surveys & Tutorials, 2017.
[3] J. Nieminen, C. Gomez, M. Isomaki, T. Savolainen, B. Patil,
Z. Shelby, M. Xi, and J. Oller, “Networking solutions for con-
necting bluetooth low energy enabled machines to the internet
of things,” IEEE network, vol. 28, no. 6, pp. 83–90, 2014.
[4] “Bluetooth Core Specification Version 5.0,” Bluetooth Special
Interest Group (SIG).
[5] Z. Shelby and C. Bormann, 6LoWPAN: The wireless embedded
Internet. John Wiley & Sons, 2011, vol. 43.
[6] H. Wirtz, T. Zimmermann, M. Serror, and K. Wehrle, “Collabo-
rative on-demand wi-fi sharing,” in 2015 IEEE 40th Conference
on Local Computer Networks (LCN), Oct 2015, pp. 19–27.
[7] S. Raza, P. Misra, Z. He, and T. Voigt, “Building the internet
of things with bluetooth smart,” Ad Hoc Networks, vol. 57, pp.
19–31, 2017.
[8] A. M. Rahmani, T. N. Gia, B. Negash, A. Anzanpour, I. Azimi,
M. Jiang, and P. Liljeberg, “Exploiting smart e-health gateways
at the edge of healthcare internet-of-things: a fog computing
approach,” Future Generation Computer Systems, vol. 78, pp.
641–658, 2018.
[9] M. Haus, A. Y. Ding, and J. Ott, “Managing iot at the edge:
The case for ble beacons,” in Proceedings of 3rd Workshop
on Experiences with the Design and Implementation of Smart
Objects, ser. MobiCom SMARTOBJECTS ’17. New York, NY,
USA: ACM, 2017, pp. 41–46.
[10] M. Gentili, R. Sannino, and M. Petracca, “Bluevoice: Voice
communications over bluetooth low energy in the internet of
things scenario,” Computer Communications, vol. 89, pp. 51–
59, 2016.
[11] S. R. Moosavi, T. N. Gia, E. Nigussie, A. M. Rahmani,
S. Virtanen, H. Tenhunen, and J. Isoaho, “End-to-end security
scheme for mobility enabled healthcare internet of things,”
Future Generation Computer Systems, vol. 64, pp. 108–124,
2016.
[12] S. Redmond, N. Lovell, G. Yang, A. Horsch, P. Lukowicz,
L. Murrugarra, and M. Marschollek, “What does big data mean
for wearable sensor systems?: Contribution of the imia wearable
sensors in healthcare wg,” Yearbook of medical informatics,
vol. 9, no. 1, p. 135, 2014.
[13] M. Hata, “Empirical formula for propagation loss in land mobile
radio services,” IEEE transactions on Vehicular Technology,
vol. 29, no. 3, pp. 317–325, 1980.
[14] X. Zhao, Z. Xiao, A. Markham, N. Trigoni, and Y. Ren, “Does
btle measure up against wifi? a comparison of indoor location
performance,” in Proceedings of 20th European Wireless Con-
ference. VDE, 2014, pp. 1–6.
