Benjamin Elizalde

Anurag Kumar

Ankit Shah

Rohan Badlani

Emmanuel Vincent
email: emmanuel.vincent@inria.fr

Bhiksha Raj
email: bhiksha@cs.cmu.edu

Ian Lane
email: lane@cmu.edu

Experiments on the DCASE Challenge 2016: Acoustic scene classification and sound event detection in real life recording

Keywords: audio, scenes, events, features, segmentation, DCASE, bag of audio words, GMMs, sound event detection, acoustic scene classification

ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Audio plays a critical role in understanding the environment around us. This makes audio content analysis research important for tasks related to multimedia [START_REF] Cheng | Srisarnoff aurora system at trecvid 2012: Multimedia event detection and recounting[END_REF][START_REF] Jiang | Fast and accurate content-based semantic search in 100m internet videos[END_REF], and human computer interaction [START_REF] Chu | Where am i? scene recognition for mobile robots using audio features[END_REF][START_REF] Janvier | Sound-Event Recognition with a Companion Humanoid[END_REF] to mention a pair. However, unlike the field of computer vision which has a variety of standard publicly available datasets such as Imagenet, audio event/scene analysis lacks such large dataset. This makes it difficult to compare different approaches and establishing the state of art. The second iteration of DCASE [START_REF] Mesaros | TUT database for acoustic scene classification and sound event detection[END_REF], occurring in 2016, offers an opportunity to compare approaches on a standard public dataset. This edition it includes four different tasks: acoustic scene classification, sound event detection-real and synthetic audio, and audio tagging.

The state-of-the-art of the previous DCASE challenge, for both acoustic scenes [START_REF] Roma | Recurrence quantification analysis features for auditory scene classification[END_REF][START_REF] Rakotomamonjy | Histogram of gradients of time-frequency representations for audio scene classification[END_REF][START_REF] Schröder | On the use of spectro-temporal features for the ieee aasp challenge detection and classification of acoustic scenes and events[END_REF] and sound event detection [START_REF] Roma | Recurrence quantification analysis features for auditory scene classification[END_REF][START_REF] Schröder | On the use of spectro-temporal features for the ieee aasp challenge detection and classification of acoustic scenes and events[END_REF][START_REF] Gemmeke | An exemplar-based nmf approach to audio event detection[END_REF], attributed their success mainly to features and audio representations rather than classifiers. Hence, an important aspect in our work is to emphasize on classifier exploration along with features. In this paper we present our work performed on Task 1 and Task 3. We proposed a variety of methods for both tasks and we obtained significant improvement over the baseline methods.

2. TASKS AND DATA The goal of Task 1, Acoustic Scene Classification, is to classify a test recording into one of predefined classes that characterizes the environment in which it was recorded for example park, home, office. TUT Acoustic Scenes 2016 dataset is used for this task. It consists of recordings from various acoustic scenes. For each recording location, a 3-5 minute long audio recording was captured. The original recordings were then split into 30-second segments for the challenge. There are 15 acoustic scenes for the task.

Task 3, Sound Event Detection in Real Life Recordings, evaluates performance of sound event detection in multi-source condi-tions similar to our everyday life. There is no control over the number of overlapping sound events at each time, not in the training nor in the audio data. TUT Sound Events 2016 dataset is used for Task 3, which consists of recordings from two acoustic scenes: Home and Residential Area. There are 18 selected sound event classes, 11 for Home and 7 for Residential Area.

TASK 1: ACOUSTIC SCENE CLASSIFICATION

From machine learning perspective, we treated Task 1 as a multiclass classification problem. The first step is to use a suitable method for characterizing acoustic scenes in the audio segments. An effective approach for characterizing audio events is bag-ofaudio-words based feature representation [START_REF] Li | The perceived position of moving objects: Transcranial magnetic stimulation of area MT+ reduces the flash-lag effect[END_REF], which is usually built over low-level features such as MFCCs. Acoustic scenes, however, are more complex mixtures of different audio events and a more robust representation is required. To obtain a more robust representation we use Gaussian Mixture Models (GMMs) for feature representations of audio segments. Broadly, we employed two high-level feature representations to represent audio scenes. On the classification front we used Support Vector Machines (SVMs) as our primary classifier and in combination with other classifiers.

Feature Representations

Let D-dimensional MFCCs vectors for a recording be represented as xt, where t = 1 to T , T is the total number of MFCCs vectors for the recording. The major idea behind both high-level feature representation is to capture the distribution of MFCCs vectors of a recording. We will refer to these features as α and β features and the sub-types will be represented using appropriate subscripts and superscripts.

The first step in obtaining high-level fixed dimensional feature representation for audio segments is to train a GMM on MFCC vectors of the training data. Let us represent this GMM by G = {w k , N ( µ k , Σ k ), k = 1 to M }, where w k , µ k and Σ k are the mixture weight, mean and covariance parameters of the k th Gaussian in G. We will assume diagonal covariance matrices for all Gaussians and σ k will represent the diagonal vector of Σ k . Given the MFCCs vectors xt of a recording, we computed the probabilistic assignment of xt to the k th Gaussian. These soft assignments are added over all t to obtain the total mass of MFCCs vectors belonging to the k th Gaussian (Eq 1). Normalization by T is used to remove the effect of the duration of recordings.

P r(k| x

t ) = w k N ( x t ; µ k ,Σ k ) M j=1 w j N ( x t ; µ k ,Σ k ) , P (k) = 1 T T i=1 P r(k| x t ) (1)
The soft count histogram features referred to as α is, α M = [P (1), ..P (k)..P (M )] T . α M is an M -dimensional feature representation for a given recording. It captures how the MFCC vectors of a recording are distributed across the Guassians in G. α M is normalized to sum to 1 before using it for classifier training.

The next feature ( β), also based on the GMM G, tries to capture the actual distribution of the MFCC vectors of a recording. This is done by adapting the parameters of G to the MFCC vectors of the recording. We employ maximum a posteriori (MAP) estimation to for the adaptation [START_REF] Gauvain | Maximum a posteriori estimation for multivariate gaussian mixture observations of markov chains[END_REF] [START_REF] Bimbot | A tutorial on text-independent speaker verification[END_REF]. Parameter adaptation for k th Gaussian follows the following steps. First we compute,

nk = T t=1 P r(k| xt), Ek( x) = 1 n k T t=1 P r(k| xt) xt, Ek( x 2 ) = 1 n k T t=1 P r(k| xt) x 2 t (2)
Finally, the updated mean and variances are obtained as

ˆ µ k = n k n k + r E k ( x) + r n k + r µ k (3)
ˆ σ k = n k n k + r E k ( x 2 ) + r n k + r ( σ 2 k + µ 2 k ) -ˆ µ 2 k ( 4
)
The relevance factor r controls the effect of the original parameters on the new estimates. We obtain 2 different feature representation using the adapted means ( ˆ µ k ) and variances ( ˆ σ k ). The first one denoted by β M is an M ×D dimensional feature obtained by concatenating the adapted means ˆ µ k for all k, that is

β M = [ ˆ µ T 1 , ... ˆ µ T K ] T .
In the second β features adapted ˆ σ k are concatenated along with ˆ µ k to obtain a 2×M ×D dimensional features. This form of β features are denoted by β M σ .

Classification

Once the feature representation for audio segments have been obtained, Task 1 essentially becomes a multi-class classification problem. Our primary classifiers are SVMs where we explore a variety of kernels. For the β features, we use Linear Kernel (LK) and RBF Kernel (RK). For soft-count histogram α features we explore a panoply of kernels. Along with LK and RK we explored the following kernels.

• Exponential χ 2 Distance (ECK): the kernel is computed as

K( x, y) = exp -γD( x, y) , where D( x, y) = i (xi - yi) 2 /(xi + yi) is χ 2 distance. • χ 2 Kernel (CK): In this case K( x, y) = i 2x i y i x i +y i • Intersection Kernel (IK): K( x, y) = i min(xi, yi) • Exponential Hellinger Distance Kernel (EHK): K( x, y) = exp -γD( x, y) where D( x, y) = i ( √ xi - √ yi) 2 • Hellinger Kernel (HK): ( x, y) = i √ xiyi
The details of these kernels can be found in [START_REF] Zhang | Local features and kernels for classification of texture and object categories: A comprehensive study[END_REF][START_REF] Vedaldi | Efficient additive kernels via explicit feature maps[END_REF][START_REF] Li | Sign cauchy projections and chi-square kernel[END_REF]. For kernels where γ term appears, the optimal value of γ value can be obtained by cross validation over training data. However, setting γ equal to the inverse of average distance D( x, y) between training data points works well in general as well. We use [16] [17] for SVM implementation.

Finally, we have a classifier fusion step where we combined the output of the different classifiers. We combined multiple classifiers by taking prediction vote from each classifier and the final predicted class is the one which gets the maximum vote. We call it the Fused Classifier and we observed that the fused classifier can give significant improvement for several acoustic scenes. The accuracy for the MFCC-GMM baseline method provided in the challenge is 72.6%.

We can observe from Table 1 that α features in general do not perform better than the baseline method for any SVM kernel. However, β features clearly outperformed baseline method. In the best case, with M = 128 and β M σ our method outperformed the baseline by an absolute 5%.

Table 2 shows results for the fused classifiers. For the fusion step we did not consider classifiers built over α since these classifiers are inferior compared to those using β features. We can observe that our proposed method beats the baseline method by an absolute 6.3%. Moreover, for scenes such as Park, Train, Library where the baseline method gives very poor results, we improved the accuracy by an absolute 16 -30%. We also obtained superior overall accuracy on all folds which suggests that our proposed method is fairly robust. This is further supported by the fact that on DCASE evaluation set, We achieved an overall accuracy of 85.9%.

TASK 3: SOUND EVENT DETECTION IN REAL LIFE RECORDINGS

