Opportunistic Routing towards Mobile Sink Nodes in Bluetooth Mesh

Networks

Marcelo Paulon J. V.

, Bruno Jos

e Olivieri de Souza

and Markus Endler

Pontif

ıcia Universidade Cat

olica do Rio de Janeiro (PUC-Rio), Brazil

Keywords:

Wireless Mesh Networks, Bluetooth Mesh, Mobile Sinks, Data Collection, Controlled Flooding, Flooding

Routing.

Abstract:

This work evaluates sporadic data collection on a Bluetooth Mesh network, using the OMNET++ INET sim-

ulator. The data collector is a roaming sink node, which could be a smartphone or other portable device,

carried by a pedestrian, a biker, an animal, or a drone. The sink node could connect to a mesh network in

hard-to-reach areas that do not have internet access and collect sensor data. After implementing Bluetooth

Mesh relay extensions, Low Power, and Friend features in OMNET++, we were able to propose and evaluate

algorithms for mobility-aware, adaptive, routing of sensor data towards the sink node. While the long-term

goal for this research is to implement the proposed algorithms on ESP32-based SoCs to monitor tree health,

so far, the preliminary simulated results already reveal some interesting ﬁndings. One variation of a proposed

routing algorithm achieved an 82.00% increase in unique data delivered to the sink node compared to Blue-

tooth Mesh’s default routing algorithm. In that case, there was a 5.45% decrease in energy consumption for

the same scenario. Also, the delivery rate increased by 58.22%.

1 INTRODUCTION

This work considers a scenario where several nodes

equipped with sensors are spread in one area of dif-

ﬁcult access, where each node monitors the health

of a tree with sensors attached to its trunk and fo-

liage, as well as some environmental variables such

as temperature and humidity in the proximity of the

tree. We further consider that sensor data accumu-

lated at each mesh node can be retrieved by a mobile

sink node (i.e., Mobile-Hub) when the sink gets suf-

ﬁciently close to the mesh node during its continuous

movement within the monitored arboretum mesh (i.e.,

MAM) region.

In any case, the goal is that the Mobile-Hub(s)

should be able to collect as much sensor data from

the whole network while on the move. But this re-

quires an agile routing of the sensor data in the WSN

towards the direction of the place where the Mobile-

Hub is currently ”having a rendezvous” with a mesh

node.

As can be seen, this use case faces not only

the challenges of intermittent connectivity (since the

https://orcid.org/0000-0002-8382-0957

https://orcid.org/0000-0002-1707-7755

https://orcid.org/0000-0002-8007-9817

Mobile-Hub is only sporadically connected to the

mesh network along its trajectory) but also of the en-

ergy constraints of the mesh network.

Bluetooth is a wireless technology that can be

used for WSNs and may be an interesting option since

most commercially available smartphones, as well as

many microcontroller devices and system-on-chip de-

vices (SoCs), support Bluetooth and its more recent

Low Energy features (Baert et al., 2018). One exam-

ple of an SoC that supports Bluetooth is the ESP32.

(Giacomini et al., 2020) describes the implementation

of a Bluetooth routing approach for IoT environments

using ESP32 SoCs.

One option for organizing Bluetooth networks is

by forming a mesh network with the Bluetooth Mesh

standard (Baert et al., 2018) (which will be referenced

as BTMesh in this paper). BTMesh’s latest version

(5.1) was ofﬁcially released in 2019 (Bluetooth SIG,

2019), and it tries to achieve more efﬁcient energy

draw when compared to other technologies such as

Wi-Fi and ZigBee. BTMesh routes packets across the

network by adopting a relay strategy that consists of

controlled ﬂooding.

This work aims to propose two alternatives

to BTMesh’s default relay algorithm (MAM

and

MAM

∆

) that may achieve higher packet delivery rates

Paulon J. V., M., Olivieri de Souza, B. and Endler, M.

Opportunistic Routing towards Mobile Sink Nodes in Bluetooth Mesh Networks.

DOI: 10.5220/0010557000670075

In Proceedings of the 18th International Conference on Wireless Networks and Mobile Systems (WINSYS 2021), pages 67-75

ISBN: 978-989-758-529-6

and lower energy draw when routing data towards

a Mobile-Hub. Those alternatives were evaluated

in a simulated data collection context, considering

BTMesh’s default relay algorithm (which this work

will call BTM-R from here on) as a benchmark.

The results indicate that one of the proposed al-

gorithms (MAM

∆

) achieves a higher packet delivery

rate to the Mobile-Hub when compared to BTM-R.

This delivery rate considers the number of unique data

packets received by the Mobile-Hub versus how many

packets were generated and sent by all other nodes.

This work also evaluated the global energy draw, the

number of packets received on the Mobile-Hub, and

