Jovan Radak
email: jovan.radak@hds.utc.fr

Bertrand Ducourthial
email: bertrand.ducourthial@hds.utc.fr

Véronique Cherfaoui
email: veronique.cherfaoui@hds.utc.fr

Early Detection of Dangerous Events on the Road Using Distributed Data Fusion

Keywords: Vehicular networks, distributed data fusion, roadside units, wireless sensors, testbed, emulation, experiments

Intelligent transport systems are a fast developing area of research with great impact on everyday life. One of the main ideas in this area is to use all possible information, coming from vehicles and the infrastructure, in order to make the system "smarter" and avoid unwanted situations -collisions, accidents, bottlenecks... Sources of data are sometimes unreliable and may lead vehicles or the whole system to wrong conclusions and adaptations. We are presenting the application of a distributed data fusion algorithm to detect dangerous events on the road. This application is adapted to detect the possibility of encountering icy roads based on readings from wireless temperature sensors. It takes into account data not only directly obtained from sensors but also from the neighborhood of each element in the system. This way, we obtain a more robust solution that is flexible to the unreliabilities of the sources of data. We demonstrate the possibility to deduce proper results from unreliable data. The algorithm is tested in emulation, using data from a real testbed, to show the usefulness and correctness of our approach.

I. Introduction

A. Motivation

Enabling vehicles and additional communication infrastructure with "smart" algorithms may help solving some of the major safety problems [START_REF] Faouzi | Data fusion in intelligent transportation systems: Progress and challenges -a survey[END_REF] in vehicular networks. In early works in this area researchers noted the importance of smart cars and the challenges to build them [START_REF] Varaiya | Smart cars on smart roads: problems of control. Automatic Control[END_REF]. In general, the intelligence of vehicles heavily depends on a large amount of gathered data that is processed and then used to give drivers or vehicles useful information. This data may come from different sources and by its nature is heterogeneous. To process this large amount of data some form of data fusion has to be applied. Many different data fusion techniques are proposed [START_REF] Luo | Multisensor integration and fusion in intelligent systems[END_REF], [START_REF] Luo | Multisensor fusion and integration: approaches, applications, and future research directions[END_REF], depending on the specific problem that they solve and the sources of data [START_REF] Khaleghi | Multisensor data fusion: A review of the state-of-the-art[END_REF]. Fusion of information can be used in different applications, from various positioning problems [START_REF] Fogue | On the use of a cooperative neighbor position verification scheme to secure warning message dissemination in vanets[END_REF] to detecting false nodes in networks [START_REF] Zoghby | Distributed data fusion for detecting sybil attacks in vanets[END_REF]. This approach is specially suitable for future smart cities equipped with a large number of sensors that may act as data sources not only for their citizens but for vehicles as well.

One of the main problems in the fusion of large amount of data is the inaccuracy and reliability of data. It is relatively easy to come up with a conclusion how to mix two pieces of information when the data sources are homogeneous, reliable and give similar readings. However, in the case of conflicting or missing data sources it may be problematic to reach a decision. The theory of belief functions have this property which makes it suitable in the presence of imprecise, uncertain and incomplete data [START_REF] Dubois | Evidence, knowledge, and belief functions[END_REF].

In this paper, we present a distributed data fusion that is based on the theory of belief functions [START_REF] Ducourthial | Self-stabilizing distributed data fusion[END_REF] and its generic algorithm. We designed an application dedicated to the early detection of dangerous events on the road. This application relies on distributed data fusion taking into account conflicting pieces of information and applies calculations until it reaches a decision. We show that the application correctly assesses the risk of dangerous icy roads even when some sensors give wrong or conflicting information. Hence, this technique surpasses a simple alert diffusion and is more robust to deficient sensors.

B. Related work

Presence of numerous sources of data are making decision problems even more complex. The problem of information fusion is well studied in various research areas (sensor networks, image processing, etc). Different solutions were proposed to deal with large amount of data sources in various applications [START_REF] Luo | Multisensor fusion and integration: approaches, applications, and future research directions[END_REF]. Another important aspect is impact of driver's behavior on the functioning of whole system [START_REF] Dressler | On the impact of human driver behavior on intelligent transportation systems[END_REF]. In [START_REF] Malta | A study of driver behavior under potential threats in vehicle traffic[END_REF] authors demonstrated the importance of early and appropriate signaling to drivers of possibly dangerous events on the road.

Interesting solution that brings in the connection of in-car mobile applications, drivers and hazardous events is presented in [START_REF] Orhan | Road hazard detection and sharing with multimodal sensor analysis on smartphones[END_REF]. Authors have developed a system that detects speed bumps and potholes based on synchronized sensor readings and extraction from a video feed that is taken simultaneously with sensor readings. Although an interesting solution, this is limited to the usage of smartphones and specific capabilities of certain types of mobile phones. This study is also limited in terms of data dissemination, i.e. it is not clear how other users can make use of this data and if some calculations can be done cooperatively. In [START_REF] Schweiger | Elisatm -car to infrastructure communication in the field[END_REF] authors present a testbed that enables communication between vehicles and infrastructure. This testing infrastructure gives interesting results and shows the significance of this approach. However, due to the different scope of the article, authors do not cover the possibility of equipping the infrastructure with sensors that may communicate with vehicles.

We are presenting a solution that links these two interesting points. We investigate the possibility of using multiple sources of the same data type to deal with uncertainties. We show how, with the help of distributed data-fusion algorithms, we can make use of this data. Finally, a solution that gives an assessment of the risk of ice on the road is proposed. We discuss results and how this approach can be used to give drivers early warnings on the possibly dangerous events on the road.

We start our presentation defining the basic concepts of Belief functions and the principle of distributed data fusion. Then, we detail our application of the distributed data fusion algorithm for dangerous event detection (Section II). In Section III we explain how this application has been implemented as well as the whole detection system relying on sensors, road-side units, vehicles and dedicated software. Section IV presents our experimental study. Extensive study has been done thanks to a network emulator that reproduces the whole testbed as well as with real data obtained from the testbed.

II. Distributed data fusion for dangerous event detection

Data fusion can be described as a mechanism that combines data retrieved from different sources and further on reduces uncertainty on the gathered data or generates decisions based on the obtained data. In general, data fusion is either centralized (collecting data and applying an algorithm in some kind of central unit) or distributed (each unit is capable of applying the algorithm on data gathered locally -from the neighborhood). In the remainder of this section we present the basic notions of the Belief functions theory, a generic distributed data fusion algorithm based on this framework and the application of distributed data fusion to detect dangerous events on the road.