Detection of sound events in scenes and long recordings have been treated as a multi-class classification problem before in [START_REF] Elizalde | Audio-concept features and hidden markov models for multimedia event detection[END_REF][START_REF] Elizalde | Lost in segmentation: Three approaches for speech/non-speech detection in consumerproduced videos[END_REF][START_REF] Elizalde | There is No Data Like Less Data: Percepts for Video Concept Detection on Consumer-Produced Media[END_REF] where a classifier is trained with the sound segments. For testing, the classifier outputs segment/frame-level predictions for all the classes. In order to follow a similar approach, first we wanted to analyze features' performance for sound events regardless of the scene. This way, we could have an intuition of performance on the harder scenario of Task 3 where not every segment of the scene corresponds to a labeled sound event.

Features and Classifiers Optimization

For the features we tried the conventional MFCCs with standard parameters such as 12 coefficients plus energy, delta and double delta for a total of 39 dimensions. Moreover, we explored three features addressing the time-frequency acoustic characteristics. The Gabor Filter Bank (GBFB) in [START_REF] Schädler | Spectrotemporal modulation subspace-spanning filter bank features for robust automatic speech recognition[END_REF] have 2D-filters arranged by spectral and temporal modulation frequencies in a filter bank. The Separable Gabor filter bank (SGBFB) features extract spectro-temporal patterns with two separate 1D GBFBs, a spectral one and a temporal one. This approach reduces the complexity of the spectro-temporal feature extraction and further improves robustness as demonstrated in [START_REF] Schädler | Separable spectrotemporal gabor filter bank features: Reducing the complexity of robust features for automatic speech recognition[END_REF]. Both features have the default parameters from the toolbox 1 for a total dimension of 1,020 each. The Scatnet [START_REF] Sifre | Rotation, scaling and deformation invariant scattering for texture discrimination[END_REF] features are generated by a scattering architecture which computes invariants to translations, rotations, scaling and deformations, while keeping enough discriminative information. It can be interpreted as a deep convolution network, where convolutions are performed along spatial, rotation and scaling variables. As opposed to standard convolution networks, the filters are not learned but are scaled and rotated wavelets. The features were extracted with a toolbox 2 using 0.25 second segments. The dimensionality of the three Scatnet components are 2, 84, 435 for a total of 521. Additionally, we included the normalized (mean and variance) Stacked (MFCCs+ SGBFB+ Scatnet) with PCA and also the normalized (mean and variance) Stacked without PCA. For the PCA we used Scikit's [START_REF] Pedregosa | Scikit-learn: Machine learning in Python[END_REF] and used the full dimensionality of 1,580 as the number of input components and the resultant automatic reduction was 909 dimensions. For all the feature types and for the sake of avoiding the length variability of the temporal dimension, we averaged the vectors across time to end up with one single vector per sound event file.

Then, for the classifiers we considered Tpot [START_REF] Olson | Automating biomedical data science through tree-based pipeline optimization[END_REF], built on top of Scikit [START_REF] Pedregosa | Scikit-learn: Machine learning in Python[END_REF], which is a Python tool that automatically creates and optimizes machine learning pipelines using genetic programming. This toolbox (version 4) considers 12 classifiers such as Decision Tree, Random Forest, Xtreme Gradient Boosting, SVMs, K-Neighbors and Logistic Regression. The main Tpot parameter is "number of generations", which corresponds to the number of iterations carried to tune the classifier, we set it to 15. An example of the best classifier for each feature type can be seen in Table 3. Interestingly, decision tree-based algorithms and logistic regression outperformed others like SVMs.

For our experiments, we extracted the 18 sound events from the two scenes using the annotations, and then we extracted different feature types from these isolated sounds. For each feature type experiment, the sound events' feature files were fed to Tpot in a randomly selected ratio of 75% training and 25% testing, each set with different files. We kept the same partitions across our experiments for consistency. The performance was measured in terms of accuracy and is displayed in Table 3.

The features with the best performance were MFCCs with 67.7% and thus we keep them for our DCASE evaluation set up. The other features have shown better results than MFCCs on audio classification, but it wasn't the case for this particular dataset. Results for Scatnet was 62.1%, for GBF was 52.4%, and for SGBF was 61.5%. Moreover, the two normalized stacked features performed almost as good as MFCCs with 66.68% for the stacked without PCA and 66.08% for the stacked with PCA. In principle the stacked version contains more information about the acoustics and thus they were expected to perform better. Nevertheless, they didn't outperform MFCCs which is designed for speech and focus on lower frequencies rather than on a wider frequency range. We cannot draw a fundamental conclusion on the performance of these features for sound event classification since the amount of data and classes are determinant.

Inclusion of Generic Sound Event Class

In the annotated scenes, not every segment of audio corresponds to a labeled sound. Hence, it cannot be assured that any of our sound event classes have to be present on every test segment. To handle out-of-vocabulary segments, we proposed a generic sound event class.

For the first experiment we wanted to analyze the impact of the generic class together with the 18 sounds in the multi-class classification set up described in Section 4.1 using MFCCs. To create such class, we used the sound events annotations and trimmed out the audio between the labeled segments, which are unlabeled. Then, we randomly selected from both scenes, 60 audio files which is about the average number of sound event samples per class. In order to visualize the performance, we included the normalized confusion matrices (CMs) in Figures 1 and2. The accuracy performance without the generic class was 67.7% and with the generic class was 60.94%. The performance dropped with the inclusion of the new class, but we can also observe how although the generic class shared the background acoustics with the other sound classes, it didn't significantly ambiguate with them.

The second set of experiments used the DCASE setup of separate scenes and four folds, and utilized the sound events with and without the generic class, but this time the generic class will have files particular to the scene. The results can be seen in Table 4 showing benefit of including the generic class. Moreover, the CMs not included due to space limitations, had cleaner diagonals. The reasons for performance improvements on the DCASE set up are suggested by the utilization of less sound classes, which reduces class ambiguity. The utilization of the generic class with samescene files as opposed to a mix of both scenes. As well as the optimization per scene of the classifier using Tpot.

Generation of Data Through Perturbation

The scarcity of labeled data per event is a common issue as discussed in [START_REF] Kumar | Audio event detection using weakly labeled data[END_REF][START_REF]Weakly supervised scalable audio content analysis[END_REF]. Annotations are costly, sounds don't occur with the same frequency and in general it's hard to capture enough variations of the same sound to train robust models. To address this problem, multiple techniques have been explored in the literature such as perturbation of the audio signal as in [START_REF] Chen | Noise perturbation improves supervised speech separation[END_REF][START_REF] Kanda | Elastic spectral distortion for low resource speech recognition with deep neural networks[END_REF]. The authors presented multiple types of perturbations resulting in improvements of speech separation. For Task 3 we performed time-based perturbation by speeding up and slowing down the sound event samples. We empirically analyzed multiple combinations of speed up-down values for different events. We concluded that speeding up more than 30% the original signal resulted in unintelligible audio and speeding down the signal more than 100% would be unlikely to occur. The range included 13 different speed values and the original version.

The set of experiments used the DCASE setup of separate scenes and four folds, and utilized the time-based perturbed audio.

For training, we added to the original files the 13 versions of the perturbed audio files, whereas for testing, the set remained intact. The results can be seen in Table 4, where the performance for Home improved, but not for Residential. Thus, we decided to use perturbation for the DCASE evaluation.

Sound Event Detection and Submission Systems

For Task 3, we used the DCASE setup of separate scenes and four folds in a similar setup as the experiments from Table 4. For each scene, we extracted the sound events from the recordings using the annotations from the train set, followed by the extraction of MFCCs features. After, we trained the Tpot optimized multi-class classifier with the event samples. For testing, instead of using sound event files only, we segmented the scene recordings from the test set into one-second consecutive segments. This number was selected due to the metric schema of the DCASE evaluation, which considers onesecond segments. After, we extracted audio features from the test segments and evaluate them with the classifier to obtain scores for each trained sound event class. The label corresponding to the highest score was chosen for the segments and then were written down 5. The inclusion of the generic class and the perturbation outperformed the baseline method by a significant margin for both Home and Residential scenes. Our submission consisted on the runs using G and G+P but using the evaluation set. The eval results were SBER of 0.9613 and Fscore of 33.6% given by the G+P version.

CONCLUSION

In this paper we showed different approaches for both acoustic scene classification (Task 1) and sound event detection (Task 3) of the 2016 DCASE challenge. On both tasks we were able to obtain significant improvement over the baseline method. For Task 1 we observed that the β features performed much better than α features. Although, linear and RBF kernels with β features can outperform the baseline by considerable margin on its own, we make note of the fact that a multiple classifier system can give further improvements. For Task 3, we tested different features and classifiers and significantly improved the baseline. Moreover, we explored a way of handling out-of-vocabulary sound segments with the generic class and the inclusion of perturbed audio to add robustness.

  -event classification accuracy using the DCASE set up with four-folds partitions. The inclusion of the [G]eneric class improved performance for both scenes, whereas the inclusion of the [P]erturbed audio improved only the Home performance.

Figure 1 :

 1 Figure 1: [H]ome and [R]esidential without the generic class. Object impact and bird singing capture most of ambiguities.

Figure 2 :Table 5 :

 25 Figure 2: [H]ome and [R]esidential with the generic class. Although this class shared the background acoustics with the 18 sounds, it didn't cause major confusion. Acoustic Scene SBER F-score Home 1.05 25.1 Home + G 0.91 23.7 Home + G + P 0.9 24.7 Residential 0.64 54.6 Residential + G 0.72 45.9 Residential + G + P 0.63 52.2Table 5: Our Segment-based Error Rate, using [G]eneric and [P]erturbation, outperformed the baseline.

Table 1 :

 1 Task 1 Accuracy for different cases (Single Classifier)

					α M				β M		β M σ
	M	LK	RK	ECK	CK	IK	EHK	HK	LK	RK	LK	RK
	64	62.8 60.6	66.2	66.3 66.0	64.7	65.3	76.8	76.6	75.5	76.7
	128 63.6 62.3	67.5	67.1 66.4	67.4	66.5	76.5	75.3	77.5	77.5
	256 63.9 63.9	67.3	67.8 66.5	68.7	67.7	76.5	71.9 76.6	75.9
	512 65.0 62.9	67.8	67.8 67.1	68.9	69.3 76.4 72.2	76.2	75.9