the end-to-end delay (from each BTMesh sensor to

the Mobile-Hub). The MAM

∆

algorithm presented

lower end-to-end delay and received more unique data

packets than BTM-R. However, in some conﬁgura-

tions, it performed worse in terms of energy draw.

In the next section, we present related work in

BTMesh networking and data collection in wireless

sensor networks. Section 3 covers BTMesh and its

characteristics. Section 4 describes the proposed data

collection solution, explaining BTM-R, MAM

, and

MAM

∆

relay algorithms. Section 5 describes the sim-

ulation model and evaluation metrics, as well as the

simulations. Section 6 presents and discusses the sim-

ulation results. Section 7 concludes by presenting fu-

ture this works.

2 RELATED WORK

After the BTMesh speciﬁcation was released, some

studies and simulations for the BTMesh technology

have been explored, such as (Baert et al., 2018) (Leon

and Nabi, 2020) (Hansen et al., 2018). (Leon and

Nabi, 2020) analyses BTMesh in a real-world envi-

ronment and reports limitations for message delivery

as a result.

(Hansen et al., 2018) evaluate three relay selection

mechanisms with the intent of reducing the number of

relay nodes in the BTMesh network to reduce costs

while preserving a certain level of redundancy. Their

work is orthogonal to the present work, as it focuses

on the BTMesh network formation (in which the net-

work topology is deﬁned), whereas the present work

focuses on analyzing routing for data collection with-

out altering the BTMesh network topology.

The authors could not ﬁnd extensions of BTMesh

relay algorithms that could be directly compared to

the algorithms this work describes in Chapter 4 - this

is - simple extensions to BTMesh routing that can be

implemented on top of BLE. For instance, such exten-

sions can be implemented on a microcontroller with

BLE support without needing to alter BLE function-

ality.

BTMesh adopts a ﬂooding routing approach and

there is an extensive amount of published work on

this topic, with optimizations through concurrent-

transmission based ﬂooding (Mager and Zimmerling,

2016) (Ma et al., 2018) (Cheng et al., 2018) (Ma et al.,

2020). The Harmony algorithm (Ma et al., 2020)

was tested through experimental evaluation and, com-

pared to the state-of-the-art at the time of publication,

presented 50% higher delivery rates and shorter end-

to-end latencies in the presence of harsh Wi-Fi inter-

ference. However, such routing algorithms optimiza-

tions differ signiﬁcantly from the algorithms proposed

by this work, as they are not designed considering

Bluetooth compatibility. The advantage of preserv-

ing Bluetooth compatibility is to more easily imple-

ment and deploy applications, as many commercially

available devices such as smartphones and microcon-

trollers support Bluetooth (Baert et al., 2018).

(Djedouboum et al., 2018) studied the current

state of data collection in Wireless Mesh Sensor Net-

works and analyzed its challenges in the context of

Big Data. They also discussed the challenges of data

collection when mobility is involved, like contact de-

tection with mobile data collectors, quality of service

(QoS), and location detection. The MAM algorithms

do not cover quality of service and location detection,

which are out of the scope of the present work. How-

ever, contact detection is an important part of the rout-

ing process and the MAM algorithms would be de-

ﬁned in the context of their research as feature-based

routing protocols that rely on route discovery.

3 BLUETOOTH MESH

BTMesh is a mesh standard based on Bluetooth Low

Energy (BLE) that supports many-to-many communi-

cation using the wireless Bluetooth protocol.

The standard uses BLE-speciﬁc advertising and

scanning as underlying mechanisms to achieve

ﬂooding-like communication (Bluetooth SIG, 2016).

BTMesh ﬂooding ensures that some nodes in the net-

work, called Relay Nodes, repeat incoming messages

so that they are relayed further until their destination

is reached. Compared to conventional BLE advertis-

ing, BTMesh nodes do not send packets according to

advertising intervals but send their packets directly af-

ter a random generated back-off time per channel. To

scan the advertisement channels for incoming pack-

ets, the mesh nodes use a 100% duty cycle, mean-

ing that they are permanently scanning unless they are

sending a packet.

WINSYS 2021 - 18th International Conference on Wireless Networks and Mobile Systems

In order to prevent the obvious problems caused

by uncontrolled message ﬂooding, BTMesh intro-

duces relay cache features. Only nodes that have the

relay feature enabled (i.e., RNs) will forward received

messages to neighbor nodes. There is an LRU (least

recently used) cache on each relay node that stores

packet signatures and ensures a relay node only re-

lays a speciﬁc message once. Also, each message has

a Time-To-Live (TTL) ﬁeld that represents the num-

ber of hops. Messages are only relayed if they are not

in the cache, and the number of hops is less than 127