A. Theory of belief functions

The theory of belief functions or Dempster-Shafer theory is one of the widely-used frameworks in data fusion [START_REF] Khaleghi | Multisensor data fusion: A review of the state-of-the-art[END_REF]. This theory is specially suitable for modeling uncertainties and the lack of information [START_REF] Smets | Data fusion in the transferable belief model[END_REF]. This theory generalizes the probability theory and the possibility theory. In the Dempster-Shafer theory, a set Ω = ω 1 , ..., ω n of mutually exclusive propositions is called the frame of discernment. The main difference, compared to the probability theory is the fact that the mass of evidence is attributed not only to single hypotheses ω i , but to any subset of Ω, including the empty set.

Following the general framework for the belief representation [START_REF] Dubois | Evidence, knowledge, and belief functions[END_REF], we define the state of belief of node v on the global frame of discernment Ω. A state of belief is assigned using basic belief assignment that is most commonly represented as a mass function, m Ω . A mass function m Ω is a mapping from 2 Ω (the set of subsets of Ω) to the interval [0, 1] ∈ R. The sum of all masses is equal to 1. A mass value is directly proportional to confidence, the more the node is confident in A ⊂ Ω, the higher is m Ω (A). The masses can be combined with different types of operators such as the conjunctive operator which emphasizes agreement when it combines two mass functions that are reliable and independent or the Dempster's operator that ignores conflict, spreading it to the other sets. These two operators are associative and commutative. In this work, we are using the cautious operator [START_REF] Denoeux | Conjunctive and disjunctive combination of belief functions induced by nondistinct bodies of evidence[END_REF]. This operator is associative, commutative and idempotent. Idempotency is an important property because it allows data coming from sources that are not independent to be combined.

In the following, direct confidence refers to mass values of the data obtained solely from the node itself, while distributed confidence refers to the combination of the mass values from the node itself with those received from its neighbors. It thus combines all data sources in the network.

B. Distributed data fusion

We can now summarize the principle of the generic data fusion algorithm introduced in [START_REF] Ducourthial | Self-stabilizing distributed data fusion[END_REF]. This algorithm supposes that each node computes a mass function called its direct confidence starting from a local measurement from an external source of data (sensor). The basic belief assignment is done using sigmoid-like functions. These functions are used to map the measurement to a mass function, spreading confidence on focal elements, subsets of the frame of discernment Ω. The direct confidence (private mass values) is updated whenever a new measurement is produced by the local sensor.

Each node computes its distributed confidence periodically by combining its own direct confidence with the output of its neighbors. In order to solve the data incest problem, the cautious operator is used. Data incest appears when a single piece information from the same source is used in the fusion process more than once. Discounting is applied to each received distributed confidence to give the closer source a higher priority than the farther one. Thus, a distant source of information will still be taken into account to compute the distributed confidence of a given node but with less importance because its output will be discounted at each hop. As a consequence, the distributed confidence computed on a node is different from another node because while it takes into account the same sources of information (direct confidences of each node of the network), they are discounted differently depending on the position of the node in the network. The result reflects the local situation in the vicinity of the node without ignoring information from other, more distant, nodes. The idempotency of the cautious operator and the discounting operations ensure the convergence of the algorithm.

Then the distributed confidence is broadcast in the neighborhood. Each node stores the distributed confidences received from its neighbors until the next local computation. Hence, the direct confidence of a node will be taken into account by its neighbors, then by the neighbors of its neighbors and so on. In this way each node is contributing to the computation of the distributed confidence.

To summarize the behavior of this distributed algorithm, every node periodically computes its direct confidence from a local measurement using sigmoid-like functions. It also stores the distributed confidences sent by its neighbors. It periodically computes its own distributed confidence using its direct confidence and the last received distributed confidences from its neighbors. Then it broadcasts its direct confidence in the neighborhood. Old received messages are deleted after a delay of several periods of computation. Keeping old messages allows the output of a neighbor to be taken into account even if some message losses occur due to problems in communication. Nodes are not synchronized, they rather use their own timers.

C. Robust application for detection of icy road

In this work we focus on the application of distributed data fusion to detect icy roads. Our aim is to have information that can be used to warn the drivers when they approach a slippery road. This application allows us to illustrate the usefulness of distributed data fusion for intelligent transportation systems. Similar applications could be designed for other road hazards. While it is clear that the road is dangerous for some temperatures and not for others, there exists a range of temperatures where there is a doubt. In here we define three states for the road, as a first approach, corresponding roughly to three ranges of temperatures. These states lead to the definition of the following frame of discernment: Ω = {freeze, slip, safe}.

We have assigned basic belief assignments from temperature sensor measurements using sigmoid functions defined for the subsets of the Ω set. The idea is to give a large mass to the state corresponding to the measured temperature and less to others. The closer the measurement gets to a threshold between two states, the more the mass is spread over several subsets of Ω. Moreover, we do not completely trust the sensors and a mass is always given to the subset Ω itself, representing the doubt (given as α). When affecting the masses for the direct confidence, there is no values for the subset ∅ because it represents the conflict. However some values may appear for ∅ after combination of several sources in the distributed confidence. The thresholds and referent values that define the road states are chosen in such a way that they correspond to real values. These parameters can be changed easily so that we can create a model that can be tested with higher temperatures (than those that produce frozen road). Sigmoid functions are given as:

m{ f reeze} = (1 -α) - 1-α 1-e -λ(Tcur -T re f +T thr1 ) (1) m{slip} = 1-α 1-e -λ(Tcur -T re f +T thr1 ) - 1-α 1-e -λ(Tcur -T re f -T thr1 ) (2) m{slip, sa f e} = 1-α 1-e -λ(Tcur -T re f -T thr1 ) - 1-α 1-e -λ(Tcur -T re f -T thr2 ) (3) m{sa f e} = 1-α 1-e -λ(Tcur -T re f -T thr2 ) (4) m{Ω} = α (5)
where T cur is current temperature -value read from the sensor, T re f , T thr1 , T thr2 and λ are the reference values chosen in such a way that sigmoids correspond to real values and have appropriate shapes. The value α = 0.2 corresponds to the belief that none of the values for the temperature is correct (doubt).

We have used parameters for sigmoid functions in such a way that they reflect actual possibilities for the frozen road condition. For our purposes, the road is sa f e for temperatures above 7

III. Implementation of the detection system

In the previous section, we introduced our distributed data fusion application for frozen road detection. In this section, we present the implementation of the whole detection system relying on sensors, road-side units, vehicles and related software. We first present the overall architecture. Then we describe the hardware components of the system. Next we introduce the framework used to implement the applications before describing the software components of the system.