Table 2 :

 2 Overall Task 1 Accuracy (Fused Classifier)

				Baseline					Proposed
	Scene	Fold 1 Fold 2 Fold 3 Fold 4 Avg. Fold 1 Fold 2 Fold 3 Fold 4 Avg.
	Beach	84.2	66.7	78.9	47.4	69.3	100	71.4	89.5	52.6	78.4
	Bus	68.4	65.0	100	85.0	79.6	68.4	50.0	100	95.0	78.4
	Cafe/Restaurant	66.7	94.7	71.4	100	83.2	88.9	63.2	76.2	95.0	80.8
	Car	70.0	89.5	89.5	100	87.3	80.0	100	100	100	95.0
	City Center	83.3	73.7	89.5	95.5	85.5	88.9	84.2	100	95.5	92.1
	Forest Path	57.1	100	66.7	100	81.0	81.0	100	100	100	95.2
	Grocery Store	52.6	81.0	89.5	36.8	65	89.5	81.0	94.7	84.2	87.3
	Home	100	55.6	95.0	77.8	82.1	100	61.1	80.0	44.4	71.4
	Library	47.6	38.9	15.0	100	50.4	47.6	33.3	85.0	100	66.5
	Metro Station	84.2	94.4	100	100	94.7	94.7	94.4	100	100	97.3
	Office	100	100	94.4	100	98.6	78.9	100	72.2	83.3	83.6
	Park	10.0	5.6	0	40.0	13.9	65.0	33.3	50.0	30.0	44.6
	Residential	78.9	47.6	100	84.2	77.7	84.2	42.9	94.7	57.9	69.9
	Train	16.7	31.6	30.4	61.1	34.9	50.0	63.2	34.8	88.9	59.2
	Tram	88.9	88.9	63.6	100	85.3	83.3	88.9	63.6	100	84.0
	Overall	67.2	68.9	72.3	81.9	72.6	80.0	71.1	82.7	81.8	78.9

3.3. Results

Our experimental setup with the folds structure, is same as the one provided by DCASE. We extracted 20 dimensional MFCC features using 30ms window and 50% overlap. MFCCs are augmented with their delta and acceleration features. For our final feature representation we experimented with 4 different values of GMM component size M , 64, 128, 256 and 512. The relevance factor r for β is set to 20. Due to space constraints we cannot present fold-and-scene specific results for all cases and hence overall accuracy for all 4 folds is shown. Table

1

shows overall accuracy results for different cases.

Table 3 :

 3 Sound-event classification accuracy for different feature types using the 18 sounds and the 75 training -25 testing ratio. Stacked included normalized MFCCs +SGBFB +Scatnet.

	Feature Type	Accuracy%	Classifier
	MFCCs	67.7	Logistic Regression
	GBFB	52.4	Gradient Boosting
	SGBFB	61.5	Gradient Boosting
	Scatnet	62.1	Random Forest
	Stacked	66.68	Random Forest
	Stacked + PCA	66.06	Random Forest

Table 4 :

 4 Sound

	Feature Type	Accuracy%	Classifier
	Home	56.4	Random Forest
	Home + G	55.2	Random Forest
	Home + G + P	55.7	Random Forest
	Residential	53.3	Gradient Boosting
	Residential + G	57.8	Decision Tree
	Residential + G + P	56.7	Random Forest

1 http://www.uni-oldenburg.de/mediphysikakustik/mediphysik/downloads/gabor-filter-bank-features/ 2 http://www.di.ens.fr/data/software/scatnet/

http://www.cs.tut.fi/sgn/arg/dcase2016/sound-event-detection-metrics


Dimitar Minovski
email: dimitar.minovski1@etu.univ-lorraine.fr

Eric Rondeau
email: eric.rondeau@univ-lorraine.fr

Jean-Philippe Georges
email: jean-philippe.georges@univ-lorraine.fr

Using ICT Energy consumption for monitoring ICT usage in an enterprise

Keywords: Energy efficiency, Network management system, Energy metrics and benchmarks, Performance evaluation and modelling, Performance monitoring, Fault detection and isolation

Energy efficient policies are being applied to network protocols, devices and classical network management systems (NMS). Researchers have already studied in depth each of those fields, including for instance a long monitoring processes of various number of individual ICT equipment from where power models are constructed. With the development of smart intelligent meters and emerging protocols such as SNMP and NETCONF, currently there is an open field to couple the power models, translated to the expected behavior of the devices, with the realtime energy measurements. The goal is to derive a comparison on the power data between those parameters in the direction of detection for possible deviations on the expected results. The logical assumption is that a detected fault in the usage of a particular device will not only increase its own energy usage, but also may cause additional consumption on the other devices part of the network. This paper shows the opportunities to use power consumption monitoring of an ICT infrastructure as a substitute for the classical NMS. A platform is developed to monitor and analyze the retrieved power data of a simulated enterprise ICT infrastructure. Moreover, smart algorithms are developed which are aware of the different states that are occurring on each device during their typical use phase. Hence, the platform is able to detect and isolate possible anomalies, for instance improper use of the networking devices. The produced results are obtained and validated with the use of Cisco switches and routers, Dell Precision stations and Raritan PDU as part of the monitored infrastructure.

I. INTRODUCTION

The energy-efficient network infrastructures have recently become a hot topic in the business world, as the concept of Green IT strives to reduce the overall operational costs, but in the same time also to eliminate the inefficiencies from the enterprises' IT systems. The network infrastructures are already massively deployed and even projected to have exponential growth [START_REF]Cisco, How the Next Evolution of the Internet Is Changing Everything[END_REF] due to the evolution of the Internet, user demands and trending topics such as Internet of Things [START_REF] Vermesan | Internet of things: converging technologies for smart environments and integrated ecosystems[END_REF]. Thus, as a shared resource they have to be constantly available, which exacerbates the sustainability issues. Researchers have already proposed different network-wide energy management schemes targeting various areas such as datacenters [START_REF] Koutitas | Challenges for energy efficiency in local and regional data centers[END_REF], mobile networks [START_REF] Wang | A survey of green mobile networks: Opportunities and challenges[END_REF] and WANs [START_REF] Gupta | Greening of the Internet[END_REF]. However, it is quite challenging to tackle the energy efficiency issues within the households and from small to large enterprises. One obstacle in making enterprise networks more energy efficient is the range of devices from multiple vendors deployed on the network. Also, it is difficult to operate with enterprise networks because of their unpredictable growth, frequently changed topology and architecture, regarding the energy consumption.

Current research and developed Network Management Systems (NMS) are not fully automated when executing energyefficiency policies. Typically they are focused on manual configuration per device, which may be error prone and unlikely to make informed decision for network-wide energy efficiency. Moreover, the classical monitoring part of NMS is based on point-to-point communication with every device on the network, which creates a great deal of traffic and additional burden. Due to improvements in the field of Green IT and smart meters, it is feasible to build a NMS that recons only on power data fetched from the power distribution unit. A pattern for augmenting the values extracted from the power consumption of the network could provide useful information about different network states, for instance detecting changes in the topology. The idea is to use Fault Detection and Isolation (FDI) approach to monitor the network state based on the energy usage. Figure 1 shows that we need two information, a model representing the expected behavior of the devices and the real-time measurements to analyze deviation between the two processes. A deviation corresponds to fault detection in the network, which is in a form of misconfiguration or improper use of the equipment. This means that monitoring the energy consumption could be used not only for Green IT purposes, for raising awareness and reducing the electricity costs, but as well for a classical ICT monitoring system. Also, as the concept of Smart Grid is making use of digital networks to improve the transportation of energy, the work presented in this paper could be explained as the reverse process -how the use of energy could improve the data transport.

The remaining part of this paper is organized as follows: Section II presents the related work, while the Section III presents the objective of the paper. The system is described in Section IV, which includes the architecture for network management, the design of the experiments and the implementation of the developed platform. In Section V the obtained results are presented and discussed, while the Section VI concludes the paper.

II. RELATED WORK

A centralized traffic engineering technique is suggested in [START_REF] Zhang | GreenTE: Power-aware traffic engineering[END_REF] for route calculation using a network topology and traffic matrix. The aim is to maximize the energy savings in the network while keeping the performance at a desired level. However, it uses manual configuration through scripts to retrieve the current state of the network, which in a heterogeneous environment with devices from multiple vendors is difficult to manage. Another type of NMS [START_REF] Chaudhari | GREEN-IT: An approach to energy savings using energy aware network management system[END_REF] uses standardized network protocols such as Simple Network Management Protocol (SNMP) to manage the power distribution and achieve energy proportionality in a network. The real-time measurements are pulled from each device with point-to-point communication on the network. The introduction of NETCONF/YANG [START_REF] Chang | Design and implementation of NETCONF-based network management system[END_REF] opened new richer ways to perform monitoring and configuration of a network. The advantage of using NETCONF over SNMP is having security and additional capability exchange features, which are necessary for managing complex networks, as well as being more efficient in terms of number of transactions. The experiment in [START_REF] Hedstrom | Protocol Efficiencies of NETCONF versus SNMP for Configuration Management Functions[END_REF] demonstrated that NETCONF is able to configure 100,000 managed objects in a single transaction, while SNMP's best case scenario is 2779 transactions for the same number of managed objects.

The strategy presented in [START_REF] Aubrun | Network calculus based fault diagnosis decision-making for Networked Control Systems[END_REF] for studying the effects of unknown induced delays in network architecture suggests the use of concepts such as Fault Detection and Isolation (FDI) and Fault Tolerance Control (FTC). The study defines a threshold for the expected delay on the basis of the network characteristic and network calculus theory. A faulty situation is then generated and compared to the defined threshold in order to successfully detect which elements are causing the delays and deals with them in a controlled manner. Similarly, [START_REF] Riekstin | Orchestration of energy efficiency capabilities in networks[END_REF] proposes the use of power profiles for each device on the network to determine their expected energy usage under different circumstances. However, the power profiles are considered in special case when the realtime energy measurements are not accessible. They suit as a backup figure to proceed with the FDI's calculations to determine a faulty situation and produce energy efficient policies for the network.