(the number 127 is deﬁned by the Bluetooth speciﬁ-

cation and corresponds to a 1-octet opcode).

The full-time duty cycle to scan the different BLE

advertisement channels directly impacts the node’s

energy consumption. The BTMesh standard tries to

solve this by introducing Friendship and Low Power

node features. A BTMesh Friend Node (i.e., FN) has

mainly two responsibilities: storing incoming mes-

sages for nearby Low Power Nodes (i.e., LPNs) and

sending those messages to the LPNs (LPNs periodi-

cally query their FNs for new messages).

With the Friendship feature, Low Power nodes

don’t need to stay permanently scanning the network

and can save battery power by keeping their radio

stack disabled most of the time. Thus, according to

the Bluetooth Mesh speciﬁcation, FNs can function

as intermediate storage and opportunistic relay nodes

for the other ”energy-restricted” mesh nodes that will

awake typically only for communication with some

FN during short periods to save energy.

Despite these advantages, BTMesh has two main

problems considering this work’s data collection sce-

nario (described in section 1):

• Network size limitation - message routing is ad

hoc, but performed through a controlled ﬂooding

approach that limits the number of hops to 127

(which could be insufﬁcient for a vast area net-

work application).

• Power consumption - although the ﬂooding ap-

proach results in some ﬂexibility in terms of han-

dling nodes’ neighbors change as well as low la-

tency (packets always get sent through the short-

est path), duplicate messages are sent through the

network and this impacts power consumption.

This work focuses on improving power consump-

tion for data collection scenarios using Bluetooth

Mesh, and does not try to overcome the Bluetooth

Mesh 127 hop limitation.

The network topology signiﬁcantly inﬂuences

how the network will behave, as deﬁning which nodes

are relay nodes, friend nodes, or low power nodes is

not done dynamically and, if not done correctly, can

make the network inefﬁcient and even disconnected

(by exceeding the hop limit from one node to another,

or by lack of relay nodes that can forward messages

between them). This work’s conﬁgured simulation

topologies, described in section 5, are connected net-

works with relay nodes, friend nodes, and low power

nodes.

4 PROPOSAL

This section describes the application of BTMesh

for collecting data using a Mobile-Hub as described

in section 1. The ﬁrst approach used the standard

BTMesh relay implementation (i.e., BTM-R) to direct

messages towards the Mobile-Hub. Also, this work

proposes two alternative relay algorithms for the spe-

ciﬁc scenario that is being discussed.

To collect data from the network, the Mobile-Hub

sends a discovery packet periodically (every 1 sec-

ond) while moving around the area. The discovery

packet is used to notify the nodes that there is a data

sink available to receive data, and those packets even-

tually reach every network node if they are received

by one of the network relay nodes, provided the relay

algorithm restrictions (e.g., BTM-R enforces a maxi-

mum hop limit). Once any node receives a discovery

packet, it should send its sensor data as well as any

stored sensor data towards the Mobile-Hub.

The BTM-R determines that the relay nodes only

consider the number of hops made so far and whether

they have already relayed the message, when evaluat-

ing if the message should be relayed.

The proposed alternatives to BTM-R only con-

sider the scenario that was described in section 1

(routing data towards a single Mobile-Hub). This is

an important difference between this work and alter-

native routing technologies for sensor networks that

cover routing from any node to another in the net-

work.

When describing alternative relay algorithms in

this section, this work will consider packets that are

not Discovery packets to be ”data packets”, which are

packets sent by the Mesh network nodes containing

sensor data that should be relayed to the Mobile-Hub.

Each subsection contains a pseudo-code with a

possible implementation of the described relay algo-

rithms. The code would be run on every relay node for

each packet they receive, and would receive as input:

the sender’s address (senderAddress), the number of

packet hops (messageHops), and the packet’s content

(messageBody). Global variables stored in the nodes,

available across local executions, are initialized in the

pseudo-code’s Init session.

Opportunistic Routing towards Mobile Sink Nodes in Bluetooth Mesh Networks

4.1 BTMesh Relay (BTM-R): Flooding

BTMesh’s original relay algorithm (BTM-R) consists

of a controlled ﬂooding approach (Bluetooth SIG,

2018). The algorithm combines two strategies to

manage the network ﬂooding:

1. limit the number of packet hops to 127 (corre-

sponds to a 1-octet opcode, as deﬁned by the spec-

iﬁcation);

2. avoid the same node relaying a packet multiple

times.

The pseudo-code Algorithm 1 illustrates BTM-R’s

implementation logic. Firstly it computes the packet

hash and checks if it is present on an LRU cache, stor-

ing this information on a variable named recentlyRe-

layed (lines 1 and 2).

If it was recently relayed (recentlyRelayed ==

true) or if the number of messages hops is greater