A. System architecture

Our detection system relies on stationary and mobile temperature measurements combined using our distributed data fusion application described in the previous section. The fix measurements are performed by wireless sensors close to the road that send their measurements to some solar road-side units (Figure 2). The road side units communicate between themselves and with equipped vehicles in their transmission range. Vehicles used in the testbed are equipped with hardware units allowing them to communicate with road-side units. They broadcast their own confidence about the road state, calculated from their own temperature and those received from the RSU.

The RSUs use wifi to communicate between themselves and with vehicles. Messages that are exchanged in this communication are those of the distributed data fusion application, namely the distributed confidence that is computed periodically by each node. Communication with sensors relies on dedicated packets exchanged with zigbee modules -that both wireless sensors and RSUs have.

B. Hardware components

For development and testing purposes we have designed and deployed the hardware of the testbed that consists of cheap off-the-shelf wireless sensors and dedicated road-side units, called Airbox (developed in our laboratory).

The testbed is deployed using 3 road-side units and 3 Xbee sensors communicating with them wirelessly via the 802.15.4 protocol. Data is gathered using the serial ports of the RSUs. We have developed a support program that is used to connect computing units (RSUs or regular PCs) with wireless sensors Wireless sensors1 are equipped with a temperature sensor. We have deployed a simple topology -using exactly one sensor for each RSU. The support program allows more complicated scenarios with multiple sensors per RSU but this strictly depends on the application for which this testbed is used.

The Airbox units are based on the IGEP platform2 -a TI OMAP controller with 512 MB of RAM. They are running the Linux operating system and a software suite developed for these purposes. The driver part of the support program is responsible for establishing a connection between the Airbox serial port, the Xbee module and the Xbee sensor. The application exchanges binary packets between the RSU and the wireless sensors and decodes them upon reception. Decoded data is further transfered to other applications that may use them.

C. Airplug framework

The Airplug software distribution is a program suite based on the Airplug framework aiming to fully support simulation, development, testing and deployment of dynamic networks. This is a simple framework based on a few development rules that focus on the implementation of portable software for highly dynamic networks. These rules are: (i) usage of standard input/output system to ensure independence of programming language implementation, (ii) use of standard ASCII text messages to ensure portability (possibility of usage in different operating systems); (iii) simple message addressing scheme which includes addressing of applications with the pair values (app name, host name) and (iv) relying on broadcast and on managing message visibility with subscriptions to certain applications.

The Airplug software distribution is developed, mostly using Tcl/Tk programming language, to support several modesindependent implementations that are complementing each other. These modes include: the terminal mode -standard UNIX compatible command line implementation; the emulation mode -network emulator that simulates lower layers of protocol stacks while keeping upper layers the same as in experiments and the live mode, an efficient implementation suitable for execution on constrained embedded systems during real experiments.

The Airplug software distribution is easily extended simply by writing applications (in any programming language) that follow those guidelines.

D. Software components

The application that makes the connection between the wireless sensors and the RSUs is called XBE. This application provides binary packet exchange between Xbee sensors and the system on which it is run (a PC or an embedded platform such as the Airbox). On the lower level, the XBE application enables communication and packet exchange in the proprietary format of Digi International using serial port and an Xbee module. On the upper layer the XBE application sends the temperature data gathered from the Xbee sensor. XBE application can be used in different scenarios. While its basic feature is to gather data from wireless Xbee sensors and transfer them to the other applications, it can also be used to gather data in a predefined log file, to read data from log files that were created in previous experiments and to read user-generated data files. Basic manipulation of gathered data is possible. For example, we can offset to the data actually read to simulate different environmental conditions (useful for recreating a specific type of environmente.g. winter temperatures during summer). Log files can be read at the same rate that was used during recording or at a higher rate as specified by application parameters. All these parameters can be used in both emulation and live modes [START_REF] Radak | Design and implementation of the vehicular network testbed using wireless sensors[END_REF].

For the purposes of testing and development of distributed data fusion algorithms we have developed the MET application. This application is a practical implementation of the belief function framework explained in Section II. This application is able to generate values, that are needed to study the robustness properties of the algorithm and to generate testing measurements according to a given function and periodicity. This last feature has been used on the Airbox units embedded in vehicles not equipped with temperature sensors and for emulation. Another possibility for this application is to take measurements from the other applications. This functionality is used in our experiments. XBE sends gathered data and MET applies data fusion on the received data (Figure 1).

MET can apply any user-defined frame of discernment (Ω set) and sigmoid functions defined for it. Independently of the data source, MET uses sigmoid functions, defined with equations (1) to [START_REF] Ducourthial | Self-stabilizing distributed data fusion[END_REF] and calculates direct confidences according to the received values and the defined frame of discernment. It then proceeds with the calculation of the distributed confidence according to the algorithm detailed in Section II. These calculations are done periodically. The periods are independently defined for each instance of MET. When a new set of results is obtained the data is sent to the neighbors. One instance of the MET application handles input from one sensor, in case that we have more sensors we can run multiple instances of MET each handling one sensor input.

The applications described hereafter have been designed and tested using the terminal mode. Then we have deployed them on the previously described testbed using the Airplug live mode. The extensive study presented in the next section has been done by reproducing the testbed in the emulation mode. This is a convenient way to see the influence of parameters and input data.

IV. Experiments and results

A. Experimental setup

The testbed presented in the previous section has been validated during real tests. As we lack the space, we do not give details about these tests in this article. Instead, we focus on the behavior of the whole system with different inputs. For this purpose we rely on the emulator mode of the Airplug distribution. Airplug-emu accepts the same programs as those deployed on the Airboxes and it is able to reproduce with a high accuracy the real tests [START_REF] Buisset | Vehicular networks emulation[END_REF]. GPS positions are the same as in the real experiment, both for the RSUs and for the vehicle (Figure 3). GPS traces for vehicles have been saved during the real test and replayed during the emulation. There is no real sensor in the emulation; the XBE applications are also used in emulation mode: they output data coming from a log file recorded during the real test. Additionally, all the applications will also output the generated data, allowing us to study the behavior of our system We divided our study in two groups of scenarios. The first one, called static, considers only the three RSU and their local temperature sensor (there is no vehicle). It allows us to show the influence of one RSU and its local measurements on its neighbors. The second group, called dynamic, considers the three RSUs with their sensors and a vehicle. Figure 3 shows a screenshot of the Airplug emulator, with openstreetmap tiles as background. It depicts the testbed close to the laboratory. The blue arrow shows the direction of the vehicle on the road, which is represented by a blue circle. The RSUs are represented by green squares. The vehicle first encounters the RSU-L (for Library), then the RSU-G (for Garage) and finally the RSU-P (for car Park). Each element in the emulation has a small histogram next to it, that represents the confidences computed in the previous step. The dynamic scenarios show the interest of our dangerous event detection system when a vehicle is approaching the icy road that is located close to RSU-P in our experiments.