The study by Drouant et al. [START_REF] Drouant | Designing green network architectures using the ten commandments for a mature ecosystem[END_REF] proposes models that gives a global overview of the impact that the network and the ICT equipment is having on the environment, developing the following equation:

E = Em + Eu + Ed = Em + ∫ ݐ݀)ݐ(ݑܲ ௗ ௬ ௧ୀ + Ed ( 1
)
Where Em is the energy required for manufacturing and transportation of the equipment, Eu is a factor related to the energy consumed during the usage of the equipment, and the energy required to dismantle the equipment is Ed. For the second part of (1), Pu is related to the power consumption by the network architecture during its use phase.

Two strategic approaches exist for modeling the energy consumed during the usage phase of the devices. The first involves a high-level modelling [START_REF] Foll | TIC et Energetique: techniques d'estimation de consommation sur la hauteur[END_REF] of the whole architecture and the second approach is more precise, meaning that it provides power models for each of the devices part of the network. A high-level model has less interactions with the devices and therefore fails to give accurate estimations how much energy a network architecture consumes at a particular point of time. On the other hand, the use of energy consumption models developed for a particular device would require constant point-to-point interactions and cause certain amount of additional traffic in the network. However, by giving a more precise figure on the expected behavior of the devices the system would be more responsive to minor changes, faults and anomalies, which is the purpose of the experiments part of this paper. Therefore, the power models for Switch [START_REF] Reviriego | An Energy Consumption Model for Energy Efficient Ethernet Switches[END_REF][START_REF] Hossain | Modeling the power consumption of Ethernet switch[END_REF], Router [START_REF] Ahn | Measurement and modeling the power consumption of router interface[END_REF], PC [START_REF] Agarwal | Somniloquy: Augmenting Network Interfaces to Reduce PC Energy Usage[END_REF] and Access Point [START_REF] Demir | An energy consumption model for 802.11ac access points[END_REF] are added to the Power Model Registry, as shown on the Figure 3, explained in the next sections.

III. OBJECTIVE

The goal is to develop autonomous network management system (NMS) which operates only with the retrieved power consumption data from the devices part of the network infrastructure. The system follows the FDI approach illustrated on the Figure 1 to detect and report for possible faulty situations and anomalies in the usage phase of the ICT equipment. To achieve this, two information as an input parameters are required: (i) power data from real-time measurement procedure and (ii) values for the expected power consumption of each device extracted from the power models.

(i) The process of real-time measurement requires probes and standardized protocols to access the needed metrics which are altogether coupled in a monitoring system. In practice, Raritan Intelligent Power Distribution Unit (PDU) is the monitored equipment which has a predefined energy Management Information Base (MIB) as a hierarchical structure with properties that is pulled out periodically. The monitoring system itself is then able to collect, analyze and modify the information stored in the PDU's MIB through SNMP.

(ii) From the other side, as discussed in the section II, the selected power models represent the expected behavior the equipment. Therefore, currently there is an open field to combine the real-time measures, which are translated to the real behavior of a device, with the developed models. A deviation between the models and the monitored power data is used to detect anomalies and to anticipate fault according to a trend analysis.

A. Building a knowledge base

The developed platform that incorporates the monitoring system and the power models has to form thorough foreknowledge in order to successfully anticipate and interpret the readings for the energy consumption. Mostly because the power data is just a raw value and does not contain rich information. As suggested by [START_REF] Kazandjieva | Measuring and analyzing the energy use of enterprise computing systems[END_REF], some types of computing Fig. 1 The general approach of the paper systems within the enterprise can exhibit large variations on the power data even when comparing two instances of the same device model. More precisely, two Dell Optiplex 760 PCs were observed to have over 40% discrepancy in their average power draw. To remedy this, the platform has to augment new ways to isolate the problem with the inconsistent energy consumption of the devices, to locate the fault or the anomaly and to classify the problem. One way to deal with this is to predict the fault that may occur during the usage of the equipment. It is important to test the responsiveness of the platform by generating different faults and misconfigurations that may occur during a typical workday in an enterprise network. Thus, closely observe the figures for energy consumption and build a knowledge base. A system with such knowledge comprised with smart algorithms is capable of analyzing the deviations and benchmark the faulty situations. From there a pattern could emerge to later detect the problem of aberrant values regarding the energy consumption of the devices during the real-life usage phase of the equipment.

B. The logic behind the NMS

The states illustrated on the Figure 2 represent the logic throughout the execution process. Having developed a standalone platform able to monitor the energy consumption as a first state allows further analysis process on the retrieved and stored data. The analysis engine as a second state is tightly coupled with the learning model of the system by developed smart algorithms which are able to detect and identify the changes in the power data. Big part of the analysis process plays the inclusion of the power models [START_REF] Reviriego | An Energy Consumption Model for Energy Efficient Ethernet Switches[END_REF][START_REF] Hossain | Modeling the power consumption of Ethernet switch[END_REF][START_REF] Ahn | Measurement and modeling the power consumption of router interface[END_REF][START_REF] Agarwal | Somniloquy: Augmenting Network Interfaces to Reduce PC Energy Usage[END_REF][START_REF] Demir | An energy consumption model for 802.11ac access points[END_REF] which are defining the power profiles of the devices and are calculating their expected behavior. The output of the models is then validated with the retrieved real-time measurements and the results are logically passed to the third state, the learning process, where they are further dismantled towards understanding and interpreting the power data values. The emphasis of the third state, the learning process, is given to the simulation of the faults that are most frequent during the regular usage phase of the ICT equipment. The established knowledge base is used as a baseline on which the learning model is constructed. This means that series of experiments have to be conducted for a range of different faults in the interest of acquiring the desired foreknowledge, which is also the key for the isolation part as a last state of the logic depicted on the Figure 2.

Ever since the commencement period of the learning process, the system is constantly updating its knowledge base depending on the behavior of the devices, and by following the figures for the energy consumption it is able to discern the aberrant states of the devices. For instance, a possible overloading on the devices, detecting sleep/hibernate states, physical or logical changes in the configuration of the devices, etc. To have seamless operations and accurate output, the learning process also needs to update the static values in the power models based on the detected new state of a particular device. Namely, as seen on the Figure 1, the formulas in the power models depend on static parameters from the network planification, which are gathered during one-time measurement. This means that the learning model has to re-compute the input parameters in the power models after a detection of a new network state, for instance transiting a switch port from offline to online state. This concludes the final fourth state of the logic behind the experiment, the engine for power management, because the outcome from the previous states results with identifying the changes that happened in the network infrastructure and suggests a recuperation, or a reconfiguration of the network.

IV. SYSTEM DESCRIPTION

A. System Architecture

The architecture of the system shown on the Figure 3 consists of subcomponents for each of the main components, namely: (i) Power Model Registry; (ii) Network Management System; and (iii) Equipment. The integrated view of the network infrastructure is the foremost advantage of the architecture, enabling the enforcement of energy-efficient policies while having a minor impact on the overall consumption and the traffic flowing through the network.

(i) The Power Model Registry includes a set of static parameters that define a power profile extracted from the hardware pieces such as the chassis, the forwarding engine/cpu or the cards/ports of the devices. Among those parameters there is a derived scaling factor for energy consumption dependent on the load. For instance, a power model would be determined by a function f(load) defining how power consumption varies with the load handled by the device. Such parameters are obtained through a one-time measurement during the initialization phase of the system, or when a new device is plugged to the PDU.

(ii) The Network Management System and the logic behind it, as discussed in the previous section, suits as a guideline through series of states that stands on the energy monitoring process. The logical assumption is to follow the impact that a device is having on the energy consumption of the whole network, since a possible anomaly during the usage phase could cause additional consumption on the other devices part of the network.

Fig. 3 The architecture of the system Fig. 2 The experiment's logic (iii) SNMP as an application-layer protocol that is widely accepted for managing and monitoring network elements is pinned as the first state of the execution process on Figure 2. The Raritan Power Distribution Unit used for evaluating the proposed solution comes with a bundled SNMP agent and energy MIB. Therefore, it enables easy and lightweight communication with the developed platform considering the fact that only the values for the power data from the attached equipment are fetched. Having a power distribution unit like Raritan enables following and reporting for plugged 8 to 48 devices.

B. Case study

List 1 represents the faults which are chosen as most common during a typical enterprise workday, tested on a various heterogeneous combinations of network architectures, prior building the knowledge base. To identify where the faults are applied, a classification based on the objective is depicted on the Figure 4. (i) As suggested in [START_REF] Agarwal | Somniloquy: Augmenting Network Interfaces to Reduce PC Energy Usage[END_REF], desktop computer are rarely turned off when they are not in use, and even though the green computing research community has focused on solving the problem of an idle PCs, the intuition is that there is still a room for improvements. For instance, the developed platform has the possibility to automatically detect the working hours of an enterprise, and by that to be able to determine if the equipment was left in the operational state. Hence, a suggestion for turning off, sleep or hibernate state is issued. Another use case is a constant level of energy consumed during non-working hours by wireless access point can indicate that the device is powered, but it does not transmit any data already for some time, meaning that it should transition into a sleep/hibernate mode.

(ii) Managing the active ports on a switch is one important and exquisite objective because it is the only way of providing network accessibility. Therefore, to have an overview on the status of the ports at one point of the time by observing the switch's values for the energy consumption is a delicate task. Mainly because of the introduction of EEE as a set of enhancements able to dynamically put a single link temporarily to sleep when not in use. One way to accomplish this is by following the consumption during the transition between shutting down and waking up a switch port, so that the platform can keep track of it and develop its own matrix of the status of the ports.

(iii) Similarly, the utilization of the Ethernet links is, on average, extremely low [START_REF] Gunaratne | Reducing the Energy Consumption of Ethernet with Adaptive Link Rate (ALR)[END_REF]. This suggests that there is an ample opportunity for energy savings by operating Ethernet links at a low data rate for most of the time with no perceivable performance impact to the user. Keeping track of the port's assigned speed by following the consumption of the switch is deriving a suggestion when to change the port's rate. But it is also helping the system to correlate it with the congestion, or the load on the switch, which is as well affecting the overall power consumption.

(iv) The listed energy-efficient possibilities are mostly applicable to a network switch. Cisco 2960 and 3560 switch series were available during the execution of the experiments, thus a evaluating of EEE and Cisco EnergyWise technology were at disposal for testing. Since those technologies could operate dynamically without assistance of the administrator, the developed solution has to identify and report for their changes.

(v) Spanning Tree Protocol (STP) is commonly used Layer 2 protocol that runs on switches and bridges, with purpose to ensure that there are no loops created on a redundant path in the network. By default, STP dynamically manages the elimination of the loops with the process of electing a tree based on priorities with a particular switch as a root. This means that there is a possibility of a network reconfiguration without the assistance of the operator, which could lead to additional power demands if it is not well managed. To observe how STP affects the energy consumption, an STP re-evaluation has to be generated that could be performed either by physical or logical events, such as physically removing a cable from a switch or by changing the priority id on the switches.

C. Implementation

The platform, which includes the power models and the monitoring module is implemented in Java language. The energy monitoring task is developed in a multi-threaded fashion to periodically pull the energy values from the Raritan PDU, by importing Java libraries for SNMP to access the functions for requesting the right Raritan's MiB OIDs. There is an ability to optimize the frequency of the probes send to the Raritan PDU throughout a developed GUI, thus the accuracy of the measures are practically defined by the operator. During the test phase of the platform, probes were requested every second and the responses are stored locally with the interest to enable further analysis on the data. The response from each probe is a group of values in the following format:

I(A) -Electric current significant with 10 -3 amps (A) base V(V) -Voltage
(2)

PF -Power factor

Moreover, the probe response does not only contain data for the total energy consumed by the whole PDU, but also it reports the consumption of its sockets individually. This means that the platform with additional analysis can successfully build its own schemas and detect what kind of device is connected to a certain socket. Algorithm 1 describes the process flow of the platform. The support of power models (PM) in the platform creates the premises to set the expected threshold regarding the energy spent by each detected device. The models from [START_REF] Reviriego | An Energy Consumption Model for Energy Efficient Ethernet Switches[END_REF][START_REF] Hossain | Modeling the power consumption of Ethernet switch[END_REF][START_REF] Ahn | Measurement and modeling the power consumption of router interface[END_REF][START_REF] Agarwal | Somniloquy: Augmenting Network Interfaces to Reduce PC Energy Usage[END_REF][START_REF] Demir | An energy consumption model for 802.11ac access points[END_REF] are represented with a static parameters gathered by one-time measurement at the initialization phase of the platform or when a new device is plugged to the PDU socket.

Having such real-time availability probes enables the platform to perform parallel comparison on the retrieved data for individual sockets and as a whole with the data provided by the power models. In case of aberrant values, the platform tries to locate the device with the unexpected behavior, load the latest stored power data history of the device and perform analysis for fault detection. The isolation process is based on calculations guided by the predefined fault foreknowledge achieved by the experiments. They are also integrated into the platform as a knowledge base. More about the results from this process is discussed in the next section.

V. RESULTS AND DISCUSSIONS

This section refers to the List 1, presenting the obtained results during the test phase of the developed platform. Each of the experiments were tested on different network architectures, monitored for 10 minutes continuously, as well as under different amount of load generated to flow through the network.

(i) The possibility to automatically detect the working hours of an enterprise allows the platform dynamically to report on the equipment that was left in an operational state. The cost of powering the hardware components of each device dominates the overall power profile and therefore the opportunity for energy savings are the highest. The difference in the energy consumption is illustrated on the Figure 6. Typically, there is a burst of energy consumption when a device goes to operational state, either from sleep/hibernate or offline mode. Those values are also used to benchmark the current state of the device.

(ii) The difference in the power consumption after a transition from active to inactive Cisco switch port is observed to be from 0.3 to 0.4 W, as illustrated on the Figure 7. This result allows the developed platform to have detailed matrix of the port statuses of each switch, which is used to report possible unnecessarily active ports, but also is part of the analysis for a possible misconfiguration of the network.

(iii) There is no notable change in the consumption when comparing 10Mb/s to 100Mb/s speed link, but the difference when making a transition from 1Gb/s to 100Mb/s is from 0.2 to 0.4 W per port. Thus, the developed platform is forming a schema of each port link speed that is used as part of the suggestions for the speed reduction if a particular link is under low utilization.

(iv) Energy-Efficient Ethernet is not yet a feature supported by many network devices currently on the market, however it is important to observe its impact on the energy consumption. During an idle period of a switch with no traffic flowing through the ports, EEE will put all of the active ports in the Low Power Idle (LPI) state. Therefore, EEE is achieving the same result as the second (ii) experiment of 0.3 to 0.4 W savings per Cisco switch port. Hence, the developed platform has to be aware of the possibilities of EEE to dynamically, for a temporary time, put a port to idle mode.

(v) STP, enabled between the switches on the Figure 5, does not save any energy with its ability to block certain port in order to discard the loops in the network. Namely, a port in a blocking state is consuming the same amount of 0.4 W as the other active ports. The only noticeable difference is the spike of energy consumption when STP is trying to re-evaluate the tree. Namely, during a physical or a logical generated error, STP will elect a new root and construct the new tree. Thus, this process adds up to 1 W for few seconds to the overall consumption of the Cisco switch, depending on the architecture. This burst of energy, also shown on the Figure 7, is used to detect a change in the STP, with the interest of reporting it for possible misconfiguration of the network.

VI. CONCLUSION AND FUTURE WORK

We presented results from evaluating the proposed novel form of energy-efficient NMS emulated in a heterogeneous network environment, showing that a significant power could be saved with minor impact on the network regarding the traffic. Precise figure on the energy conservations is difficult to be drawn due to the factors such as the size of the SNMP packet, number of nodes that a SNMP packet has to traverse, complexity of the network architecture and the number of MIB values required for calculation. Also, each packet as it is traversing a node invokes energy consumption for procession, memory and bandwidth usage. The size of an SNMP packet varies from 484 to 1500 bytes [START_REF] Stevenson | Method and apparatus for fetching sparsely indexed MIB tables in managed network systems[END_REF], and according to [START_REF] Baliga | Energy consumption in optical IP networks[END_REF] 10nJ is used for transferring a bit through a network. The approach of monitoring the power consumption directly from the PDU, instead of pointto-point communication with every device in conventional NMS brings own complexity as the network grows. For instance, in a set-up of multiple faults happening simultaneously, the FDI concept presented is this paper is able to cope with the occurring situation. However, this study considers an ideal scenario without testing the responsiveness of the models under noise, excluding the sensibility issues of the used models.

As a first work in the area of augmenting the extracted power data from the ICT devices, the results from this study demonstrates a promising start in the future development of energy-efficient network management systems. However, the next step would be improving the sensibility of the models, in order to be more responsive to modeling errors and noise on the network when they transpire. As future work, we envision improvements in the proposed platform by doing selfrecuperation and autonomous reconfiguration of the network, through the suggestions that are currently being produced. The anticipation is also to include other common network anomalies and to follow their impact on the energy consumption, for instance the packet loss rate and highly congested networks, which could possibly trigger a use of other techniques in order to gather all the necessary information for the analysis process, rather than just monitoring the energy values.

List 1 :

 1 faults to be detected on the network (i) Testing the operational vs. the sleeping mode on the devices such as Cisco switches, routers, access points, Dell PCs and LCD monitors and HP laptop computers (ii) Turning off/on a Cisco switch port (iii) Performing link adaptation on the Cisco switch's ports (iv) Evaluating the effect on Energy-Efficient Ethernet (EEE) and Cisco EnergyWise (v) Testing a Spanning Tree Protocol (STP) reevaluation on the network One possible case study of network architecture is depicted on Figure 5, where the generated faults are represented as the 'Y' input parameter. At disposal for the experiments there were 8 Cisco switches from the series 2960 and 3560, 8 Cisco 1941 Routers, 10 Dell Precision T1700 stations, 2 HP Pavilion laptops, 6 Raritan PX2 PDUs and 2 Raritan PX3 PDUs.

Fig. 4

 4 Fig.4 Classification of the objectives

Algorithm 1 :

 1 the process flow input: PM, the power models; PR, the probe response output: Ffault, detected fault, Iisolation, isolating the fault R is the Raritan PDU E denotes the attached equipment KB is the knowledge base foreach X in PR do Wtotal ← X(I(A)) * X(V) * X(PF) Store(Wtotal) if Wtotal > PMtotal then foreach E in R do Windividual ← E(I(A)) * E(V) * E(PF) Store(Windividual) if Windividual > PMindividual then Ffault ← Detection(E, KB, History(Windividual) Iisolation ← Isolation(Ffault) Store(Ffault, Iisolation) return Ffault, Iisolation

Fig. 6

 6 Fig.6 Obtained results from Raritan PDU -(i) experiment

ACKNOWLEDGMENT This research was supported by Erasmus+ PERCCOM (Pervasive Computing and Communications for Sustainable Development) Program.


Kais Mekki

William Derigent

Ahmed Zouinkhi

Eric Rondeau

André Thomas
email: andre.thomas@univ-lorraine.frahmed.zouinkhi

Mohamed Naceur Abdelkrim
email: naceur.abdelkrim@enig.rnu.tn

New communicating concrete for data storage and retrieval through integrated micro sensor nodes

Keywords: Smart homes, Communicating materials, Precast concrete, Micro sensor networks, Data retrieval protocols. I

INTRODUCTION

Concrete's versatility, durability, and economy have made it the world's most used construction material. The concrete construction companies mainly follow two strategies: i) Local concrete fabrication: the concrete is produced on construction site via formwork, the site is delivered only in raw material (granula, cement, adjuvant, etc.) and scrap. ii) Precast concrete fabrication: all construction elements (beams, floors, bearing walls, pillars, etc.) are factory away from the site and brought to the site to be implemented quickly. For reasons of cost and time, the choice is take up mostly toward the precast concrete. Indeed, as it was described in one of the four roles of construction management [START_REF] Vrijhoef | The four roles of supply chain management in Construction[END_REF]: We must transfer the activities of the earlier building site in the chain. These avoid the climate change in the site and conduct a number of parallel operations. With precast, it is possible to improve the construction site in place, time and quality. Actually as example, the United States uses about 260 million cubic meters (340 million cubic yards) of ready precast concrete each year. It is used in highways, streets, parking lots, parking garages, bridges, high-rise buildings, dams, homes, floors, sidewalks, driveways, and numerous other applications [START_REF] Kosmatka | Design and Control of Concrete Mixtures[END_REF]. In recent years, a new research area has appeared for improving concrete in logistic chain, traceability and security using Internet of Thing tools (especially RFID and Sensor Nodes technology). As example in 2007, BizzDev company (www.bizzdev.com) designed a system composed of two parts: a temperature sensors node is directly embedded in the precast and RFID tag in its surface. The concrete is therefore able to deliver its temperature continuously over time for supervising application. Also, the CERIB company (www.cerib.com) on collaboration with CRAN laboratory uses RFID in the concrete for traceability in the supply chain: concrete beams were instrumented by integrating two RFID tag on each end. Then, CE information has been stored in the memory of these tags, increasing the chances that such information is not lost and still available throughout the supply chain. However, the idea used in this two examples consists in integrating sensor nodes and tags RFID in some part of the concrete precast. This could lead to two problems: i) If the precast exceeds the human scale. It is common to find some buildings beams or concrete slabs of tens meters (even a hundred meters). It is then difficult for the operator to systematically go through all of the building (for example, over 100m) to identify its characteristics or by searching for the tags containing the information. ii) When the concrete precast is used and installed inside the building, it is difficult to localize and access to the RFID tags inside the precast. iii) The RFID technologies are limited in memory, thus using one or two tags could not allow large storage memory of information. For this reason, another's application aims to fully integrate RFID tags in concrete precast to allow accessing information from each part of building. In [START_REF] Kalansuriya | RFID Tag Antenna-Based Sensing for Pervasive Surface Crack Detection[END_REF], the RFID tags are placed uniformly in the surface of the precast to take a first step towards automatic detection of cracks. The cracks are detected when some tags are damaged. In [START_REF] Lafarge | Quand les ntic s'invitent sur le chantier de la tour d2(92): Une collaboration réussie entre Lafarge et Vinci Construction France[END_REF], Lafarge company (www.lafarge.com) integrated RFID tags directly into the concrete for traceability application. The RFID tags are disseminated in all the building concrete at number 4 or 5 tags every 2m 3 on average. The ID of tags could then be readied in each part of building. Using the ID, the operators could access to all the needed information about the concrete (e.g. constructor, date, technical characteristic, etc.) through external associated database. The nature of the two last above application is limited. It is a simple identification of RFID tags and a consultation of concrete data from an external database. In this paper, we define new services of communicating concrete precast which could store database information directly into the concrete. This paradigm is developed through uniformly integrating thousands of micro-sensor nodes in the concrete (25 nodes each 4 m 2 ). Each node could communicate wirelessly with others inside the concrete. Thus, the nodes could then construct a wireless sensor network inside the building. Then, the information could be stored in the micronodes using data storage protocol for wireless sensor network. Unlike RFID, the operator could connect to any node in the concrete and store or read all the information in the building through multi-hops routing protocol of WSN. For this issue, we recently developed a new data storage protocol called USEE [START_REF] Mekki | USEE: A Uniform Data Dissemination and Energy Efficient Protocol for Communicating Materials[END_REF]. USEE guarantees that each data is uniformly replicated throughout the WSN inside the precast. Thus, information could be read in all parts of the building. USEE is based on three strategies: counter-based flooding to forward messages to all nodes in the concrete, neighbor storage information which control the replication rate and ensure that information is stored once in each neighborhood as much as possible (i.e. for increasing the storage capabilities of WSN), and finally probabilistic storage (i.e. the data is stored with probability P) [START_REF] Mekki | USEE: A Uniform Data Dissemination and Energy Efficient Protocol for Communicating Materials[END_REF]. This protocol was showed good performance in dense sensor network through simulation especially for uniform data storage in the whole network, optimization of energy consumption and high storage capacity compared to the literature protocols. To extract and read the stored data, this paper presents a data retrieval protocol based on Random Walk (RW). The RW empowers nodes with the ability to efficiently forward requests hop by hop which only rely on neighborhood information. We empowered RW by adding Pull Gossip (PG) to query the neighbors in each hop and increase the number of covered nodes during retrieval process.

