Instructions to authors for the preparation of manuscripts

Data 
Results 
Total size of data 
33686 Bytes 
Average size of data 
29.02 Bytes 
Minimum number of data storage operations 
11500 
Minimum number of data retrieval operations 
11553 
Data storage delay 
< 1 min 
Data retrieval delay 
< 5s 
3. INSTRUMENTATION OF THE COMMUNICATING 
PRECAST CONCRETE
In this section, the appropriate micro-node is firstly presented 
for the communicating precast concrete instrumentation.
Then, a study of the nodes density inside the concrete is 
detailed. 
3.1. Micro-node for communicating precast concrete 
In this paper, the proposed communicating precast concrete is 
equipped with micro-sensor nodes which are very small and 
could be integrated in a precast without modifying either its 
properties or its appearance as shown in figure 2 (i.e. a 
uniform nodes deployment is used in the concrete). 
Currently, several researches focus on miniaturization of 
electronic components for sensor nodes (Kuncoro, 2014) 
such as 
μPart
, 
ECO
, 
ZN1
, 
SAND
, 
SensorCube
, and 
Tyndall
. 
SAND
, 
μPart
, and 
Tyndall
are the micro nodes with the 
smallest size (1 cm
3
). However, 
μPart
node has no reception 
functionality (only data transmission node) and does not 
allow multi-hop communication. In addition, 
Tyndall
and 
SAND
are very limited lifetime nodes (in average 10 hours 
and 432 hours, respectively) and require continuous battery 
charging which seems difficult when the node is embedded in 
the concrete.
However, the 
SensorCube
node has several advantages 
compared to 
ZN1
and 
ECO
. First, 
SensorCube
provides 
temperature and humidity sensors required by the concrete 
monitoring during the BOL and the MOL. Moreover, it 
provides good memory size (120 Kbyte), and it can store all 
the generated data during the precast concrete lifecycle 
(33686 bytes, see table 1). Also, it has the advantage of 
providing a packaged system being fully reconfigurable. 
Each module has a specific functionality, such as transceiver, 
micro-controller, power supply or sensors. Its modular nature 
lends itself to the development of a variety of layers for use 
in different application scenarios. In addition, the 
SensorCube
node could be equipped with many different energy resources 
such as battery and energy scavenging module, which would 
increase its autonomy. 
For all these benefits, the 
SensorCube
node was chosen for 
communicating precast concrete. In this paper, this node is 
modelled in Castalia simulator. 
Micro sensor node
Wireless connection 
Fig. 2. Communicating precast concrete using micro-nodes. 
3.2. Nodes density inside the precast concrete 
In (Mekki et al., 2016d), the density of nodes inside the 
precast concrete is studied for the best performance of 
uniform data storage using USEE protocol and for the best 
reliability of RaWPG protocol, through statistics and 
simulation studies. Authors in (Mekki et al., 2016d) suppose 
that if the data is stored at least once in each neighbourhood 
in the WSN, the data certainly exist throughout all the 
concrete precast (i.e. throughout all the building). They show 
that the greater the number of nodes 
n
in each 
neighbourhood, the higher the probability of finding the 
information in each neighbourhood. The probabilistic study 
was validated by simulation. For this, a communicating 
precast concrete was simulated. All the nodes are uniformly 
deployed within a 20m×20m square. Different numbers of 
nodes 
n
in the neighbourhood are simulated: 9, 15, 25, 37, 
and 45. Authors show that the disseminated data is present in 
all the neighbourhood of almost all the nodes inside the 
concrete (more than 80% and 90% of neighbourhoods 
contain the data) for storage probabilities more than 0.2 and 
for 
n
= 25, 
n
= 37, and 
n
= 45. However, the data existence 

---

probability in the neighbourhood is very low for a small 
number of neighbours 
n
= 9 (between 31% and 62%) and 
n
= 
15 (between 47% and 85%). In conclusion, a large number of 
nodes 
n
in each neighbourhood in the WSN increases the 
probability of finding data in all parts of the precast concrete 
(i.e. all parts of the building). 
As presented in the introduction, RaWPG protocol uses TTL 
parameter to limit the retrieval path length. In (Mekki et al., 
2016d), the maximum length of TTL is studied through 
statistics tools using the data existence probability in the 
neighbourhood as parameter. The path length is studied for 
different data existence probabilities 
ps
in neighbourhood. 
Authors in (Mekki et al., 2016d) show that for the probability 
0.8<
ps
<1 of 
n
=45, TTL should be fixed to 4. For the 
probability 0.7<
ps
<1 of 
n
=37, TTL should be fixed to 5. For 
the probability 0.6<
ps
<1 of 
n
=25, TTL should be fixed to 8. 
4. DATA STORAGE AND RETRIEVAL DURING THE 
PRECAST CONCRETE LIFECYCLE 
In this section, USEE and RaWPG protocols are evaluated 
through simulation on the case study of the precast concrete 
lifecycle. In this simulation, the neighbourhood nodes density 
n
=25 and TTL=8 are used as recommended in (Mekki et al., 
2016d) for the best performance of USEE and RaWPG. 
4.1. Simulation parameters 
The protocols were implemented in Castalia simulator. The 
simulated precast concrete consists of 2500 nodes. All the 
node positions are uniformly distributed within a 20m×20m 
square (
n 
= 25 nodes in each neighbourhood). T-MAC, a 
contention-based medium access control protocol is used as 
MAC protocol. Wireless radio channel characteristics such as 
signal noise, interference ratio, and average path loss are 
chosen to simulate the realistic modelled radio wireless 
channel in Castalia based on lognormal shadowing and the 
additive interference models. The maximum size of each data 
is fixed to 30 bytes (i.e. 30 bytes = average lifecycle data size 
as shown in table 1).
4.2. Data storage performance 
In the following, USEE is evaluated in terms of storage 
uniformity, storage capacity, and average delay. 
4.2.1. Uniformity and quality of data distribution in the 
precast concrete 
To perform this experiment, the simulated precast is divided 
into 100 cells as shown in figure 3, illustrating a 
dissemination experiment. In this figure, the red point 
corresponds to the node sending the data, called the “master 
node”. This is the node initially receiving data sent from the 
user. Each black point on the grid corresponds to a node that 
has stored the data. 
This experience gives us an idea on how well USEE protocol 
distributes the information over the entire simulated precast 
concrete. Figure 4 presents the existence ratio of the 
information in the cells. It shows that USEE has a uniform 
data dissemination which corresponds to a good data 
distribution: the information exists in 100% of cells (in all