than 126, it stops executing, and the packet gets dis-

carded (lines 3-5). Otherwise, the number of message

hops is incremented and the packet is relayed through

a broadcast (lines 6 and 7).

Two noticeable problems with this approach are:

I) due to BTM-R routing approach, the messages may

get relayed excessively and delivered multiple times

since they are sent through every route possible. If

much data is coming from sensors, there may be com-

petition on multiple routes to deliver it. II) the 127

hop limit could be a problem depending on the nodes’

topology layout/distribution, possibly making certain

nodes unreachable to others.

Algorithm 1: BTMesh Relay (BTM-R).

Input: senderAddress, messageHops, messageBody

1: byte hash ← hashMessage(messageBody)

2: bool recentlyRelayed ← isInLRUCache(hash)

3: if (recentlyRelayed == true or messageHops >

126) then

4: return

5: end if

6: hops ← messageHops + 1

7: broadcastMessage(messageBody, hops)

4.2 MAM

: Last Known Route

The MAM

algorithm is the ﬁrst alternative routing

algorithm this work designed and evaluated as a vi-

able alternative to BTM-R for Mobile-Hub data rout-

ing. MAM

is based on a reactive routing strategy that

only uses BTM-R’s controlled ﬂooding approach for

Discovery packet propagation.

With the intent of maintaining a route to the

Mobile-Hub, each node sets the last known directly

connected node to have access to a Mobile-Hub. This

information is updated on every node upon each re-

ceived Discovery packet. With this approach, data

packets are then no longer broadcast but are sent to

a single node in each step.

The pseudo-code Algorithm 2 illustrates MAM

implementation. On every relay node, a global vari-

able bestNodeAddress is initialized as NULL. In

line 1, the algorithm checks if the packet is a Discov-

ery packet by looking at its body. If it is a Discovery

packet, the global variable bestNodeAddress gets set

to the packet sender address (line 2), the packet is re-

layed using BTM-R’s mechanism, and the execution

stops (lines 3-4).

If the packet is not a Discovery packet, the algo-

rithm assumes it is a Data packet that should be di-

rected towards a Mobile-Hub. Discovery packets are

only generated by the passing Mobile-Hub and may

be relayed by relay nodes further into the network.

The algorithm continues to execute if the incom-

ing packet is not a Discovery packet. It checks if the

global variable bestNodeAddress is set (line 6), and

if it is, the message gets sent to this address with an

incremented number of hops (lines 7-8).

This logic implies that if the variable

bestNodeAddress is not set, data packets will

not be relayed. Also, it implies that if it relays a data

packet, it will only be relayed to a single node. It was

designed with those characteristics in consideration,

with the intent of reducing the number of messages

propagated through the network and thus the overall

energy consumption.

Algorithm 2: MAM

- Last known route.

Init: bestNodeAddress ← NULL

Input: senderAddress, messageHops, messageBody

1: if (isDiscoveryMessage(messageBody) == true)

then

2: bestNodeAddress ← senderAddress

3: bluetoothMeshRelay(senderAddress, mes-

sageHops, messageBody)

4: return

5: end if

6: if (bestNodeAddress != NULL) then

7: hops ← messageHops + 1

8: sendMessage(bestNodeAddress, message-

Body, hops)

9: end if

WINSYS 2021 - 18th International Conference on Wireless Networks and Mobile Systems

4.3 MAM

∆

: Reactive Least-hop Route

The MAM

∆

algorithm also consists of a reactive rout-

ing approach, but it sets data packet routes to Mobile-

Hubs based on its distance (in hops) to the Mobile-

Hub. This distance is essentially the number of hops

it takes from each node until the Mobile-Hub.

This approach requires a way of knowing in ad-

vance the number of hops from each node to the

Mobile-Hub (and updating it often as this information

changes as the Mobile-Hub moves). This is achieved

through the discovery message packet hop informa-

tion.

Upon receiving a Discovery packet, the relay node

evaluates if the sender would be the best destination

for sending data to the Mobile-Hub. This evaluation

considers the number of hops, as well as an expiration

time.

The expiration time is called expiry and, when

expired, makes the next Discovery packet have its

sender set as the best node regardless of the number

of hops. This way, the best routes get preserved for

some time, but the logic accounts for them eventually

becoming old/invalid. A ∆ (milliseconds) parameter

is used to control this expiration’s length.

If the route is not expired and the number of hops

of an incoming Discovery packet is less than the best

one, then the algorithm considers it to be the new best

destination, and sets its state accordingly (storing the

new best sender address and number of hops and re-

setting the expiry/timeout).

The pseudo-code Algorithm 3 describes MAM

∆

’s

implementation.

The variable bestNodeAddress is the address

used to forward data packets, as the relay node con-