In each group of scenarios (static or dynamic), we considered two cases. The first one is the normal case where all sensors output correct temperature measurements. The second one is the disturbed case where the sensor connected to the RSU-G close to the garage is placed inside the garage. It then measures higher temperatures that do not reflect the road temperature. This is an extreme case of misplaced sensor. We would like to study the behavior of our system in such a situation. In the following, the first scenario is called outside because all sensors are placed outside. By opposition, the second is called inside because a sensor is placed inside of the garage. We will then study four scenarios, namely static-outside, static-inside, dynamic-outside and dynamic-inside.

Road temperatures in the outside scenarios are 3 • C, -1 • C and -3 • C for the RSU L, G and P respectively. The icy road representing the danger is close to the RSU-P. This setup is used to emulate sudden drops of temperature that may happen on the road due to changes in the atmospheric pressure or the environment. In the internal scenarios, the temperature given by the sensor of RSU-G is 21 • C. The other sensors output the same temperature as in the external scenario.

In order to have realistic emulated mobile scenarios, decreasing temperatures have been generated in the vehicle. For this purpose, we used the MET application in the vehicle in emulation mode so that it generates temperatures according to a given function. Starting temperature for the vehicle is 7 • C and it decreases linearly each second with 0.133 • C/s steps. The function for the temperature that the vehicle "measures" is constructed in such a way that the vehicle reports temperatures similar to those of the RSUs at the time it is passing close to them.

B. Results for the static scenarios

The static-outside scenario shows the adaptation of distributed confidences calculated by each RSU. Due to the fixed temperatures, chosen for the static-outside experiments, the distributed confidences (shown on Figures 4(a), 4(b) and 4(c)) have a short period of transition after which they settle to stable values. The values for distributed confidence correspond to their direct confidences (calculated from sigmoid functions knowing the temperature that each one of them is receiving) but we can also see the influence of the neighborhood on these calculations. Thus, for RSU-L, the distributed confidences for the {slip} and {slip, sa f e} subsets are different than the direct confidence that it calculates, and in this case it corresponds more to the values calculated by RSU-G. The static-inside scenario shows how distributed data fusion adapts when one of the RSUs is receiving data that is very different compared to neighboring RSUs. In this case we can see, similarly to the previous case, the influence of the measurements from RSU-G on those of RSU-L. RSU-G measures the highest temperatures (21 • C) thus it influences the increase of the distributed confidence for the {sa f e} value. We can see the same influence on the RSU-P. This RSU is receiving measured temperature well beyond the level of its own {sa f e} state and yet its {sa f e} state has the highest value.

We used the static scenarios to show how different readings from external sources of data and direct confidence influence the distributed confidences of the neighbors. We can conclude that drastic changes in retrieved values on one RSU can bring in significant changes in the distributed confidences on the neighboring RSUs.

C. Results for the dynamic scenarios

In the beginning of both dynamic scenarios the vehicle is out of range from any RSU. The periods of communication with the different RSUs are given on Figure 6 and they are: T L , the period in which the vehicle only communicates with RSU-L from t = 12s to t = 28s; T LG , the period in which the vehicle communicates with RSUs L and G from t = 28s to t = 41s; T LGP , the period in which the vehicle communicates with all three RSUs from t = 41s to t = 51s; T GP communication with RSUs G and P from t = 51s to t = 70s; and T P communication only with RSU P from t = 70s to t = 73s.