In the rest of this paper, the new data retrieval protocol is firstly detailed. Then, the new paradigm of communicating concrete precast using micro-sensor networks is presented. We studied the optimal density of the nodes inside the concrete precast (i.e. probabilistic and simulation studies) for the best uniform storage results of USEE protocol and for the best reliability of the proposed data retrieval protocol. Finally, the retrieval protocol performances are discussed in terms of number of covered nodes, response delivery ratio, and average delay.

II. DATA RETRIEVAL PROTOCOL IN COMMUNICATING CONCRETE

In this section we propose a data retrieval protocol to read the uniformly replicated data in the concrete by USEE [START_REF] Mekki | USEE: A Uniform Data Dissemination and Energy Efficient Protocol for Communicating Materials[END_REF]. In the following, a state of art of data retrieval protocol of WSN is presented. Then, the proposed data retrieval protocol is detailed.

A. State of art

Various schemes to efficiently retrieve data in WSN have been proposed in the past years [START_REF] Nikolaos | Energy-Efficient Routing Protocols in Wireless Sensor Networks: A Survey[END_REF]. There are two main approaches: two request/response phases and one request/response phase.

-Two request/response phases: using this class, the user (or sink node) broadcasts a request message, for instance, "give me the temperature in a particular area". The request is flooded throughout the network. Upon receiving the request, each node sets up a gradient toward the nodes from which it receives this message (i.e. the gradient specifies both data rate and the direction along which response should be sent). This process continues until gradients are set up from the sources back to the sink (figure 1(a)). The source data are then returned in the reverse path of the request propagation. If each node receives the same request from more than one neighbor, the source data will travel to the sink along multiple paths (figure 1(b)). At this point the sink reinforces a particular path with the least-delay (figure 1(c)). All response messages then could be sent from the source to the sink through the reinforced path (figure 1(d)). Directed Diffusion (DD) [START_REF] Intanagonwiwat | Directed Diffusion: A Scalable and Robust Communication Paradigm for Sensor Networks[END_REF] is the most known protocol of this class. Various other based DD protocols are developed such as DCHT [START_REF] Li | Efficient Multi-Path protocol for Wireless Sensor Networks[END_REF], BMR [START_REF] Ganesan | Highly-Resilient, Energy-Efficient Multipath Routing in Wireless Sensor Networks[END_REF], EAR [START_REF] Shah | Energy Aware Routing for Low Energy Ad Hoc Sensor Networks[END_REF], and GBR [START_REF] Schurgers | Energy efficient routing in wireless sensor networks[END_REF].