siders it to be the best node to reach the Mobile-Hub.

The variable bestNodeHops is the number of hops

from the current node to the Mobile-Hub. It is stored

to decide whether or not the best node should be up-

dated.

The variable expiry is the expiration time that

was previously described. Upon receiving a Discov-

ery packet, the algorithm will set the best node to the

packet sender if the current time is greater than expiry.

In line 1, it checks if the packet is not a Discovery

packet. If it’s not a discovery packet, then it will be

relayed if the best node is set (lines 2-5) and then ex-

ecution will stop regardless of the best node being set

or not (line 6).

If execution proceeds, it means the algorithm is

handling a discovery packet. In line 8, it checks

whether or not the current time is greater than ex-

piry, and sets this boolean value to a variable called

expired.

In line 9, it checks if the value of expired is true

or the number of hops is less than the value held

in the global variable bestNodeHops. If this check

is valid, the bestNodeAddress global variable is set

to the sender’s address (line 10), the bestNodeHops

global variable is set to the number of packet hops

(line 11), and the expiry global variable is set to the

current time plus the algorithm parameter ∆ (line 12).

Line 14 is the ﬁnal execution step run for all Dis-

covery packets, to relay them using the BTM-R’s

logic. Similarly to MAM

, Discovery packets are still

always relayed and Data packets are no longer broad-

cast (but get sent to a single node).

The advantage of MAM

∆

when compared to

MAM

is that MAM

∆

temporarily preserves routes

considering the distance to the Mobile-Hub. It was

designed with the goal of maintaining shorter routes

to the Mobile-Hub, which would imply a smaller en-

ergy consumption.

Algorithm 3: MAM

∆

- Reactive least-hop route.

Init: bestNodeAddress ← NULL, bestNodeHops ←

0, expiry ← 0

Input: senderAddress, messageHops, messageBody

1: if (isDiscoveryMessage(messageBody) == false)

then

2: if (bestNodeAddress != NULL) then

3: hops ← messageHops + 1

4: sendMessage(bestNodeAddress, message-

Body, hops)

5: end if

6: return

7: end if

8: bool expired ← NOW() > expiry

9: if (expired == true or messageHops <

bestNodeHops) then

10: bestNodeAddress ← senderAddress

11: bestNodeHops ← messageHops

12: expiry ← NOW() + ∆

13: end if

14: bluetoothMeshRelay(senderAddress, message-

Hops, messageBody)

5 SIMULATION

The simulations rely on OMNET++ INET framework

v5.6.1, an open-source model suite for simulating

wired, wireless and mobile networks. For the best

of our knowledge, the INET framework lacks any

ofﬁcial implementation of the BTMesh standard and

BLE. (Kajdocsi et al., 2019) describe a BTMesh par-

tial implementation using the OMNET++ framework,

Opportunistic Routing towards Mobile Sink Nodes in Bluetooth Mesh Networks

however, the authors state that their simulation model

made it impossible to evaluate a network with more

than 30 nodes, and also it did not contain one of

BTMesh’s core features, Friend Nodes.

The goal of this work’s simulations is to evaluate

the feasibility and the performance of the proposed

variants of relay algorithms in a data collection sce-

nario with one Mobile-Hub - initially with 50 ﬁxed

nodes and then a conﬁgurable number of nodes.

This work involved creating a model that sup-

ported those initial requirements (50 nodes and

BTMesh Friendship), and this was achieved by using

INET’s IEEE 802.15.4 model as a base, to be used

across all simulations. This standard was chosen as it

deﬁnes low-rate wireless personal area networks (LR-

WPANs) like ZigBee, which has similar features to

BLE. This work’s simulation model has the following

characteristics that make it similar to BTMesh:

(a) maximum transmission range = 100 meters

(b) transmission rate = 1 Mbps (BTMesh’s transmis-

sion rate)

lay+Friend

The following metrics were collected and used to

compare the different Relay Algorithms described in

section 4:

• End-to-end delay (ms): the elapsed time in mil-

liseconds from the moment a packet is sent by the

source (sensor node) until the packet arrives at the

Mobile-Hub.

• Delivery rate (%): the delivery rate of all of the

generated data packets to the Mobile-Hub, this

means the number of successfully delivered pack-

ets to a Mobile-Hub divided by the total number

of sent data packets, multiplied by 100.

• Mobile-Hub received packets (bytes): the amount

in bytes of received packets. The charts distin-

guish between unique and repeated data.

• Energy Draw (Joules): the amount of energy that

was drawn, by all of the network nodes.

BLE advertising packets, the type of packet used

by BTMesh, only implement a simple collision avoid-

ance mechanism. It changes the advertising channels

sequentially and also has a random delay between 0

and 10ms for consecutive sends on the same channel,

