ResearchBib Share Your Research, Maximize Your Social Impacts
Sign for Notice Everyday Sign up >> Login

EWSN 2020 - International Conference on Embedded Wireless Systems and Networks

Date2020-02-17 - 2020-02-19


VenueLyon, France France



Topics/Call fo Papers

Over the last decade, a large number of low-power wireless communication protocols has been proposed by both academia and industry. Their performance, however, has rarely been benchmarked under the exact same settings. Furthermore, little is known about the dependability of low-power wireless protocols in the presence of RF interference, which is known to significantly increase packet loss, end-to-end latencies, and energy consumption. Since 2016, the EWSN dependability competition aims to fill this gap by quantitatively comparing the dependability of state-of-the-art low-power wireless protocols under the same settings and in harsh RF environments.
Scenario and Categories
This year’s competition scenario will emulate the operation of a wireless sensor network where several co-existing Wi-Fi devices are crowding the RF spectrum. In particular, the messages generated by several source nodes need to be collected at a single destination (sink) in a reliable, timely, and energy-efficient way despite the presence of RF interference.
Data transmissions. Each source node is connected via I2C to an EEPROM that contains messages (of variable length) to be transmitted to a given destination. The benchmarking infrastructure will generate messages in the EEPROM of each source node asynchronously and signal their availability by toggling a pre-defined GPIO pin. These messages should be forwarded to the intended destination as efficiently as possible within a maximum per-message delay bound ∂, i.e., the end-to-end delay of every message from its generation to its reception at the sink should be lower than ∂. The latter is fixed and applies to all messages exchanged during a test run. Contestants can expect the values of ∂ to be set in the order of hundreds of milliseconds / a few seconds. As soon as the destination node receives a new message, it needs to write the corresponding data to the EEPROM and raise a pre-defined GPIO pin accordingly. The benchmarking infrastructure will then verify the correctness of the information written in the EEPROM and use the GPIO rising edge time-stamp to compute the end-to-end latency. If a message has been received with an end-to-end delay greater than ∂, it is considered to be lost.
Testbed infrastructure. As in the previous editions, the D-Cube testbed infrastructure will be used to benchmark the competing solutions. D-Cube allows to unobtrusively profile in hardware the energy consumption of each node in the network and to accurately measure the reliability and end-to-end latency of individual transmissions. Furthermore, thanks to its binary patching capabilities, D-Cube allows to benchmark the competing solutions using different input parameters, such as the address of source and destination nodes and the length of the packets being transmitted. These input parameters will not change during a test run and will be directly injected by D-Cube into the firmware under test by applying patches to the provided ihex binary, as explained in this document. This allows to make sure that results are not setup-specific. An example of how to integrate the necessary code for the binary patching will be provided beforehand.
Type of nodes. In contrast to the previous editions, this year’s competition will make use of nRF52840-DK wireless nodes deployed in an office building over several floors in an area of approximately 1440 m2. The nRF52840-DK board supports multiple technologies and radio modes (e.g., IEEE 802.15.4, BLE 1Mbps, BLE 2Mbps, etc.): contestants are free to use any of the supported technologies and modes without any limitation.
RF interference. Competing solutions will be tested both in the absence and in the presence of RF interference. The latter will be generated across the whole 2.4 GHz ISM band in a repeatable fashion by running JamLab-NG across the testbed infrastructure using D-Cube's observer nodes. The generated RF interference will resemble the patterns of common Wi-Fi appliances and will vary over time. The contestants cannot assume that some of the frequencies in the ISM band will be constantly interference-free.
Categories. Based on this scenario, two different categories are planned for this year’s edition:
Single-hop data collection. In this category, up to 20 source nodes generate raw sensor values of different length, which should be communicated to the same destination. The latter is located in proximity of all source nodes and can be reached directly, i.e., in normal conditions, the sink can be reached by every source node within a single hop.
Multi-hop data collection. In this category, up to 60 source nodes generate raw sensor values of different length, which should be communicated to the same destination. The latter may be located several hops away from a given source node, even when making use of the coded PHY layers available on the nRF52.
Test runs using different configurations (i.e., a different set of input parameters) will be performed for each category. The raw sensor values will be generated either periodically or aperiodically during a test run. The period (or the lower/upper bound for aperiodic traffic), the delay bound ∂, the length of the packets to be transmitted, as well as the identity of the source and destination nodes will be injected to the firmware under test using D-Cube’s binary pathing features, and will apply for the whole duration of a test run. Additional information can be found in the “Frequently Asked Questions” section. More details will be provided as part of the logistics information before the beginning of the preparation phase.
Binary firmware. For each category, contestants are asked to provide a single binary in hex format (Intel) for all nodes. This ihex binary will be uploaded to all nodes in the network using the onboard JLink-OB debug adapter. The provided binary firmware should support different input parameters as described previously.

Last modified: 2019-10-25 22:50:43