Virginia Tech logo
Instructions


Sponsors

Instructions for Phase 2

Hello Spectrum ShaRC contestants! Phase 2 of the contest will begin at 12:01 a.m. EST (UTC -5) on December 21, 2016. Code submissions are due at 11:59 p.m. EST on February 20, 2017. Details of each team's access times to their assigned nodes on CORNET are available at this Google Spreadsheet: (Note that this is a different link than the one supplied for Phase 1 of the contest.) The schedule currently only lists access times for the first week, but will be amended by the end of next week to include access times for the duration of phase 2.

Hopefully the first phase of the competition served to familiarize you with CRTS. The second phase of the competition is meant to put more emphasis on MAC layer functionality. Specifically, the goal is to achieve high throughput while minimizing the impact of your transmissions on a primary user (PU) network. As such, the scoring will be modified to include a multiplicative factor based on the degradation experienced by the PU network. Score = (Sum of Sharc node throughputs) * [(PU throughput with active Sharc nodes)/(Average PU throughput with no active Sharc nodes)]^2. Squaring the normalized throughput of the PU emphasizes the importance of non-interference with the primary user in determining the scores.

 

Instructions for Phase 1

1. Design of CR

This competition will be using the Cognitive Radio Test System, a framework for test and evaluation of cognitive radio (CR) networks. The focus of the first phase of the competition is on cognitive engines (CE). Each team will design one or two CEs based on the Extensible Cognitive Radio (ECR).

Teams are not responsible for developing an entire CR from the ground up e.g. using softwaredefined radio (SDR) software such as GNU Radio.

The ECR is a particular CR that we have developed to enable flexible development of CEs. Please see the documentation for CRTS and the ECR available in the git repo https://github.com/ericps1/crts . Once getting to the repository via the link, be sure to take a very careful look at the README that comes below the file structure, and crts-manual.pdf that can be found in the repository. The pdf manual should be the document that you will be primarily following in an entire process of working with CRTS. Refer to Tutorials 1 through 3 (Chapters 5 through 7) in design of your own CE.

2. Transmitting Frequencies

Teams must use frequencies for which Virginia Tech has an FCC license. Please see http://cornet.wireless.vt.edu/CORNET_FCC_License.pdf for detailed terms of the license. For quick reference, a table of licensed frequencies is provided at http://cornet.wireless.vt.edu/license.html. Teams should monitor their selected frequencies before transmitting, to ensure that those frequencies are not in use. Also, if transmitting near the edge of the licensed bands, teams must limit the bandwidth of signals transmitted by their radios such that the signal does not extend beyond the licensed frequency range.

3. Scoring Policy

Submissions will include one or two .cpp files defining CEs for the ECR. No other alterations to CRTS or the ECR will be made for a particular team. Teams should provide installation instructions for any libraries that are required by their CEs. Also, teams should be available to provide advice on installation of any required libraries.

Score will be based on the sum data transmitted between the two CRs in a set period of time in a set of interference scenarios. These scenarios will be designed to vary in terms of perceived difficulty/complexity. In general, a scenario will comprise the two CR nodes and one or more nearby interferers which will be transmitting dynamically in terms of time, power level, and / or frequency. Teams will have no control over or exact knowledge of the particular scenarios being used for scoring. Final scoring will be based on statistical results i.e. scenarios will be run multiple times using multiple combinations of nodes. Each team will be evaluated in an identical way.

4. Access to CORNET

All testing will be performed on the CORNET testbed.

Because of the number of teams entered in the challenge, access to CORNET will follow a strict schedule which will be provided to teams individually.

CORNET accounts and schedule information will be provided to each team upon receipt of all required registration documents from that team.

Submissions are due November 18, 2016. Late submissions will be ranked lower than submissions received by the deadline, regardless of their performance. Code that will not compile will be given a score of zero. Code that crashes during testing will be scored based on the data successfully received prior to the crash.

Early submissions will be given preliminary evaluations in the order they are received to make sure the code compiles and runs. Time permitting, feedback will be provided to teams so they can fix any issues in their code.

Invitation to the third and final phase of the challenge, to be held in Blacksburg, VA on April 7, 2017, will be determined based on rankings in the first three phases, for example, a team’s rankings in the three phases are added together so that a team that places first in Phase 1 and second in Phase 2 would have a cumulative score of 6 and would be invited after a team that earned a cumulative score of 3 by scoring second and first in the two phases. We currently plan to invite up to two representatives from each of the top four qualifying teams, and can provide limited travel funds for each of these representatives. It is possible that the number of invited teams could be increased depending on funding available at the time the invitations are issued. Any teams for which Virginia Tech cannot provide travel assistance will be permitted to participate remotely.

4. Cheating

Cheating will result in penalties including demotion in rankings and disqualification.

Cheating includes but is not necessarily limited to: sending data between nodes other than overthe- air via the USRP, using unauthorized frequencies for transmission, or using the network synchronized clocks on the nodes to synchronize control of the CRs.

The synchronization clock issue can be elaborated as follows. The use of the system clock is permitted (and possibly necessary in some situations), but it should be used in a manner that is realistic to a typical wireless scenario. A synchronization over a network must be achieved via an over-the-air signaling. The goal is to avoid situations where the radios rely on the server nodes' synchronized system clock to perform operations that, in a realistic scenario, need to be handled by over the air signaling. Some of the CEs provided with CRTS do not follow this rule, so be very careful if basing your CEs on provided code.

A simple example of a violation of this rule (and indeed where most teams broke this rule), is to perform frequency hopping based on the system clock and an ABSOLUTE time reference. So if you say "every time the system clock rolls over to a new second, change the frequency," the only reason the nodes are synchronized is because they have synchronized system clocks, which is not realistic. What would be a realistic alternative (though not necessarily the only or the best way to do it) is to set up an initial link and send a message which signals "start frequency hopping NOW." Then you can look at the current time and use that RELATIVE timing information to synchronize the frequency hopping of the two nodes.

We provide several questions and answers from the last year’s Spectrum ShaRC as examples, to help understand the synchronization policy in more practical contexts:

Question:

Are the following uses of the system clock on each node (accessed via gettimeofday()) permitted?

1) To scan through the spectrum at the beginning of each run, to measure channel conditions. (each radio changes its tx/rx freq once per second)

2) To switch to certain fixed pairs of frequencies if the radios ever lost contact with each other completely, because of e.g. heavy interference or mismatched tx/rx frequencies.

3) To prevent switching frequencies too rapidly (e.g., more than once per second).

Answer:

1) If you are only sensing, not transmitting/receiving data frames, then there isn't really anything wrong with this. But if you are actually transmitting/receiving data, then it is a frequency hopping scenario that is based on an absolute time reference (already described), which is not allowed.

2) This approach is fine if you do not use an absolute time references. So you could for instance say, "if I haven't received a frame in x seconds, switch to frequency y." This is fine. The problem is if you say, "if I haven't received a frame in x seconds, switch to frequency y at time t," where t is an absolute time reference.

3) Again it comes down to how you use this. What would be acceptable is to: determine an initial time t1 at the start of the transmission period, periodically determine the current time t2 and calculate the time delta td=t2-t1, switch frequencies if td>=ts (where ts is your switching period). What is not okay is to: periodically determine the current time t1, and then compare t1.seconds and t0.seconds (where t0 is the previous time). This second approach is not allowed because it waits for the system clock to roll over to a new “second” (the unit of an absolute time reference) in order to synchronize the nodes. This can be true even if you don't use seconds by the way. Even if you do the same thing every 0.1 seconds, the problem is the same.