-One request/response phase: in WSN, minimizing the number of flooding reduces the energy consumption rate. One request/response class avoids the two existing floods in figure 1(b) and 1(c). First, the request is flooded in the network and gradients are established at each hop. Unlike two phases protocols, when the request reaches a source node, it sends the response messages only to the most powerful neighbor (evaluated thanks to properties like latency, quality of radio link, high residual energy, etc.) in the reverse path of the request propagation.The most known one request/response phase protocols are: MARP [START_REF] Sen | An Adaptable and QoS-Aware Routing Protocol for Wireless Sensor Networks[END_REF], MCFA [START_REF] Ye | A scalable solution to minimum cost forwarding in large sensor networks[END_REF], GRAB [START_REF] Ye | Gradient broadcast: A robust data delivery protocol for large scale sensor networks[END_REF],RR [START_REF] Braginsky | Rumor Routing Algorithm for Sensor Networks[END_REF], EEQR [START_REF] Ahvar | EEQR: An Energy Efficient Query-Based Routing Protocol for Wireless Sensor Networks[END_REF], EQSR [START_REF] Othman | Energy efficient and QoS based routing protocol for wireless sensor networks[END_REF], and MR2 [START_REF] Maimour | Maximally Radio-Disjoint Multipath Routing for Wireless Multimedia Sensor Networks[END_REF]. In this paper, choosing the correct data retrieval protocol is related to the specificities of the communicating concrete and the way the data is stored inside it by USEE [START_REF] Mekki | USEE: A Uniform Data Dissemination and Energy Efficient Protocol for Communicating Materials[END_REF]. The information is uniformly replicated in the network inside the concrete (the same information is replicated in many nodes). However, all the literature techniques are based on request flooding. By using flooding technique in communicating concrete, many nodes could respond to the same request leading to high redundant rate, network congestion, high transmission rate, and thus increasing the energy consumption. Hence, using of such protocols is not appropriated since they deplete the energy of nodes especially for limited resources of micro-sensor node. Thus, Random Walk (RW) [START_REF] Lima | Random Walks on Sensor Networks[END_REF] is chosen in this paper to propagate the request hop by hop throughout the WSN. However, this mechanism could lead to random long path (data retrieval failure) and long delay. Thus, Pull Gossip (PG) [START_REF] Liu | Balancing push and pull for efficient information discovery in large-scale sensor networks[END_REF] mechanism is also selected to interrogate the neighbor nodes in each hop of the RW process.

B. Random Walk and Pull Gossip based protocol for data retrieval in communicating concrete

The Random Walk (RW) is a process in which a carried data is repeatedly forwarded (as a message) from a node to one of its randomly chosen neighbors until the end of the random walk length (i.e. the number of hops that the random walk should last) as shown in figure 2(a). As discussed before, the RW process could lead to random path, and could lead to long path without any results. Thus, the Pull Gossip (PG) mechanism is executed in each hop. Using PG based algorithm, a node query its neighbors. The node will receive a response only if a neighbor has this information. Thus, the request message is transmitted from anode X to another Y only if the information is missing in the neighborhood of X. This process increases the number of covered nodes of simple RW as shown in figure 2 The next hop is randomly chosen. However, the information has more chance to be found if many new nodes are covered in each hop, to increase the efficiency of the retrieval process. Thus, this process is modified by forwarding the request to the farthest neighbor node, hence the maximum number of nodes in the next PG discover is covered. As example, in figure 3(a), the next hop is chosen randomly. The number of new nodes covered by PG during the next hop is equal to 6. However, in figure 3(b), the next hop is chosen thanks to farthest neighbor selection. The number of new covered nodes is equal to 12. This mechanism dramatically increases the chance of finding information at each hop. The farthest neighbors selection algorithm is described in the next section.

