EWSN Dependability Competition 2018 - Call for Competitors
[The deadline for the abstract submission has been extended until October 23, 2017!]
Following the success of the 2016 and 2017 editions, the International Conference on Embedded Wireless Systems and Networks (EWSN) will host also this year a competition to compare the performance of WSN and IoT communication protocols in harsh RF environments.
Background. Over the last decade, a large number of low-power wireless communication protocols has been proposed by both academia and industry. Although the presence of RF interference is known to often negatively affect their performance (leading to an increase in packet loss, latency, and energy consumption), the performance of low-power wireless protocols designed by different authors has rarely been benchmarked under the same congested RF environments. The EWSN dependability competition aims to fill this gap and to quantitatively compare the performance of different WSN/IoT communication protocols in environments rich of radio interference.
Following the success of the 2016 and 2017 editions, the International Conference on Embedded Wireless Systems and Networks (EWSN) will host also this year a competition to compare the performance of WSN and IoT communication protocols in harsh RF environments.
Background. Over the last decade, a large number of low-power wireless communication protocols has been proposed by both academia and industry. Although the presence of RF interference is known to often negatively affect their performance (leading to an increase in packet loss, latency, and energy consumption), the performance of low-power wireless protocols designed by different authors has rarely been benchmarked under the same congested RF environments. The EWSN dependability competition aims to fill this gap and to quantitatively compare the performance of different WSN/IoT communication protocols in environments rich of radio interference.
Format
This year's dependability competition will have a new format compared to the past two editions, the most prominent changes being that it will take place remotely over a longer time window, and that it will involve the reporting of multiple events from several nodes.
Remote preparation and evaluation. Interested participants should first submit an abstract describing their approach by the competition entry deadline. Accepted contestants will obtain the credentials to remotely access the competition infrastructure and enter the preparation phase. During the latter, contestants will have the possibility to test their protocols and receive real-time feedback, in order to be able to optimize the solution for the competition scenario. Contestants will be able to upload a single binary ihex file to all nodes in the network and receive via e-mail their serial output, as well as the evaluation results. After the preparation phase, each team needs to provide one binary that will be used for the final evaluation.
Poster session. A poster session dedicated to the dependability competition will take place during the first main conference day (February 15, 2018). All competing teams must present their solution in the poster session and will have the possibility to engage in lively discussions with the other conference attendees.
Awards and winners' presentations. The winners of the competition will be awarded during a dedicated plenary session on the first main conference day (February 15, 2018). After receiving the award, the top three teams must hold a 10-minutes presentation about their solution, followed by a short discussion session.
Remote preparation and evaluation. Interested participants should first submit an abstract describing their approach by the competition entry deadline. Accepted contestants will obtain the credentials to remotely access the competition infrastructure and enter the preparation phase. During the latter, contestants will have the possibility to test their protocols and receive real-time feedback, in order to be able to optimize the solution for the competition scenario. Contestants will be able to upload a single binary ihex file to all nodes in the network and receive via e-mail their serial output, as well as the evaluation results. After the preparation phase, each team needs to provide one binary that will be used for the final evaluation.
Poster session. A poster session dedicated to the dependability competition will take place during the first main conference day (February 15, 2018). All competing teams must present their solution in the poster session and will have the possibility to engage in lively discussions with the other conference attendees.
Awards and winners' presentations. The winners of the competition will be awarded during a dedicated plenary session on the first main conference day (February 15, 2018). After receiving the award, the top three teams must hold a 10-minutes presentation about their solution, followed by a short discussion session.
Eligibility
Both academia and industry submissions are encouraged. All wireless communication protocols used in low-power wireless sensor networks are welcome, and there is no restriction on the operating system used to program the sensor nodes.
The competition will take place if at least 5 teams respond to this preliminary call for competitors. Depending on the nature and number of submissions, multiple categories may be defined. The winning teams in each category will receive cash awards and present their approach at EWSN in a 10-minutes plenary talk.
The competition will take place if at least 5 teams respond to this preliminary call for competitors. Depending on the nature and number of submissions, multiple categories may be defined. The winning teams in each category will receive cash awards and present their approach at EWSN in a 10-minutes plenary talk.
Competition Scenario and Evaluation Procedure
Hardware.
Contestants will be asked to deploy their software on off-the-shelf Maxfor MTM-5000-MSP sensor nodes (TelosB replicas operating in the 2.4 GHz ISM band) and to dependably communicate information despite the surrounding radio interference. This hardware choice allows contestants to prepare by testing their protocols on most public WSN testbeds.
Scenario. The competition scenario emulates the operation of a sensor and actuator network monitoring discrete events in an industrial setting where several co-existing wireless devices are crowding the RF spectrum. For example, several sensors may be scattered around an industrial plant to detect a fire or a leakage. As soon as it detects a fire, a sensor sends an alarm message to one or more actuators that are part of a water spray deluge fire suppression system. Similarly, if a sensor detects leakage in one unit of the plant, it immediately sends an alarm message to the correponding actuator in order to close the valve.
The sensor nodes in the wireless sensor and actuator network can hence act as sensor (source), forwarder, or actuator (destination). In the competition scenario the occurrence of events is passed to the source nodes via the GPIO pins by the D-Cube's Raspberry Pi3 observers. The source nodes need to communicate through the network the information received on their GPIO pins: each GPIO is matched with a destination or set of destinations, and its status (high or low) has to be promptly communicated to the intended recipient(s) accordingly. Each destination node then needs to trigger the output of its GPIO pins according to a given logic function containing the information received from the source nodes. For example, a destination may need to OR the information received from the source nodes, emulating a scenario in which as soon as at least one fire sensor detects an alarm, the fire suppression system should be active, whereas it should be deactivated as soon as all sensors communicate that the hazard has ceased. The role of each node and the matching between GPIOs and destination(s) will be known beforehand.
The above figure illustrates and exemplifies the competition scenario. Source1 needs to communicate the status of GPIO1 and GPIO2 to Destination1, whereas any change in GPIO8 has to be sent to both Destination1 and Destination2. Similarly, Source2 needs to communicate the status of GPIO1 and GPIO2 to Destination2, whereas any change in GPIO8 has to be sent to both Destination1 and Destination2. Both destinations OR the information obtained by the source nodes accordingly on GPIO8. To ensure compatibility with the testbed setup, additional information and code examples will be provided at a later stage.
Evaluation procedure. Solutions will be evaluated based on (i) the reliability of transmissions, i.e., on the number of GPIO changes correctly reported to each destination, (ii) on the end-to-end latency in communicating each GPIO change to each destination, and (iii) on the energy-efficiency of the solution. The latter will be measured at each source, forwarder, and destination node using D-Cube's. Organizers may also limit the energy-budget of the nodes emulating battery depletion, such that nodes are turned off once their battery capacity has been exceeded.
Scenario. The competition scenario emulates the operation of a sensor and actuator network monitoring discrete events in an industrial setting where several co-existing wireless devices are crowding the RF spectrum. For example, several sensors may be scattered around an industrial plant to detect a fire or a leakage. As soon as it detects a fire, a sensor sends an alarm message to one or more actuators that are part of a water spray deluge fire suppression system. Similarly, if a sensor detects leakage in one unit of the plant, it immediately sends an alarm message to the correponding actuator in order to close the valve.
The sensor nodes in the wireless sensor and actuator network can hence act as sensor (source), forwarder, or actuator (destination). In the competition scenario the occurrence of events is passed to the source nodes via the GPIO pins by the D-Cube's Raspberry Pi3 observers. The source nodes need to communicate through the network the information received on their GPIO pins: each GPIO is matched with a destination or set of destinations, and its status (high or low) has to be promptly communicated to the intended recipient(s) accordingly. Each destination node then needs to trigger the output of its GPIO pins according to a given logic function containing the information received from the source nodes. For example, a destination may need to OR the information received from the source nodes, emulating a scenario in which as soon as at least one fire sensor detects an alarm, the fire suppression system should be active, whereas it should be deactivated as soon as all sensors communicate that the hazard has ceased. The role of each node and the matching between GPIOs and destination(s) will be known beforehand.
The above figure illustrates and exemplifies the competition scenario. Source1 needs to communicate the status of GPIO1 and GPIO2 to Destination1, whereas any change in GPIO8 has to be sent to both Destination1 and Destination2. Similarly, Source2 needs to communicate the status of GPIO1 and GPIO2 to Destination2, whereas any change in GPIO8 has to be sent to both Destination1 and Destination2. Both destinations OR the information obtained by the source nodes accordingly on GPIO8. To ensure compatibility with the testbed setup, additional information and code examples will be provided at a later stage.
Evaluation procedure. Solutions will be evaluated based on (i) the reliability of transmissions, i.e., on the number of GPIO changes correctly reported to each destination, (ii) on the end-to-end latency in communicating each GPIO change to each destination, and (iii) on the energy-efficiency of the solution. The latter will be measured at each source, forwarder, and destination node using D-Cube's. Organizers may also limit the energy-budget of the nodes emulating battery depletion, such that nodes are turned off once their battery capacity has been exceeded.
Submission Instructions
Interested participants should first submit an abstract describing their approach by the competition entry deadline.
Formatting requirements. Abstracts should prominently include the name of the authors as well as their affiliation and contact information. Abstracts must be written in English and can have a maximum length of 2 pages including figures, tables, and references. Pages must have 8.5" x 11" (letter) two-column format, using 10-point type on 11-point leading, with a maximum text block of 7" wide x 9" deep with an inter-column spacing of .25". Authors may use the LaTeX templates provided here.
Abstract submission. To submit your competition entry, please email your abstract to cboano(at)tugraz.at with the following subject line: "EWSN 2018 Competition - Submission".
Camera-ready. The abstracts will be used to pre-select the participants to the competition. Accepted contestants will have the chance to edit their abstract and submit a camera-ready version by the end of the competition's preparation phase. Accepted abstracts will appear in the ACM Digital Library, unless authors explicitly mark their submission as confidential.
Formatting requirements. Abstracts should prominently include the name of the authors as well as their affiliation and contact information. Abstracts must be written in English and can have a maximum length of 2 pages including figures, tables, and references. Pages must have 8.5" x 11" (letter) two-column format, using 10-point type on 11-point leading, with a maximum text block of 7" wide x 9" deep with an inter-column spacing of .25". Authors may use the LaTeX templates provided here.
Abstract submission. To submit your competition entry, please email your abstract to cboano(at)tugraz.at with the following subject line: "EWSN 2018 Competition - Submission".
Camera-ready. The abstracts will be used to pre-select the participants to the competition. Accepted contestants will have the chance to edit their abstract and submit a camera-ready version by the end of the competition's preparation phase. Accepted abstracts will appear in the ACM Digital Library, unless authors explicitly mark their submission as confidential.
Important Dates
Competition entry deadline (Abtract submission): October 23, 2017 [Extended!]
Notification of acceptance: October 31, 2017
Camera-ready abstract submission: January 7, 2018
Competition's preparation phase (remote): From November 27, 2017 until January 29, 2018
Submission of final software: January 29, 2018
Competition's evaluation phase (remote): From January 29 until February 9, 2018
Competition awards and poster session: February 15, 2018
Notification of acceptance: October 31, 2017
Camera-ready abstract submission: January 7, 2018
Competition's preparation phase (remote): From November 27, 2017 until January 29, 2018
Submission of final software: January 29, 2018
Competition's evaluation phase (remote): From January 29 until February 9, 2018
Competition awards and poster session: February 15, 2018
Organization
Carlo Alberto Boano (Graz University of Technology, Austria)
Markus Schuß (Graz University of Technology, Austria)
Markus Schuß (Graz University of Technology, Austria)
Supporters
FAQ – Frequently Asked Questions
-
Where will the competition take place?
This year's edition of the dependability competition will take place remotely, using an infrastructure and a Website similar to the one employed in 2017. The sensor nodes will be deployed at Graz University of Technology on the facilities of the Institute for Technical Informatics. -
How many team members need to register to the competition?
At least one participant of each accepted team needs to register to the EWSN conference and participate in the dedicated poster session on February 14. Credentials to access the competition infrastructure will be sent only after the registration has successfully been completed. -
How many nodes should be expected and at which density?
The exact location of the sensor nodes will not be disclosed, in order to avoid solutions that are specifically engineered in advance for the evaluation scenario. Contestants will be provided with an upper bound on the number of nodes and their density in the next weeks, so that they can correctly dimension their solution. In any case, not more than 60 wireless sensor nodes deployed over several floors in an area of approximately 1440 m2 can be expected. -
Can a submission be kept confidential?
Yes, there is the possibility to keep the submitted abstract confidential (i.e., no publication in the ACM digital library). The results of the preparation phase and the final ranking after the evaluation phase will be public. -
Software upload: is a single version of the firmware necessary?
Contestants will be asked to provide a single binary ihex for all nodes. The binary will be uploaded to all nodes in the network using a common MSP430 Bootstrap Loader. -
How does a node knows its identity?
The ID of each node can be read from the on-board external flash. In this case, the ID is an unsigned short (16 bits) number, and an example program in Contiki on how to read it from flash is available here. Alternatively, also the 48-bit unique ID chip (DS2411) can be used. -
Which frequencies are allowed?
The use of frequencies below 2400 and above 2483.5 MHz are strictly forbidden. There is no limitation about the usage of frequencies between 2400 and 2483.5 MHz (hence, all IEEE 802.15.4 channels from 11 to 26 can be employed). Please note that, as the TI CC2420 radio allows to send and receive packets also outside the 2.4 GHz band (roughly between 2230 MHz and 2730 MHz), the frequency usage will be monitored during the evaluation phase and any detected violation will lead to a disqualification. -
Is there any limitation in the number of packets sent?
Destination nodes will only need to reproduce on the GPIO pins the same pattern observed by the source node(s). There is no constraint on the number of packets sent in the network. -
How will interference be generated?
RF interference will be generated in the competition area in a repeatable fashion to ensure fairness across multiple experiments. First, JamLab will be running on multiple co-located wireless sensor nodes acting as interferers across the whole 2.4 GHz ISM band. We will further make use of Raspberry Pi 3 nodes to artificially generate interference using the embedded BCM43438 chip. The reproduced interference will resemble the patterns of common Wi-Fi appliances and will vary over time. Interference will be active throughout the whole experiment and contestants cannot assume that some IEEE 802.15.4 channel(s) will be constantly interference-free. -
Can additional interference be present in the area?
During the evaluation phase, which will take place over night, no particular sources of interference are expected. We will nevertheless monitor the radio interference in the surroundings and, in case some particular disturbance is detected, the experiment will be repeated.
We look forward to your contribution to EWSN 2018 in Madrid, Spain!
Organized by:
GOLD Sponsors: 
SILVER Sponsors: 