according to Bluetooth Core v5.0 speciﬁcation (Blue-

tooth SIG, 2016). On Bluetooth Core v5.1 speciﬁ-

cation (Bluetooth SIG, 2019), collision avoidance is

slightly improved by allowing advertising channels to

be chosen at random instead of sequentially.

This work’s simulations account for the possibility

of packets being lost, with a radio interference model

Figure 1: Average delay comparison between BTM-R and

MAM relay with least-hop route.

and CSMA/CA simulation as well as a Mobile-Hub

movement model. The radio layer was imported from

INET’s 802.15.4 model, which uses CSMA/CA not

BTMesh’s simpler collision avoidance approach. The

movement model was imported from INET, called

CircleMobility (Varga, 2020), in which the node sim-

ply moves around a circle at a ﬁxed speed. For this

work’s 50 node-simulation, a ﬁxed radius of 400 me-

ters and a constant speed of 14 m/s were used.

For the MAM

∆

algorithm, the simulations varied

the algorithm’s ∆ parameter.

Varying execution time was not very signiﬁcant in

the context of this work, since it is comparing relay

algorithms. The execution time only needed to be big

enough for the Mobile-Hub to visit some of the nodes

and for some of the routes be overridden according to

the ∆ parameter.

Each simulation was run for 200 seconds, which

is the default for OMNET++’s simulations. The net-

work was composed of 13 LPNs and 37 FNs (with all

FNs being Relay Nodes), and a single Mobile-Hub

that circled around the mesh nodes. This map was

manually generated by the authors, and is a connected

network. The following variations values were tested:

Delta (in milliseconds) 5, 10, 20, 50, 100, 500

The Mobile-Hub’s circular trajectory was across

a 400 meters radius, at a constant speed of 14 m/s

(equivalent to a quadcopter), and covered only a sub-

set of the network nodes. The Mobile-Hub connected

to 10 Relay Nodes (20% of all network nodes).

WINSYS 2021 - 18th International Conference on Wireless Networks and Mobile Systems

Figure 2: Energy Draw (Joules).

6 RESULTS

This section presents the four evaluated metrics in the

next subsections.

6.1 End-to-End (Sensors to Sink) Delay

Figure 1 shows the end-to-end delay (from the mo-

ment data packets are sent by the source node un-

til they reach the Mobile-Hub) in milliseconds. The

chart shows the results, presented as box plots, for

BTM-R, MAM

, and MAM

∆

with varied ∆ values.

Each box plot representing the data includes the 25%

quartile (Q1), median (marked in red), and the 75%

quartile (Q3). Outliers have been omitted to facilitate

visualization. Higher values indicate that the delay

was greater, which means that messages took more

time to be delivered to the Mobile-Hub.

BTM-R’s median was of 42ms while MAM

’s me-

dian was of 45ms. However, all of MAM

∆

’s medians

were lower than BTM-R’s, with the best one being

30ms. Those results indicate that MAM

performs

worse in terms of end-to-end delay when compared

to BTM-R, and that the MAM

∆

algorithm performed

better than BTM-R and MAM

6.2 Energy Draw

Figure 2 presents the energy draw of all Mesh nodes

in Joules. The values were aggregated as a sum, in

which the Mobile-Hub energy draw was neglected,

Figure 3: Delivery Rate (%).

and are displayed on a bar chart. The horizontal

axis presents each relay algorithm that was used, and

the vertical axis contains the energy draw values in

Joules. Higher values indicate that more energy was

consumed, however, this is not necessarily an indica-

tor of worse overall performance since more messages

could have been sent or the simulation presented a

higher packet delivery rate. On each alternate algo-

rithm bar, there is a percentage indicating the percent-

age comparison between each value and BTM-R’s.

The results (Figure 2) show that MAM

energy

draw was as low as 16.87% less than BTM-R’s. The

chart indicates that the lowest energy draw for the

tested scenarios was with the MAM

∆

algorithm with ∆

= 5, 17.07% less than BTM-R. For MAM

∆

with ∆=50,

most energy was consumed among the alternative al-

gorithms, 4.2% less than BTM-R. Those results indi-

cate that all the proposed alternatives consumed less

energy than BTM-R; however, the energy consump-

tion varied according to the algorithm’s ∆ parameter.

6.3 Delivery Rate

Figure 3 presents the delivery rate (to the Mobile-

Hub) of all Mesh nodes data packets, in percentage.

The values consider the amount of unique data pack-

ets received divided by the amount of unique data

generated by each sensor node. The horizontal axis

presents each relay algorithm that was used, and the

vertical axis contains the delivery rate percentage val-

ues. Higher values indicate that more unique mes-

sages were delivered successfully to the Mobile-Hub.

On each alternate algorithm bar, there is a percentage