Moreover, a link cost function is used by the node to select the best farthest neighbor as next hop. Thus, the request is routed throughout a high quality of service path which increase the reliability of the protocol. A cost function is used such as presented in [START_REF] Othman | Energy efficient and QoS based routing protocol for wireless sensor networks[END_REF]. Let L Border is the set of farthest neighbors of a node X inside the concrete. The cost function includes an energy factor, available buffer factor, and interference factor with appropriate weights α, β, and γ:

ݐݔ݁ܰ ℎ = max ܮ∈ܻ ݎ݁݀ݎܤ ൛ߙܧ ݀ݏ݁ݎ ,ܻ + ܤߚ ݎ݂݂݁ݑܾ ,ܻ + ܫߛ ݁ܿ݊݁ݎ݂݁ݎ݁ݐ݊݅ ,ܻܺ ൟ
Where, ܧ ݀ݏ݁ݎ ,ܻ is the current residual energy of a farthest neighbor Y where ܻ ∈ ܮ ݎ݁݀ݎܤ , ܤ ݎ݂݂݁ݑܾ ,ܻ is the available buffer size of node Y, and ܫ ݁ܿ݊݁ݎ݂݁ݎ݁ݐ݊݅ ,ܻܺ is the Signal-to-Noise Ratio (SNR) for the link between X and Y.

C. Farthest neighbors selection algorithm

The algorithm of farthest neighbors selection is executed in the beginning of the concrete precast lifetime. It is used for executing the final data retrieval protocol during the precast lifecycle. The algorithm of farthest neighbor selection uses three messages: -HELLO: It allows each node to announce their ID to its neighbor nodes.

-TAB_EXCHANGE: It allows each node to announce its neighborhood table to all its neighbors. -FAR_NEIGHBORS: It allows each node to announce the list of its selected farthest neighbors. The algorithm of the farthest neighbor selection is executed by all nodes in the concrete. Let X be a node inside the communicating concrete. To construct the neighbor table (N Table ) for each node, the HELLO message is exchanged between neighbor nodes using the broadcast communication model. Then, each node inserts its N Table into a TAB_EXCHANGE message and broadcast it to all neighbors. Hence, a node X can compute the number of common nodes between its N Then, the list of selected farthest neighbors (L Border ) is broadcasted using FAR_NEIGHBORS message. When a node X receives FAR_NEIGHBORS from its neighbor Y, X checks if its ID exists in the list L Border carried by the message. If yes, the node X store the ID of Y (ID_SOURCE of FAR_NEIGHBORS). Finally, X is configured as farthest neighbor for Y.

Once the farthest neighbors selection algorithm is finished, the data retrieval protocol can be executed during the communicating concrete precast lifecycle.

D. Data retrieval protocol

The proposed data retrieval protocol uses five messages: -REQUEST: It is the request message that contains the requested data reference. It contains the TTL counter which fixes the maximal number of hops for data retrieval path.

-REQUEST_NG: It is the request message that is used to interrogate the neighbors through broadcast communication model.

-FAR_INFO: It is sent by the farthest neighbor toward the REQUEST_NG source. It contains the information needed for the link cost function to choose the most powerful next hop.

-RESPONSE: It is the response message sent by the node that has the requested data in its memory. RESPONSE is sent to the source node (the node that begins REQUEST transmission in the concrete) through the reverse path of the REQUEST message.

-FAILURE: It is sent by the node that receives REQUEST message with TTL=0. FAILURE is sent to the source node through the reverse path of the REQUEST message. The proposed protocol includes three treatments: REQUEST treatment, REQUEST_NG treatment, and RESPONSE/FAILURE messages treatment. In the following, the treatment of each message is detailed.

REQUEST message treatment

The REQUEST message is forwarded from one node to another one in the concrete until a node that contains the information is founded or the TTL counter falls to zero. If one of the latter happens, a RESPONSE or FAILURE message is sent toward the source node on the reverse path of REQUEST. For that, upon receiving REQUEST message, the node temporarily stores the ID of the sender node (ID_SOURCE) to construct the reverse path to the source node. Then, the node checks whether it has the requested information in its memory. Otherwise, the node checks the TTL field in REQUEST. If TTL is zero, a FAILURE message is sent back. Otherwise, the node starts the neighborhood interrogation. For this, a REQUEST_NG message is broadcasted to all neighbors, and then the node waits for reception of FAR_INFO of the farthest neighbors and a possible RESPONSE message. If a RESPONSE is received from a neighbor, the node sends it to the previous node from who it was received the REQUEST. If any RESPONSE message is received, it means that the information does not exist in the neighborhood. In that case, the node decrements TTL, and forwards REQUEST to the best farthest neighbor who is selected using the received FAR_INFO messages and the link cost function.

REQUEST_NG message treatment

Upon receiving a REQUEST message, a node X broadcasts REQUEST_NG to all its neighbors. When a neighbor node receives the REQUEST_NG message, it sends back a RESPONSE message to REQUEST_NG sender only if it has the requested data in its memory. Only the neighbors which are configured as farthest nodes for X send FAR_INFO. Otherwise, the REQUEST_NG message is dropped. As described before, FAR_INFO contains the needed information for the link cost function to evaluate the best powerful farthest neighbor.

RESPONSE/FAILURE message treatment

Upon reception of a RESPONSE or FAILURE message, the node sends the message to the already stored ID_SOURCE of REQUEST. Thus, these messages are forwarded through the reverse path of REQUEST until it reaches the source node.

III. INSTRUMENTATION OF THE COMMUNICATING CONCRETE

PRECAST

This section details the ideal type of micro-nodes for the instrumentation of the communicating concrete precast. We also study the optimal density of nodes in the concrete for the better performance of USEE protocol in term of uniform replication, through probabilistic and simulation studies. Finally, we study the density of nodes in the concrete for the best performance of the farthest neighbors selection algorithm used by the data retrieval protocol.

A. Micro-sensor nodes for communicating concrete

The proposed communicating concrete paradigm uses microsensor nodes which are very small and could be integrated in a precast without modifying either its properties or its appearance as shown in figure 4 (i.e. a uniform nodes deployment is used in the concrete). Currently, several researches focus on miniaturization of electronic components for sensor nodes. But few micro-nodes exist in the literature such as μPart [START_REF] Beigl | μParts: Low Cost Sensor Networks at Scale[END_REF], ECO [START_REF] Park | Eco: an Ultra-compact Low-Power Wireless Sensor Node for Real-Time Motion Monitoring[END_REF], ZN1 [START_REF] Yamashita | A 15 × 15 mm, 1 μA, Reliable Sensor-Net Module: Enabling Application-Specific Nodes[END_REF], SAND [START_REF] Ouwerkerk | SAND: a modular application development platform for miniature wireless sensors[END_REF], SensorCube [START_REF] Torfs | Wireless network of autonomous environmental sensors[END_REF], and Tyndall [START_REF] Harte | Wireless sensor node design for heterogeneous networks[END_REF].

Micro sensor node

Wireless connection Fig. 4. Communicating concrete precast using micro-nodes.

SAND, μPart, and Tyndall are the micro nodes with the smallest size (1 cm 3 ). However, μPart node has no reception functionality (only transmission data 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 communicating concrete application. Moreover, it provides good memory size as a micro node (120 Kb). 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 sensor. In addition, 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, SensorCube node was chosen for communicating concrete. In this paper, this node is implemented in the Castalia simulator.

B. Nodes density inside the concrete for uniform data storage using USEE In this section, the ideal density of nodes inside the concrete precast (nodes are uniformly deployed inside the concrete) is studied for the best performance of uniform data storage using USEE protocol. For this issue, we suppose that: if the data is stored at least once in each neighborhood in the WSN, so the data certainly exist throughout all the concrete precast. In the following, a probabilistic and simulation studies are presented.

a) Probabilistic study

Let N the total number of nodes in the concrete. After executing USEE protocol, the sensor network contains two types of nodes: nodes that store the data and nodes that did not store it. Let: Let n the number of nodes in the neighborhood of a sensor node in the concrete. The n nodes are composed of nodes e 1 and e 2 . In statistics, the neighborhood of size n is a drawing of n nodes among the total number of nodes N. Let attach now to e 1 and e 2 , a number X taking the value 1 if e 1 is drawn and the value 0 if e 2 is drawn. So, X is a discrete random variable representing a Bernoulli variable whose probability distribution is given by the two probabilities prob(X = 1) = P and prob(X = 0) = (1-P). We are interested in the random variable k defined as "the number of nodes e 1 among the n nodes". Let, p(k) is the probability of finding k times the e 1 among n nodes. In our case, the draw of n nodes from N is a simultaneous drawing (not orderly and without replacement). Thus, the probability distribution associated with this draw is a hypergeometric probability law with associated parameters n, N and P. It is defined by the following equation:

)݇( = ܥ ܴ ݇ × ܥ ܰ-ܴ ݊-݇ ܥ ܰ ݊ = ܥ ݊ܲ ݇ × ܥ )-1(݊ ݊-݇ ܥ ܰ ݊
We are interested in calculating the probability p(k≥1) defined as the finding data in the neighborhood at least once. This corresponds to the probability of finding a node e 1 at least once among the n nodes. The probability p(k) follows a hypergeometric law, so:

݇( = ݔ ݅ ) = 1 ݊ ݅=0
Where:

ݔ ݅ = {0,1,2,3, … , ݊}
This gives:

݇( = 0) + ݇( = 1) + ݇( = 2) + ⋯ + ݇( = ݊) = 1 ݇( = 0) + ݇( ≥ 1) = 1
So, p(k≥1) is:

݇( ≥ 1) = 1 -݇( = 0) Finally: p(k ≥ 1) = 1 - ܥ ܰ-ܴ ݊ ܥ ܰ ݊ Figure 5
shows the variation of p(k≥1) for different sizes of the neighborhood n and for each storage probability P. the figure shows that the greater the number of nodes n in each neighborhood, the probability of finding the information in each neighborhood increases. This probabilistic study shows that beyond a neighborhood size of 40 nodes, the information exists in every neighborhood regardless of the probability storage P (see figure 5).

b) Simulation study