For the dynamic-outside scenario we can see that the direct confidences for the vehicle (Figure 7 Vehicle is getting warning at t = 12s of the possibility of ice on the road before it actually reaches this point t = 40s Fig. 7: Results for dynamic-outside scenario distributed confidences giving the highest value to the {slip} state under the influence of the confidences calculated by RSU-L. In this way the vehicle effectively predicts the possibility of a dangerous event (icy road) even though it is far away from it. The vehicle is then coming closer to the dangerous spot, the temperature measured by the vehicle decreases, changing its direct confidences. Comparing Figure 7(b) and Figure 7(c) we can deduce that in this period (T LG ), the distributed confidence change is occurring before its direct confidences change. In this case, the direct confidence just enhances this change, making it even more obvious. Similarly, we can deduce that the distributed confidence for the { f reeze} state is starting to increase much earlier than its direct confidence. This is again due to the influence of the measurements from the RSUs, and in this case this is prevalently due to the influence of RSU- The main goal of the dynamic-inside scenario is to observe the way that distributed confidences are adapted in case of extreme differences in sensor readings. From the distributed confidences of each RSU (Figures 8(a)-8(c)), we can conclude that a high temperature that read by RSU-G has a large influence on both RSU-L and RSU-P. These three figures show that the influence of RSU-G dominates, bringing in the highest values for the distributed confidence for the {sa f e} value. However, we can also observe that passage of the vehicle is bringing in the change which corresponds to the real situation (decreasing temperatures in successive RSUs). This is visible in the periods T LGP and T GP , when the vehicle is connected to RSU-P and at the same time reaches lower temperatures in its own measurements. We can conclude that it influences the distributed confidences calculated by the RSUs bringing their calculations much closer. The distributed confidence of the vehicle reveals that the measurements correspond to the real case i.e. direct confidences calculated from the vehicle are influenced by the RSUs. Nevertheless, the vehicle keeps its calculations of the distributed confidences, thanks to the belief function framework that spreads confidence to several subsets of the frame of discernment. In this case, the vehicle is again capable of detecting the dangerous spot on the road but due to the anomaly caused by the readings from RSU-G this detection is happening later when the vehicle gets in the range of all three RSUs and its own direct confidences start to change values.

V. Conclusion

In this paper, we have presented an application of distributed data fusion for early detection of dangerous events (icy roads), based on the belief functions theory. Our application combines several sensors measurements and propagates a mass vector with confidences on all the subsets of the frame of discernment that characterizes the different states of the road (freezing, slippery, safe). The main advantage of this technique is its robustness to wrong measurements and to give earlier warnings to drivers.

For development and testing purposes we have designed a complete testbed consisting of wireless sensors and solar RSUs communicating with WiFi between them and with vehicles. Extensive studies have been done by emulation, using data retrieved from our testbed, in different scenarios -with regular and erroneous measurements, using vehicles and RSUs. Results show that our application enables warning for approaching vehicles earlier than a simple alert broadcast generated when an average temperature is under a threshold. Moreover, data fusion can generate alerts for the approaching vehicles even when one of the sensors gives completely different measurements. Future work will include extensive road experiments with our testbed as well as adaptation of our application to other hazards. We also plan to investigate usage of pignistic probabilities in making the decision that is transmitted to the driver and to incorporate it in standardized environmental notification messaging system (DENM).

VI. Acknowledgments

Fig. 1 :

 1 Fig. 1: Testbed with xbee sensors, road-side units and software support from Airplug platform

  • C, road status is between sa f e and slip in the interval {3 • C, 7 • C}, road is most probably in the slip state in the temperature interval {-1 • C, 3 • C} and most probably in the f reeze state for temperatures below -1 • C. The sigmoid functions shapes for these referent values can be seen in the Section IV on Figure7(b) where local values are decreasing linearly with time allowing direct confidence to take the shape of sigmoid functions.

Fig. 2 :

 2 Fig. 2: Hardware elements of the detection system

Fig. 3 :

 3 Fig. 3: Map showing positions of road-side units (green squares) and vehicle's (blue circle) direction of movement (blue arrow).

Fig. 4 :Fig. 5 :

 45 Fig. 4: Distributed confidences for road-side units during the emulation in static-outside scenario.

  Fig. 6: Distances of vehicle from different RSUs; shown only when the vehicle is in the communication range of RSU

  (a) Distributed confidences calculated by the RSU L. Measures are adapted and they take into account direct confidences from vehicle. (b) Distributed confidences calculated by the RSU G. Direct confidence calculations received from vehicle from t = 33s to t = 68s are influencing the change of distributed confidence calculated by RSU G. (c) Distributed confidences calculated by the RSU P, two conflicting measures {freeze} and {safe} have highest values -due to the influence of RSU G.

Fig. 8 :

 8 Fig. 8: Results for dynamic-inside emulation scenario

Fig. 9 :

 9 Fig. 9: Distributed confidences for the vehicle in the dynamicinside scenario. Due to the readings of RSU-G, the vehicle is getting delayed warning of a possible icy road ahead.

http://www.digi.com/products/wireless-modems-peripherals/wirelessrange-extenders-peripherals/xbee-sensors

2 https://www.isee.biz/products/igep-processor-boards

This work was carried out and funded in the framework of the Labex MS2T. It was supported by the French Government, through the program "Investments for the future" managed by the National Agency for Research (Reference ANR-11-IDEX-0004-02). It has been partially supported by the Celtic Plus project CoMoSeF Cooperative Mobility Service of the Future.


Jovan Radak

Bertrand Ducourthial

Véronique Cherfaoui

Stéphane Bonnet

Design and Implementation of the Vehicular Network Testbed Using Wireless Sensors

Keywords: Wireless sensors, roadside units, testbed, emulation, experiments, Airplug, Airbox

Testbeds are indispensable tool in research and development process in wireless networks technologies. They show us how our solution is going to work in real environment. In the recent years there is a growing trend in the development of testbeds aimed to be used as tool for both research and verification of the results obtained theoretically and using simulators. We are presenting experimental vehicular network testbed based on the cheap, off-the-shelf wireless sensors that are gathering environmental data, temperature, humidity and luminosity. These sensors are connected to the road-side units (RSUs) running Linux operating system and dedicated software distribution, Airplug. This complete system (wireless sensors, RSUs and Airplug software distribution) can be used for simulation, emulation and experiments in vehicular networks but also for any other type of wireless network. We are using this system for the gathering of environmental data and then re-using collected data in the different emulation and experimental scenarios. We are showing the usefulness of our wireless sensors testbed and possible scenarios of its usage in emulation and real experiments.

Introduction

Practical implementation is one of the final steps in research and development for the novel solutions in wireless ad-hoc networks (and in general research and development process). This step is performed in real hardware platform and it is usually the most critical one. The problem lies in the complexity of the hardware platforms that cannot be completely taken into account in the process of modeling and simulations of the wireless ad-hoc networks. Thus, dedicated hardware platform should be used for implementation and testing of the solution previously developed for some specific problem.

Different kinds of high-quality network simulators (like ns2, ns3, Omnet++ -just to name a few) are currently in use as primary tool for the development and testing of solutions for wireless ad-hoc networks. Network simulators have large user base who developed different kinds of libraries that suit specific problems that they are addressing. It is relatively easy to find library for the specific problem that we want to tackle (for example tens of different energy efficient MAC layers for wireless sensor networks) and to run the simulation for our targeted instance (for example 50 fixed sensor nodes with 20 mobile nodes that have moving pattern that corresponds to the movement of the buyer in the supermarket). But, the main problem remains in the limitations of the models used in different simulators (their accuracy and completeness) and the lack of compatibility between imposed models, hardware platforms and real scenarios that are planned to be used in implementation.

Emulation using network simulators [START_REF] Mahrenholz | Real-time network emulation with ns-2[END_REF] or using dedicated platform [START_REF] Pavkovic | From real neighbors to imaginary destination: Emulation of large scale wireless sensor networks[END_REF] takes the middle ground between simulation and experiments. It usually includes mix of the real hardware or data retrieved for the real hardware and simulation. In this way emulation can be viewed either as an enhanced simulation or as some kind of experiment with the limited number of hardware elements. Indeed this is an approximation of the real experiment that guarantees the flexibility of the simulation with more realistic data but at the cost of limited hardware usage. This approach is advocated because of its practical usefulness and flexibility in rapid application development and testing. However, the main problem, previously mentioned for the network simulators, remains -limitations of the used models and gap between it and dedicated platform planned for implementation.

We are presenting our testbed for vehicular ad-hoc networks. This testbed is developed to be used in conjunction with the previously developed tools for simulation and testing of dynamic wireless networks. We are using cheap, off-the-shelf, wireless sensors that are gathering environmental data -temperature, humidity and light. Our solution is based on the usage of wireless Xbee sensors1 (produced by Digi international), Airbox units, dedicated hardware based on the IGEP2 developments boards and the Airplug software distribution, developed in our laboratory. Airplug is modular and flexible software platform developed for the simulation, emulation and testing of the dynamic wireless networks (and more general distributed systems) that can be used on any Linux compatible platform. Thus, our testbed is not limited on this specific embedded architecture (like Airbox), it can be used on any Linux compatible embedded platform or desktop computer that fulfills small subset of requirements. Airplug also allows us reuse of previously gathered data in such a way that we can either emulate entire experiment on a single computer or recreate experiments using dedicated hardware.

The solution that we are proposing in this article is specific in four aspects:

-Fully developed solution -it consists of the hardware and software elements that can be used as-they-are without any modifications. Currently we are using environmental wireless sensors that measure temperature, humidity and luminosity. -Mobile platform -our current testbed is fixed and developed close to our laboratory but using our guidelines, hardware and software distribution it can be developed on any site -indoors or outdoors, using different hardware platforms. -Modular platform -our platform is modular in both physical implementation and program support. Additional hardware elements can be easily added and they do not depend on the manufacturer as long as they comply with general communication standards used in our platform. Airplug platform is compatible to any Linux system, so any hardware platform (Linux compatible) can be use to extend current physical implementation. Also, additional program support can be developed using development guidelines for our software platform. -Flexible platform -this platform is developed to be used in the experiments with vehicular networks, but it is flexible and can be used in other types of experiments with devices like UAVs (unmanned air vehicles) or robots as long as the communication modules of these devices are compatible to the ones used in our platform.

In this article we are going to present our solution for vehicular network testbed emphasizing the usage of wireless sensors in it. We will also present program support for these wireless sensors and possible applications of the testbed equipped with environmental sensors. The rest of this article is organized as follows: Section 2 presents the work related to our solution, overview of testbeds used for wireless ad-hoc and sensor networks and the approaches in network emulation, Section 3 presents general hardware architecture of our testbed, while Section 4 presents Airplug software distribution and specific application support for the usage of wireless Xbee sensors. Section 5 provides example of the data gathered using our testbed and possible scenarios of the usage of our solution. Finally, Section 6 presents our conclusion of this article and ideas for the future work.

Related work

In the recent years we have seen the great effort to develop experimental infrastructures for the wireless ad-hoc networks and Internet of things paradigm that will allow researchers to test their solutions in real world environment. Some of these platforms are developed for specific applications while the others are more generic and can be used for a wider range of problems.

Smartsantander is a platform developed for research and experimentation with wireless sensor network and Internet of things in urban environment. It is a city-scale test site consisting of 20000 sensor nodes developed in 4 cities across the Europe: Belgrade, Guilford, Lübeck and Santander [START_REF] Sanchez | Smartsantander: The meeting point between future internet research and experimentation and the smart cities[END_REF]. It is mainly viewed as a platform for the experiments with the Internet of things services and infrastructures in the smart city. So far it is used for the various experiments including the streaming of acoustic data [START_REF] Pham | Streaming the sound of smart cities: Experimentations on the smartsantander test-bed[END_REF]. GreenOrbs in China is the test site deployed using wireless sensor nodes and than mainly aimed forestry applications [START_REF] Bo | Locating sensors in the forest: A case study in greenorbs[END_REF]. It has evolved in the dedicated environment monitoring system for real-time CO 2 management in the city [START_REF] Liu | Citysee: not only a wireless sensor network[END_REF] Wisebed [START_REF] Hellbruck | Using and operating wireless sensor network testbeds with wisebed[END_REF] proposes different approach to the testbed infrastructure. It is a joint project of 9 different institutions in Europe with the test consisting of 750 sensor nodes (with different types of sensors both static and mobile) organized in federation architecture. This platform also supports virtualization and co-simulation with the part of the testbed. OneLab [START_REF] Fdida | Onelab: Developing future internet testbeds[END_REF] is also federation of the platforms but it aims in helping both developers and users of the platform. It is open to third-party platforms allowing developers to promote their testbed but also users to chose among variety of testbeds that fits best to their testing platform.

Senslab is a large experimentation testbed deployed in 4 cities in France -Grenoble, Lille, Rennes and Strasbourg [START_REF] Ducrocq | Large scale geolocalization and routing experimentation with the senslab testbed[END_REF]. It consists of 1024 sensor nodes (WSN430 nodes developed specially for this project) with 2 types of radio chips and several environmental sensors. This platform's main purpose is for the experiments with wireless sensor networks both in high and low level of abstraction [START_REF] Des Roziers | Two demos using senslab: Very large scale open wsn testbed[END_REF]. Additional tools are also developed: simulators WSim (simulating sensor nodes) and WSNet (wireless sensor network simulator) and ports for different kinds of real time operating systems (FreeRTOS, TinyOS, Contiki). Currently, there is an ongoing upgrade of Senslab platform, called IoT Lab 3 . This platform promotes new approach in the architecture of the testbed which is basically a service allowing users hands on experience with real platforms. Wisebed, SmartSantander and Senslab are parts of this platform allowing users multidisciplinary research in the area of wireless networks and Internet of Things.

Emulation is widely used as a term that explains uses of both hardware and software in the process of evaluation and experimenting. The term emulation covers different approaches in testing and evaluation and it goes from pure simulation with the enhanced models [START_REF] Girod | A system for simulation, emulation, and deployment of heterogeneous sensor networks[END_REF] to the usage of smaller hardware platforms to replicate results of large scale networks [START_REF] Pavkovic | From real neighbors to imaginary destination: Emulation of large scale wireless sensor networks[END_REF] [START_REF] Coulson | Flexible experimentation in wireless sensor networks[END_REF].

In our laboratory we have previously developed Airplug software distribution. This platform is the complete system that can be run several different modes including simulation, emulation and experiment mode. The user defines the parameters of Airplug usage on the start of application giving details about the scenario (type of mobility or fixed position, range, type of communication..., number of nodes as well as the mode of usage ).

The solution that we are proposing in this article is enhanced comparing to the current testbed solutions in three aspects:

-Hardware and software co-development -both physical architecture and program support are developed simultaneously i.e. if we decide to use new type of wireless sensors that are measuring different set of values then we are also developing appropriate software support for that piece of hardware. -Mobility -while the other testbed solutions also propose certain kind of mobility to the nodes (or subset of nodes) used in testbed our solution is unique in the sense that each part of the hardware platform can be easily relocated according to our needs in the experiment, also the same type of dedicated hardware (Airbox) can be used as the part of in-vehicle hardware platform making it fully mobile. Although we envisaged this testbed for vehicular network testing and development, it's concept can be used for different types of mobile agents -robots or unmanned air vehicles -and it can be easily transformed (using same software platform) in the testbed for other specific purposes (obstacle avoidance, object tracking,...). -Modularity -additional software elements can be easily added and they do not depend on the type of the elements used in physical implementation as long as they comply with general communication standards used in our platform. This means that if we need to test for example multi-hop routing algorithm we can develop application that implements that specific algorithm and to deploy additional number of Airbox units that will allow us to have appropriate test results.

Architecture of our testbed is simple, it consists of wireless Xbee sensors and Airbox devices (dedicated embedded hardware). In the terminology of the vehicular networks Airboxes are road-side units -RSUs (we will use these two terms interchangeably throughout this paper). In the creation of the wireless sensor testbed our leading ideas were simplicity of usage, modularity and mobility of the given solution. Following our main concepts we have decided to use simple wireless sensors that do not communicate between themselves but only the device that is hierarchically above them in this case with the road-side units. To avoid possible data collisions we have decided to use different wireless standards for communication with sensors and for communication between RSUs. Figure 1 presents conceptual scheme of our testbed. Wireless sensors are communicating only to the RSUs that are in their neighborhood using dedicated communication link (802.15.4 standard). All road-side units are running Airplug software distribution (more details about it in the Section 4) that has application dedicated to communication with Xbee sensors -given as XBE block in Figure 1. Each RSU can serve one or more Xbee sensors. RSUs communicate between themselves using wifi communication link (802.11).

Configuration, that we are showing in Figure 1 is fixed. This means that each Airbox used in this configuration is actually a road-side unit. Airboxes that we are using inside of the vehicle cannot communicate with wireless sensors (they are not equipped with Xbee modem), they are meant to gather data from vehicles using other interfaces, namely using CAN bus.

Wireless sensors

We are using cheap off-the-shelf wireless Xbee sensors equipped with temperature, humidity and luminosity sensors. They are using Xbee modem based on the 802.15.4 protocol to communicate with other devices. These sensors are not able to exchange messages between themselves, only to the device that is hierarchically above them. -Polling -Xbee modules are configured in such a way that they initiate periodical reading of the sensors and transfer of the retrieved data. -Upon request -RSUs are initiating reading of the sensors sending the specific read request packet to Xbee sensors; for this to be available all Xbee modems must have API mode enabled.

Road-side units

Road-side units are dedicated embedded hardware units, called Airbox. They are based on the IGEP platform. These units are running Linux operating system and Airplug software distribution. RSUs are equipped with Xbee modems that allow them to communicate with wireless Xbee sensors. They are also having wifi communication module that allows them to communicate between themselves and to form ad-hoc network. RSUs and Xbee modems are configured to communicate using API mode of Xbee modems. This means that they exchange dedicated packets that follow the rules imposed by their manufacturer (Digi international). 4

Placement of the testbed

We have chosen to deploy our testbed near to the Research Center of the Technological University in Compiégne. Three road-side units are deployed. Configuration of the RSUs is shown on the Figure 4. RSU1 is deployed close to the garage and has continuous power supply making it available all the time. RSU2 and RSU3 are deployed in the parking space, closer to the street. In this way they can exchange messages with the vehicles equipped with Airbox units. These two RSUs are using batteries as a power supply, their autonomy is roughly around 20 hours.

Xbee wireless sensors (not shown on the Figure 4) are deployed in the proximity of each road-side unit. RSU2 and RSU3 have one Xbee sensor in their proximity while RSU1 has 2 Xbee sensor, one placed inside of the garage and the other one positioned outside of the garage. In this way it is possible to obtain different readings and to use this data in other applications.

Program support for wireless sensors testbed

Important part of our testbed is its program support, it is based on the Airplug software platform 5 . To incorporate wireless Xbee in our testbed and in the Airplug software dis-Fig. 4. Geographical position of the road-side units, RSU3 is shown in the upper left corner encased with an energy harvesting module tribution sensors we have implemented dedicated, Airplug compatible, application that implements all the functionalities of the wireless sensors. In this section we will give brief overview of Airplug software distribution and its functionalities and the support for the Xbee sensors, more details about design philosophy and Airplug's architecture can be found out in previous publications [START_REF] Ducourthial | Designing applications in dynamic networks: The airplug software distribution[END_REF].

Airplug software distribution

Airplug software distribution actually presents practical implementation of the Aiplug framework. This framework is developed to support dynamic wireless network and it is based on the few simple guidelines:

-Independence of the programming language implementation -to follow this guideline framework is using standard input/output channels (each programming language can read/write from input/output channels). -Portable message format -we are using ASCII text messages, binary messages, if needed, are encoded; the only limitation is that the field delimiter (for the different parts of the message) cannot be used as the part of the field -Simple addressing scheme -Airplug compatible applications are uniquely addressed with a pair (application name,host name); communication between nodes rely mainly on the broadcast in the neighborhood thus three keywords are reserved for the host: AIR when we broadcast to all neighboring nodes, LCH when we broadcast to all local applications (run by the localhost) and ALL includes both local and remote broadcast Airplug software distribution presents several implementations that are also called modes. These modes are standalone implementations and they are complementing each other, i.e. while the one is dedicated for the laboratory studies, the other is used in real experiments.

Terminal mode is also called airplug-term, it is based on the implementation of the Airplug framework in UNIX compatible terminal. This mode is dedicated for the rapid application development and prototyping and it gives many functionalities thanks to the wide range of libraries. These libraries are dedicated to Tcl/Tk programming language but they can be also programmed in any other programming language as long as they comply with message format and addressing scheme.

Emulation mode is also called airplug-emu, it is a network emulator with the upper layers (of the communication stack) same as the ones in the real experiments while lower layers (physical communication) are reproduced -simulated. Emulation scenarios are described using XML files with the possibility to detail each node's mobility and the applications that are running on each of the node. This mode can be extended using remote mode (airplug-rmt) that allows some applications to use remote execution connecting them via sockets to a dedicated application called RMT (an application that relays messages between computers).

Live mode also called airplug-live, is the implementation dedicated for the real experiments. It is efficient implementation written in C programming language and it manages both local and inter-node communication while running on the top of POSIX compatible operating system. This implementation actually represents middleware between Airplug compatible applications and network interfaces.

Xbee sensors connectivity

Program support for the wireless Xbee sensors is Airplug compatible applicationcalled XBE -written, like the most Aiplug libraries, in Tcl/Tk. This application (XBE) is compatible with all Airplug software distribution modes, meaning that it can be run both on the PC running Linux terminal, but also on the embedded devices used in experiments, running airplug-live.

XBE establishes connection between xbee modem and serial port of the device running the XBE application, using either predefined configuration settings for the serial port or the settings that user gives upon the start of XBE application. It communicates with Xbee sensors sending the request for read packages either periodically or upon the users request (on the graphic user interface -GUI). Communication with other applications is periodic and the messages containing sensors readings, unique ID and time-stamp of the reading of each sensor are sent with the period that user defines on the start of application. Sending of message is also possible on the request but only in the terminal mode when the GUI is present. Read data can be logged into the file using Airplug saving facilities. This application has ability to read the log files previously created with this application. We have implemented this with an intention to replicate the experiments in emulation mode using the real data previously gathered from Xbee sensors.

Preliminary results and experimentation scenarios

In this section we will give brief overview of the usage of our testbed and explain possible scenarios of usage for the data collected using it. Testbed is used for environmental data gathering that should be used in the emulation of new protocols that we are developing. Four different scenarios of testbed and data usage are given along with an explanation on the specificity of each scenario and its possible application.

Environmental data gathering

As a part of our work on the distributed data fusion we were evaluating algorithms using generated environmental data. Our idea was to develop and use our own testbed equipped with sensors gathering environmental data. In the Figure 5 we are showing the example of the data gathered by our testbed. More precisely, two wireless Xbee sensor were attached to the one road-side unit (RSU1 in the Figure 4) one being inside of the building and the other one outside. On these graphs (Figure 5) we are showing mean values of the data gathered (RSU has requested data from Xbee sensors each minute) in the night between 6 and 7 February.

Different scenarios for testbed and gathered data usage

Gathered data along with the possibilities of our testbed and different Airplug modes give us four possibilities for the experiments with environmental data. We must stress in here that only two of four possibilities are real experiments (in the sense that they are using all deployed hardware) but the idea is that they all use real data, either previously gathered or collected on the fly from the sensors running at the time of experiment.

Real time experiment with collected data

The idea is to use our testbed hardware with data gathered in the real time. Each RSU is running Airplug-live mode with XBE application while being connected to Xbee sensor(s). Data is gathered in the real time, depending on the parameters set for each XBE application.

This kind of experiment is good for the verification of communication algorithms that depend on the environmental data but in the case when algorithm itself does not depend on the varying of environmental parameters. This is due to the change of the environmental data that is rather slow and cannot be easily observed in an experiment that lasts for a short period of time.

Experiment with emulated environmental data Real hardware is used with RSUs running Airplug-live mode and XBE application. The only difference to the previous In this kind of experiment we can choose the speed of reading from the file. Knowing that we have delays between the readings in the log file we can produce the same kind of an experiment like the one using real data. In this mode we can also choose to speed up readings of the data from log file thus effectively speeding up the experiment for a parameter defined at the start of experiment.

We can use this kind of experiment when we want to track how the algorithms respond to the rapid changes of the environmental parameters. All other parameters (V2I communication, GPS readings, delays between transmissions, etc) remain the same but the change of environmental parameters is rapid so we can better observe its influence on the algorithm. Moreover, using this scenario we can easily setup different environmental data than the ones that we are able to retrieve in real time. For example, we can run the experiment during the warm days using data gathered during winter, thus effectively we will have the experiment run in the winter (according to the environmental data).

Emulation using real data Idea behind this scenario is to use the data gathered in the real time by one or several RSUs, each of them having Xbee sensors and XBE applications running. The data is then used either in one computer running the appropriate emulation scenario with airplug-emu mode or it can be run on multiple computers using airplug-rmt mode.

For example, we can setup emulation scenario using several vehicles moving using map traces and fix several RSUs in the scenario. Some of these RSUs can be the ones that are gathering data in real time and some of them running XBE application with data gathered previously, or we can avoid using XBE applications at all on some of the RSUs (if the testing does not have use of them) and run other Airplug compatible applications that are implementing tested algorithms.

In this kind of scenario we are mixing different kind of applications and sources of data while communication parameters are emulated in the Airplug-emu mode. These kinds of scenarios are good for longer experiments in which we have repetitive change of some parameters (movements of vehicles, communication between RSUs or V2I communication) but we want to see how different environmental data may influence execution in this specific case.

Emulation using gathered data This scenario can also be called pure emulation. In this kind of experiment we do not depend on the hardware that we are using, everything can be executed using only one PC, running the airplug-emu and appropriate emulation scenario or using multiple PCs with aiplug-rmt. This is multipurpose experiment, since we can easily change source of the data, at which rate it is being read and communication parameters. It is best suited for the rapid development of the applications and as the first step after the simulations ran on some of generic simulators (ns2, omnet++, etc).

Conclusion

In this paper we have explained our solution for the usage of wireless sensors and dedicated hardware to build testbed for vehicular ad-hoc networks. While it is the truth that our current solution has only three fix nodes it can be viewed as the proof of concept of our idea of wireless sensors testbed specially suited for the urban areas and vehicular networks. Flexibility of our hardware and software platform permits us to easily deploy this kind of testbed that can contain significantly higher number of nodes (measured in tens or hundreds). This architecture can also be used with different wireless sensors, with the only limitation that they have to use same type of communication module as our dedicated Airbox units. Development and testing of different kinds of algorithms, if not already a part of the Airplug platform, is based on the development of the dedicated applications that handle data provided from other Airplug applications.

We see great potential in the future usage of our testbed architecture. We are already using it for the gathering of environmental data that we plan to use for thorough testing of previously developed algorithms. We are also planning to use this platform to solve different problems in vehicular networks (distributed data fusion using information gathered from sensors, data propagation, correlation of gathered spatial data, etc.). While primarily developed as a tool for vehicular network testing this same platform can be used for the experiments with UAVs (unmanned air vehicles) and for robot networks.

Fig. 1 .

 1 Fig. 1. Testbed with Xbee sensors, road-side units (Airboxes) and software support from Airplug software distribution

Fig. 2 .

 2 Fig. 2. Xbee sensor (with xbee modem visible and enclosed)

Fig. 3 .

 3 Fig. 3. Airbox -platform based on IGEP development boards, Xbee modem with external antenna is shown attached to the dedicated slot (1 euro coin is used for the comparison of sizes)

Fig. 5 .

 5 Fig. 5. Environmental data gathered during 12 hours period (from 19h -07h) in the night between 6th and 7th February using Airplug software RSU unit and Xbee sensor

http://www.digi.com/products/wireless-modems-peripherals/wireless-range-extendersperipherals/xbee-sensors

2 https://www.isee.biz/products/igep-processor-boards

http://www.iotlab.eu/

http://www.digi.com/support/kbase/kbaseresultdetl?id=3215

http://www.hds.utc.fr/airplug/

Acknowledgments

This work was carried out and funded in the framework of the Labex MS2T. It was supported by the French Government, through the program "Investments for the future? managed by the National Agency for Research (Reference ANR-11-IDEX-0004-02)