indicating the percentage comparison between each

value and BTM-R’s.

Opportunistic Routing towards Mobile Sink Nodes in Bluetooth Mesh Networks

The results (Figure 3) show that MAM

deliv-

ery rate was 16.26%, which is 40.39% lower than

BTM-R’s 27.29% rate, and it was the lowest deliv-

ery rate among all others tested scenarios. For MAM

∆

with ∆=500, the delivery rate was 43.18%, the high-

est among the tested scenarios, 58.22% greater than

BTM-R. Those results indicate that, for the tested

scenarios, the proposed alternatives can also achieve

higher and lower delivery rates when compared to

BTM-R, depending on how the alternative algorithms

are parameterized.

Figure 4: Packets received comparison between BTM-R

and MAM

∆

with least-hop route.

6.4 Received Packets

Figure 4 presents the amount of data packets received

by the Mobile-Hub, in bytes. The values consider the

amount of unique data packets received and display

them on a bar chart indicating how many of them were

duplicates (if any). The horizontal axis presents each

relay algorithm that was used, and the vertical axis

contains the amount of data packets in bytes. Higher

values indicate that more messages were received by

the Mobile-Hub; however, unique values are painted

in blue and repeated values in red. On each alternate

algorithm bar, there is a percentage indicating the per-

centage comparison between each unique value por-

tion and BTM-R’s unique value portion.

The results (Figure 4) show that on the BTM-

R simulation, the Mobile-Hub collected 9.1k unique

bytes and a total of 18.4k bytes of data. Thus, in this

simulation, 50.5% of the collected data were dupli-

cate packets. MAM

received 6.79k bytes of unique

data packets, which is 25.36% lower than BTM-R’s,

and it was the algorithm with the lowest amount of

unique data received among all other tested scenar-

ios. For MAM

∆

, with ∆=5, the Mobile-Hub collected

7.92k bytes of unique data, 13.04% less than BTM-R.

For all other tested ∆ values, results presented a higher

amount of unique data packets collected when com-

pared to BTM-R. With ∆=500, the amount of unique

data received was 16.57k bytes, the highest among the

simulations, 82% greater than BTM-R. Those results

indicate that the proposed alternatives can achieve

higher and lower amounts of unique data packets re-

ceived by the Mobile-Hub when compared to BTM-

R, depending on how the alternative algorithms are

conﬁgured. Also, it indicated that MAM

and all

tested MAM

∆

algorithms did not result in the deliv-

ery of duplicated data packets to the Mobile-Hub.

6.5 Analysis and Tradeoffs

Compared to BTM-R, MAM

consumed less energy

in the tested scenarios (-16.87%) and lower end-to-

end delay in most cases. However, delivery rate (Fig-

ure 3) was lower compared to BTM-R (-40.39%).

Also, the received packets in bytes values were lower

than BTM-R’s (-25.36%). This indicates that, overall,

BTM-R outperforms MAM

The MAM

∆

algorithm was tested with different ∆

values. For ∆=5, the delivery rate was lower than

BTM-R’s in the tested scenarios (-28.50%). The

received packets in bytes were 13.04% lower than

BTM-R. The energy draw was lower than BTM-R’s

in the tested scenarios (-17.07%). This indicates that,

in most cases, BTM-R outperforms MAM

∆

with ∆=5.

For ∆=10, the delivery rate was lower than

BTM-R’s (-0.92%). The received packets in bytes

were higher than BTM-R in the tested scenarios

(+21.74%). The energy draw was lower than BTM-

R’s in the tested scenarios (-13.29%). This indicates

that MAM

∆

with ∆=10 outperforms BTM-R in terms

of amount of data collected and energy draw, how-

ever, performs worse regarding delivery rate.

For higher ∆ values (>= 20.0), MAM

∆

presented

delivery rates that were higher than BTM-R in the

tested scenarios. The highest ∆ value that was sim-

ulated (∆=500) presented the highest delivery rates:

43.18% (a 58.22% increase compared to BTM-R’s

rate). In all tested cases, the energy draw was lower

compared to BTM-R. The scenario that consumed

most energy (∆=50) represents only a 4.20% energy

draw decrease compared to BTM-R, with a 43.87%

delivery rate increase, and a 76.45% received pack-

ets in bytes increase. However, in some cases in

which the energy draw was lower, the delivery rate

WINSYS 2021 - 18th International Conference on Wireless Networks and Mobile Systems

and amount of unique received packets in bytes was