In this simulation study, we validate the probabilistic results obtained in the previous section. For this, we simulate a communicating concrete precast using Castalia simulator. All the nodes are uniformly deployed within a 20x20m square. Wireless radio channel characteristics such as signal noise, interference ratio, and average path loss are chosen to simulate the realistic modeled radio wireless channel in Castalia based on lognormal shadowing and the additive interference models. Different number n of nodes in the neighborhood are simulated: 9, 15, 25, 37, and 45. Figure 6 shows the data existence ratio in the neighborhood for different sizes of n and for each storage probability P. The figure shows that, when the number of neighbor nodes n is increased, the probability of data existing in the neighborhood increases which gives a probability of more and more to find information in every piece of the precast. Following this figure, the disseminated data is present in the all neighborhood of almost all the nodes of the concrete (more than 80% and 90% of neighborhoods 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 neighborhood is very low for few number of nodes n = 9 (between 31% and 62%) and n = 15 (between 47% and 85%).

In conclusion, a large number of nodes n in each neighborhood in the sensor network increases the probability of finding data in all parts of the concrete precast.

C. Nodes density inside the concrete for efficient farthest neighbors selection algorithm

In this section, we study the impact of the variation of the neighborhood size n on the effectiveness of the farthest neighbor selection algorithm of the proposed data retrieval protocol. The validation of the effectiveness of this algorithm is a key function for the data retrieval protocol. The red nodes in figure 7 show the selection of the farthest neighbors. The results observation highlights that the proposed algorithm is high efficient for the highest neighborhood density (n = 25, n = 37, and n = 45). The algorithm perfectly works for a communicating concrete using high density of neighborhoods nodes. Low density in the neighborhood does not meet the expected results by the algorithm.

IV. DATA RETRIEVAL PROTOCOL PERFORMANCE

In this section, the data retrieval protocol is evaluated in terms of the number of covered nodes, delivery ratio, and delay metrics. The proposed protocol is compared with the performance of a simple RW+PG algorithm (without farthest neighbor selection and without link cost function). The proposed protocol uses TTL parameters to limit the retrieval path length. Thus, the maximum length of TTL is studied through statistics tools using the data existence probability in the neighborhood as parameters (see figure 6).

In the following, the TTL value is firstly studied. Then, the simulation results of the protocol performances are presented.

A. Maximum length of TTL

Using USEE, the information is stored in each sensor node with probability P [START_REF] Mekki | USEE: A Uniform Data Dissemination and Energy Efficient Protocol for Communicating Materials[END_REF]. This process resulted in a probability of existence of information in a neighborhood p(k) as discussed before in this paper. Let p be the probability p(k) of existence of information in a neighborhood.

In the data retrieval protocol, the request is broadcasted in the neighborhood of each hop. Each broadcast, there are two possible cases: i) the neighborhood contains the data in the memory of one of the neighborhood nodes (success), ii) any neighborhood node contains the data (failure). This presents a Bernoulli test where each launch has only two possible outcomes, called success and failure. Therefore, the data retrieval process presents a random experiment of repeating m times (m hops) a Bernoulli test of p as parameter. This Bernoulli schema is modeled by a tree that had two initial branches (success-failure), and each of these branches gives rise to two new branches (success-failure).

A succession of m independent Bernoulli trials (mN * ) allows the construction of a random variable S m counting the number of success after m Bernoulli trials. This random variable has the Binomial probability distribution with parameters m and p. S m is defined as follows:

ܵ ݉ = ݔ ݅ ݉ ݅=1
According to the Binomial distribution, for all 0≤k≤m: This result limits the length of the retrieval path. To be almost certain to find the information after m hops, we fixed P(S m ≥ 1) = 0.99. Finally, for all 0<p<1:

ܲ(ܵ ݉ = ݇) = ቀ ݉ ݇ ቁ  ݇ ݍ ݉-
݉ = -3 log(1 -p)
Figure 8 shows the path length m (which presents TTL value) for different data existence probabilities in neighborhood p. As example, for the probability 0.8<p<1 of n=45, TTL should be fixed to 4. For the probability 0.7<p<1 of n=37, TTL should be fixed to 5. For the probability 0.6<p<1 of n=25, TTL should be fixed to 8.

B. Data retrieval protocol performances

In this section, the performance of the proposed data retrieval protocol is evaluated and compared with the performance of a simple RW+PG algorithm. For this simulation, the neighborhood nodes density n=25 is used. For that, 2500 nodes are uniformly deployed in 20x20m concrete square (25 nodes in each 4 m 2 ). TTL=8 is used for n=25 as presented in the previous section. Finally, many data are stored in the simulated concrete using USEE protocol (one data for each storage probability P). The simulation experience is repeated 60 times and the average results are showed in the following, for the number of covered nodes, delivery ratio, and delay metrics.

a) Number of covered nodes

Figure 9 shows the number of nodes covered using the proposed data retrieval protocol and the simple RW+PG according to the number of hops. RW+PG solution randomly selects a neighbor node as next hop for request forwarding. This could lead to select neighbor close to the previous hop and hence the new coverage includes many nodes already covered by the previous hops. This issue is avoided by using our farthest neighbor selection technique. Figure 9 indicates the number of the new covered nodes in each next hop is more than RW+PG. The difference between the two protocols is clearer for high number of TTL. For TTL=3 as example, our protocol covers 8 nodes more than RW+PG. However, for TTL=8, the protocol covers 32 nodes more than RW+PG.

b) Response delivery ratio

Another important metric to be assessed is the average response delivery ratio. Figure 10 shows the average delivery ratio of the proposed protocol and the simple RW+PG. Figure 10 highlights that the proposed protocol outperforms RW+PG due to the consideration of the link cost function to choose the most powerful farthest node as next hop. Thus, the request and response messages are forwarded through a high quality of service path. Implementing a link cost technique in the data retrieval algorithm enhances the delivery ratio of the request and the response messages.

c) Average delay

End to end delay is also an important metric in evaluating data retrieval protocols. It is the elapsed time between beginning of request transmission and the reception of the response message by source node. Figure 11 illustrates the average delay of proposed protocol and simple RW+PG has almost the same. The proposed protocol uses both waiting times in each hop to interrogate the neighbors and FAR_INFO wait/process which causes more queuing delay. This waiting times increases the delay even if the request has more chance than RW+PG to find the data through the farthest neighbor selection.

V. CONCLUSION

In this paper, a new communicating concrete paradigm is presented for data storage and retrieval in intelligent precast. This paradigm is developed through uniformly integrating thousands of micro-sensor nodes in the concrete. The data is stored and then retrieved using multi-hop communication protocol for WSN. A previous data storage protocol called USEE is developed. However, this paper presents the data retrieval protocol. The protocol uses the multi-hop random walk process to forward the request to further nodes, and the pull gossip mechanism to interrogate the neighbor nodes in each hop. On this protocol, a mechanism called farthest neighbors selection and a cost function link were implemented. During request forwarding, only the powerful farthest neighbor is selected as next hop. This feature is very important in sensor networks since simple random walk forwards messages through randomly and low quality of service paths which causes failure in retrieval process. Moreover, the paper presents the instrumentation of the WSN inside the concrete. The adequate sensor node is chosen. Then, the density of nodes is studied for the best storage and retrieval protocols performances.

Fig. 1 .

 1 Fig. 1. Two request/response phases for data retrieval in WSN.

  (b).

  (a) Random Walk (b) Random Walk + Pull Gossip Fig. 2. Random Walk and Pull Gossip mechanisms.

  Fig. 3. Benefit of selecting the farthest neighbor in RW process.

e 1 :

 1 node containing the data e 2 : node empty of data E 1 : {all nodes e 1 } E 2 : {all nodes e 2 } As presented before, the storage probability of USEE is equal to P [5], let: R = Card (E 1 ) = NхP : total number of nodes e 1 N-R = Card (E 2 ) = Nх(1-P) : total number of nodes e 2

Fig. 5 .

 5 Fig. 5. Variation of p(k≥1) for different sizes of the neighborhood n and for each storage probability P.

Fig. 6 .

 6 Fig. 6. Data existence probability in neighborhood vs. Storage probability P.

Fig. 7 .

 7 Fig. 7. Effectiveness of the farthest neighbor selection algorithm.

  ݇Where : k : the number of successes. m : the number of hops. p : the probability of success in a hop. q : the probability of failure in a hop. Let P(S m ≥1) the probability of finding the information at least once after m hops: P(S m ≥ 1) = P(S m m k=1 = k) Moreover, by removing the case of not finding data after m hops: = P(S m = 0) + P(S m = k) m k=1 Using the Binomial distribution function of a random variable S m : m ≥ 1) = 1 -ݍ ݉ P(S m ≥ 1) = 1 -(1 -) ݉ 1 -P(S m ≥ 1) = (1 -) ݉ log(1 -P(S m ≥ 1)) = m × log(1 -p) For all P(S m ≥ 1) ≠ 1 and p ≠ 1: ݉ = log(1 -P(S m ≥ 1)) log(1 -p)

Fig. 8 .

 8 Fig. 8. Probability p vs. TTL.

Fig. 9 .

 9 Fig. 9. Number of covered nodes RaWPG vs. simple RW+PG.

Fig. 10 .

 10 Fig. 10. Average response delivery ratio of RaWPG vs. simple RW+PG.

Fig. 11 .

 11 Fig. 11. Average delay of RaWPG vs. simple RW+PG.

  Table and the N Table of its neighbors (N Table exchanged using TAB_EXCHANGE). A node Y is considered as farthest neighbor for X, if it has a minimum number of common nodes between N Table of X and N Table of Y.