Rules of Play
Beacon Format
How to Enter
Misc Rules
Extreme Sensing '07

Extreme Sensing at IPSN 2008

The Skoke Hunt

The Seventh International Conference on Information Processing in Sensor Networks (IPSN '08) will be hosting the second Extreme Sensing competition on April 22-24, 2008. This year's competition is a “skoke hunt”, where a skoke is a mote, cell phone, or PDA that is designed to be easily located by its creators, but hard for anybody else to find. Each team must bring four skokes that will be given to attendees of the conference, who will carry them throughout the conference. All teams must then try to identify as many attendees that have skokes as possible. All skokes must transmit a pre-defined beacon message at least once a minute, but a team can equip its own skokes with any number of sensors to relay information about their own whereabouts, to eavesdrop on opponents' skokes, or to jam their messages. Teams can use at most four detector nodes that can be equipped with any technology to find skokes, but must be completely passive, ie. the detector nodes may not transmit any radio messages or other signals. The team with the most skokes after 36 hours wins!

Rules of Play

Skoke designs: All skokes must have a CC2420 radio and must transmit a beacon message using a pre-defined packet format at full transmission power at least once per minute. The simplest skokes may simply transmit this beacon more frequently. However, teams can also equip their skokes with any number of sensors or other gadgets to collect and relay information about their own whereabouts. For example, a skoke can use an accelerometer to tell its designers whether or not it is moving. At the same time, a skoke must be careful not to transmit so many messages that it is easy for opponents to find. Skokes can be used to crack or jam the detection systems of other skokes. For example, they can log when and where they heard messages from other skokes, or they can try to jam their messages. Skokes can be enclosed in a container, but the entire skoke including sensors and any container must be no larger than 24 cubic inches (irregular shapes will be approximated by length x width x height).

Hiding skokes: At the beginning of the conference, each team must bring four skokes of their own design that they will exchange with other teams. After the exchange, teams have four hours to hide the skokes that they received from their opponents. Thus, each team will hide four skokes that were designed by other teams. A skoke is "hidden" by giving it to a conference attendee that is not affiliated with the competition or any of the teams. This attendee should keep the skoke until a competitor asks for it, or until the end of the competition. Skokes can be concealed in pockets, in bags, etc., but cannot be hidden inside a Faraday cage. The attendee should be told (i) to carry it with them at all times, both inside and outside of the conference (ii) not to give the skoke to another attendee, and (iii) not to leave the conference without returning the skoke. The attendee should also be told not to answer questions about the skoke without first receiving a special ticket from the questioner (explained later). Attendees have the right to refuse a skoke. During the four hour hiding period, teams are allowed to backward engineer their opponents' skokes. For example, teams can shake them or expose them to light to see if this triggers a radio message. However, teams cannot open any enclosing containers to see what sensors are inside. They also cannot modify, damage, or reset the skokes.

Finding skokes: Teams find a skoke by retrieving it from the attendee that is carrying it. Teams can find any skokes, whether designed by themselves or another team. However, teams cannot find the four skokes that they themselves hid. Each team will receive fifteen tickets, and must use these tickets every time they choose to ask an attendee for a skoke. Every time a team finds five skokes, they can receive five more tickets. When a team runs out of tickets, they cannot find any more skokes. To choose which attendees to ask, teams can use at most four detector nodes that help to locate skokes. A detector node can be as simple as a mote that measures the RSSI of the beacon messages, like a Geiger counter, but they can also be more complex: teams can create their detector nodes out of any mote, PDA, cell phone, or laptop class devices and can equip them with any number of sensors or other gadgets. Detector nodes can be connected to each other by physical wires, can be set up in calibrated locations, etc. However, the detector system as a whole must be completely passive, ie. it cannot transmit anything such as radio messages, ultrasound, infrared, etc. Additionally, the teams themselves must also be passive, ie. they cannot probe or prod or shake a backpack to see if a skoke is inside. Nor can teams probe or prod (or shake!) conference attendees by asking them questions about skokes. Teams can only actively ask an attendee about a skoke after giving that attendee one of their tickets. Once a skoke is found, it must be disabled within fifteen minutes. Thus, a skoke can be used to crack or jam the detection systems of other skokes while in the possession of an attendee, but it cannot be used to augment the detector system after it is recovered. Teams should be careful not to let their hunting disturb technical presentations, and should not ask attendees for skokes while they are listening to a talk.

Thinking Strategically

In the most basic system, the skokes would send beacon messages every 5-10 seconds, and detector nodes would report the radio signal strength of the beacon packets using LEDs. Teams could use this to find the skokes by walking around with it to sense skokes, much the way radioactive material can be found using a Geiger counter. This would be a fairly effective baseline entry, and the TinyOS code for this system is available here. Other systems might record the times at which each skoke first came into or went out of radio range. The competition rules also allow for many different strategies, not only for improving your own system but also for competing with other systems. For example:

Stealthy sensing: Your skokes can use sensors to learn about their environment, such as whether they are in somebody's pocket or in a suitcase, and they can transmit this information to you. This can help narrow down the attendees that might have your skokes. The transmission of frequent information, however, increases the chances that opposing teams will be able to locate your skokes first! Therefore, stealth should be a key priority.

Using skokes as detectors: You can use at most four detector nodes to locate skokes. However, you can also use your skokes to augment your detectors by, for example, recording and reporting when they see other beacon messages. This way, you may find out that a particular skoke is staying in the same hotel or went to dinner at the same restaurant as your skoke. You can even use your skokes to triangulate the positions of the other skokes. Once you recover your skoke, however, they must be disabled. Thus, a trade-off is at hand: the longer you take to collect your skokes once you locate them, the more information they can gather for you. At the same time, you increase the chances that another team will find them!

Using other teams' skokes: At the beginning of the conpetition, you will have one skoke from each of the other teams, and four hours to backward engineer them. If you find that the other teams' skokes are transmitting a certain type of information, you can use information from their detection system to help you find the skokes. From this perspective, you should try to make it difficult to backward engineer. For example, delay the transmission of your data, transmit aggregate information, and use different radio channels to try to throw off your opponents.

Interfering with other teams' skokes: You can also interfere with other teams' skokes. For example, if you detect that they are sensing vibration, you could hide their skoke in a location where motion belies little information. You could alternatively use your skokes to jam all of the non-beacon messages from other skokes, putting you at equal footing with the skoke designers. From this perspective, you should design your own system to be robust to jamming or other destructive attacks.

Beacon Format

All skokes must send a beacon message at full transmission power at least once a minute. The beacon message should use the TinyOS-2.x message format and be sent to the broadcast address with AM type 0x9F and a 28 byte data payload. The first byte of the payload should be the team ID, and the second byte of the payload should be a skoke ID. For each team, the skoke Ids should go from 0-3 since each team will have four skokes. All other bytes can have any value. In order to avoid specifying all radio parameters (of which there are many), a proper beacon message can be defined as a message that can be decoded by the TOSBase defined in this code when programed on a telos or micaz mote. Basically, this means that it must be sent with a CC2420 radio on the default Tinyos-2.x radio channel (26) with default parameters such as modulation phase, CRC algorithm, etc.

How to Enter

To enter, a team must send email to Kamin Whitehouse, the competition chair, containing the team's name, institutional affiliation, the players' names, and a rough description of the system to be used. The team should expect a response with a team ID to be used in the beacon messages on game day. Entries must be received on or before April 10, 2007. Email should be sent to:

All teams and the competition chair will meet immediately after the first session of the first day of the conference. At this time, all teams will exchange skokes, and the four hour hiding period will begin. Teams will also receive 15 initial tickets with which to ask conference attendees for skokes, and should verify that they know how to turn off all different types of skokes (in case they find them). The competition will end at the beginning of the last day of the conference.

At the end of the conference, all teams may be asked to submit the code that they used during the competition. This code may be given to teams entering the competition in subsequent years, allowing new entries to build upon technologies of previous years, and forcing winning teams to always improve on their previous year's submission. Before game day, all teams must also send a one-slide PowerPoint animation explaining roughly how their system works. This slide may be used when presenting the winning entries to the conference at the end of the competition.

All rules of this contest are subject to change or clarification at any time, and are likely to change as the need for clarifications arises. In the case of any dispute, decisions about scoring and eligibility will be made by judges on Game Day and will be final. Contestants who would like to do something that might be the cause of dispute should ask for clarification of the rules and/or pre-approval of the hardware and techniques before the April 10 deadline.

Miscellaneous Rules

Teams cannot collude in any part of the contest, eg. by revealing the operation or location of skokes, or by sharing tickets.

Skokes should be designed to survive 48 hours from the beginning of the competition. They should not be fragile and should not require any special handling instructions. They must be simple to disable, eg. a battery that can be removed or an on/off switch.

Skokes are permitted to sense any aspect of their environment that is not already designed to locate devices. For example, skokes can listen for and report on 802.11 ESSIDs or cell towers, but cannot use GPS.

Teams should be respectful of the privacy of the skoke carrier. For example, long-duration audio recordings of private conversations are forbidden.

Skokes can only use the CC2420 radio to communicate information to the detector systems. They cannot send information over 802.11, cellular radios, etc.