Hello Spectrum-ShaRC Challenge participants! These are the instructions for Phase 1 of the challenge:
1. Design of CR
This challenge will be using the Cognitive Radio Test System (CRTS), a framework for test and evaluation of cognitive radio (CR) networks. The focus of the first phase of the challenge is to get familiar with CRTS. CRTS provides a flexible framework for over the air test and evaluation of cognitive radio (CR). On the next phases, the focus will be 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 software-defined 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 in the git repo https://github.com/cornet3d/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.
The deliverable for the first phase will be the octave/matlab log files that are generated when running Tutorial 1 found in the crts-manual.pdf.
Successful completion of Tutorial 1 and submission of generated log files is required to qualify for phase 2 of the Spectrum-ShaRC challenge.
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 the octave/matlab files generated and the configuration file used (basic_two_node_network.cfg) when running Tutorial 1. You are allowed to make changes to the configuration file as you see fit in order to increase throughput between radio nodes. No other alterations to CRTS or the ECR will be made for a particular team. Score will be based on the sum data transmitted between the two radio nodes in a set period of time. For the first phase, teams will have a choice of which pair of nodes to use as indicated in the settings of the basic_two_node_network.cfg file to be submitted.
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, 2017. 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 in April, 2017, will be determined based on rankings in the first 2 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.
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 over-the-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 are providing the following questions and answers from previous Spectrum ShaRC Challenges as examples to help understand the synchronization policy in more practical contexts:
Question 1: Are the following uses of the system clock on each node (accessed via gettimeofday()) permitted 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)?
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.
Question 2: Are the following uses of the system clock on each node (accessed via gettimeofday()) permitted 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?
Answer 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.
Question 3: Are the following uses of the system clock on each node (accessed via gettimeofday()) permitted to: prevent switching frequencies too rapidly (e.g., more than once per second)?
Answer 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.