Clone the Simulator virtual RF testbed and start hacking today!
Click here and we’ll be in touch with submission instructions!
To summarize the competition’s format, competitors are tasked with transmitting data from one radio node to another within a congested or hostile channel. Competitors control both ends of the link, and may use any physical layer of their liking to transmit and deliver the data. Competitors earn points based on how many sequential data packets they deliver. Radio links must be reliable, and as such any dropped, duplicate, or missing packets submitted to the scoring engine will adversely affect scoring.
Competitors will be able to participate in several scrimmages ahead of a final. Scrimmages are for gathering data and debugging, and have no bearing on the competition’s outcome. The final is what determines scoring, and may be comprised of several matches to exercise radio performance under different conditions.
The competition will take place in Fall 2020, with details to be announced at a later date.
Each match is comprised of one competitor team playing against a simulated environment. Two instances of the competitor’s radio submission will be created (collectively reffered to as Competitor Transceivers). One is designated the “transmitter” (Competitor TX) and the other the “receiver” (Competitor RX), however the same Docker image is used for each. This naming convention refers to the direction in which scoring traffic flows, and despite their labels, both competitor radio instances may transmit.
Environmental components that are instantiated are a Channel Simulator instance, a Scoring Instance (which is also the traffic source and sink), and one or several Incumbent Radio applications that also occupy the spectrum. Optional Channel Condition containers create other types of environmental effects that Competitor Transceivers must contend with.
Matches will last between 30 seconds and 3 minutes in duration, where traffic is sourced to Competitor TX and is eligible for scoring. Prior to each match there will be a 30-second setup period, where the Channel Simulator and Incumbent Radio applications are live, but no scoring traffic will be sourced from the Scoring Instance. Competitors may use this time to measure the spectrum, establish links between their Competitor Transceivers, and perform channel sounding. At the end of each match, the Channel Simulator will be disabled, allowing no additional traffic to be passed between the Competitor Transceivers. A 15-second cool-down period follows before the infrastructure is torn down and the next match begins.
Since reliability is an essential attribute of a useful wireless protocol, the scoring algorithm has been designed with this in mind. In summary, the score a competitor receives within a match is equal to the highest sequence number of consecutive packets delivered, starting from the first packet.
Packets generated by the scoring instance will be comprised of a header plus pseudorandom data. In order to be scored, packets must be submitted to the Scoring Instance by Competitor RX bit-for-bit, exactly as they were delivered to Competitor TX by the Scoring Instance. Packets within a match may be of uniform or varying size, though for consistency and fairness all competitors will be given identical packet size demands within each set of matches.
Here are some examples for a hypothetical load of 100 packets: - Competitor Transceivers deliver packets 1 through 100. The competitor’s score is 100. - Competitor Transceivers deliver packets 1 through 33, misses packet 34, and delivers packets 35 through 100. The competitor’s score is 33. - Competitor Transceivers deliver 0 packets. The competitor’s score is 0. - Competitor Transceivers deliver packets 1 through 100, but drops the last octet from packet 3. The competitor’s score is 2.
How to Play
Radio Resiliency Competition takes place on virtual infrastructure. Simulation lowers the barrier to entry by reducing cost, and increases the rate of iteration for competitors and organizers alike. It also allows competitors to locally test with an exact replica of the software that will run the Scrimmage and Final matches.
Competition infrastructure is implemented in a microservice architecture that uses
docker-compose to orchestrate the containers that comprise it. A diagram and description of each microservice follows.
The Channel Simulator microservice simulates the RF spectrum. It runs a GNU Radio flowgraph that takes in IQ ZeroMQ streams from any number of sources, muxes them together, and then emits a single IQ ZeroMQ stream representing the combined spectrum.
Any number of channel profiles or conditions may be simulated. This includes but is not limited to varying the effective link budget between the transmitter and receiver nodes, multipath fading, and dynamic channel conditions.
Competitor Transceivers (Competitor TX / Competitor RX)
The Competitor Transciever microservice container represents the competitor’s radio platform. During each match, two instances will be created – one serves as the “transmitter” (Competitor TX), and the other serves as the “receiver” (Competitor RX). This nomenclature only designates the flow of scoring traffic within a match; both competitor radio nodes are capable of transmitting.
Each Competitor Transceiver instance receives the spectrum from the Channel Simulator via an IQ ZeroMQ stream. Both instances can transmit via separate IQ ZeroMQ streams that source IQ to the Channel Simulator. Additionally, Competitor Transceivers can connect to the Scoring Instance via ZeroMQ. The Scoring Instance will serve scoring traffic only to Competitor TX, and will only score data packets submitted from Competitor RX.
The RRC competition infrastructure comes with a working competitor radio implementation! Competitors are free to submit this basic modem if they like, though they are encouraged to build on top of it to be competitive. While GNU Radio is used throughout the rest of the infrastructure, competitors are welcome to use any signal processing framework of their choosing as long as they are able to adhere to I/O conventions.
Incumbent Radio Applications
Incumbent Radio applications are implemented as microservices that transmit IQ within the RF spectrum. Competitors have no control over these! Incumbent Radios may take the form of other benign radio systems, or they may be hostile and act adversarially. RRC organizers will add more incumbent radio reference applications over the duration of the competition.
The Scoring Instance is the microservice responsible for generating scoring traffic. At the start of the match, the Scoring Instance will begin sending packets over ZeroMQ to Competitor TX. The Scoring Instance will also listen for packets originating from Competitor RX over ZeroMQ. Packet scoring will stop precisely at the expiration of match duration.
Competitors submit their entries by pushing their latest Docker image to a GitLab container registry. RRC organizers will provide a repository and path when you register.