also lower (MAM

and MAM

∆=5

The results indicate that, with the correct tuning

(∆ parameter), MAM

∆

may achieve a signiﬁcantly

better performance compared to MAM

and BTM-

R in terms of unique received packets and delivery

rate, as well as energy efﬁciency (when we consider

the amount of energy drawn proportionally to the

higher delivery rates and higher unique data packets

received).

7 CONCLUSION AND FUTURE

WORK

This work proposed two alternative approaches to re-

laying messages in BTMesh networks to a mobile

sink node named Mobile-Hub. The proposed ap-

proaches were implemented and evaluated with the

BTMesh standard model on a simulator (OMNET++

INET framework) by executing multiple simulations

to collect the desired metrics: energy draw, Mobile-

Hub data delivery rate, Mobile-Hub amount of data

received, and end-to-end delay (time elapsed from the

sensor node data being sent to the network until it

reaches the Mobile-Hub).

The preliminary results show that one of the pro-

posed relay algorithms, MAM

∆

, achieved betters re-

sults in all of the evaluated metrics when compared to

BTMesh’s default relay algorithm (BTM-R).

Extending the MAM

∆

algorithm to handle multi-

ple Mobile-Hubs and heterogeneous data collection

by type (e.g., multiple Mobile-Hubs, that subscribe to

different data types) should be an exciting path to ex-

plore as a ramiﬁcation of this work.

Experimenting with different mobility types, as

well as running simulations with different network

topologies varying the number of nodes as well as

FN/LPN densities should also bring interesting results

and discussions. Field tests using microcontrollers

with sensors and a quadcopter as Mobile-Hub are also

in the roadmap for this research.

ACKNOWLEDGEMENTS

This study was ﬁnanced in part by AFOSR grant

FA9550-20-1-0285.

REFERENCES

Baert, M., Rossey, J., Shahid, A., and Hoebeke, J. (2018).

The Bluetooth Mesh Standard: An Overview and Ex-

perimental Evaluation. Sensors, 18(8):2409.

Bluetooth SIG, I. (2016). Bluetooth core speciﬁcation ver-

sion 5.0.

Bluetooth SIG, I. (2018). An intro to bluetooth mesh part

2. URL: https://www.bluetooth.com/blog/an-intro-to-

bluetooth-mesh-part2/.

Bluetooth SIG, I. (2019). Bluetooth core speciﬁcation ver-

sion 5.1 feature overview.

Cheng, L., Niu, J., Luo, C., Shu, L., Kong, L., Zhao, Z., and

Gu, Y. (2018). Towards minimum-delay and energy-

efﬁcient ﬂooding in low-duty-cycle wireless sensor

networks. Computer Networks, 134:66–77.

Djedouboum, A., ARI, A., Gueroui, A., Mohamadou, A.,

and Aliouat, Z. (2018). Big data collection in large-

scale wireless sensor networks. Sensors, 18.

Giacomini, E., D’Alterio, F., Lacava, A., and Cuomo, F.

(2020). Blues: A self-organizing ble mesh-network

paradigm for iot environments. In 2020 IEEE 21st In-

ternational Symposium on ”A World of Wireless, Mo-

bile and Multimedia Networks” (WoWMoM), pages

409–414.

Hansen, E. A. J., Nielsen, M. H., Serup, D. E., Williams,

R. J., Madsen, T. K., and Abildgren, R. (2018). On

relay selection approaches in bluetooth mesh net-

works. In 10th International Congress on Ultra Mod-

ern Telecommunications and Control Systems and

Workshops (ICUMT), pages 1–5.

Kajdocsi, L., D

omb

ozi, A., and Kov

acs, J. (2019). Devel-

opment of bluetooth mesh core stack using omnet++.

In 2019 IEEE 17th International Symposium on Intel-

ligent Systems and Informatics (SISY), pages 23–28.

Leon, E. D. and Nabi, M. (2020). An experimental per-

formance evaluation of bluetooth mesh technology for

monitoring applications. In 2020 IEEE Wireless Com-

munications and Networking Conference (WCNC),

pages 1–6.

Ma, X., Zhang, P., Li, X., Tang, W., Wei, J., and

Theel, O. (2018). DeCoT: A dependable concurrent

transmission-based protocol for wireless sensor net-

works. IEEE Access, 6:73130–73146.

Ma, X., Zhang, P., Liu, Y., Boano, C. A., Kim, H. S., Wei, J.,

and Huang, J. (2020). Harmony: Saving Concurrent

Transmissions from Harsh RF Interference. Proceed-

ings - IEEE INFOCOM, 2020-July:1024–1033.

Mager, F. and Zimmerling, M. (2016). Mixer. PCI-Paint

and Coatings Industry, 2016(AUGUST).

Varga, A. (2020). Circlemobility - inet framework.

URL: https://doc.omnetpp.org/inet/api-current/ ned-

doc/inet.mobility.single.CircleMobility.html.

Opportunistic Routing towards Mobile Sink Nodes in Bluetooth Mesh Networks