Q: 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 (more than once per second).
A: 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. 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.
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 isn't 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.
Here are comments on the uses of the system clock mentioned in the question:
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 this is basically just the frequency hopping scenario already described, which is problematic as explained.
2) This approach is fine if you do not use 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 t2.seconds (where t2 is the previous time). This second approach is the one described earlier; waiting for the system clock to roll over to a new second in order to effectively synchronize the nodes. This can be true even if you don't use seconds by the way. You could do the same thing every 0.1 seconds and the problem is the same.
A practical way of describing the policy is: if your radios perform any operations which require time synchronization, you must establish said synchronization by over the air signaling. A good general rule of thumb would be: when using the system clock, you should look at full precision time differences. If you're truncating the time, e.g. only looking at the seconds, then you're running the risk of relying on the synchronized system clocks.
Also, in response to the reference to this approach being used in the provided code in CE_Two_Channel_DSA_PU.cpp and the interferers, This appears to have been confusing/misleading to some teams. But these radios aren't intended to be cognitive radios like we've asked the teams to design. The interferers do just that, provide a source of interference to test the CRs’ ability to adapt for the sake of their own performance. The CE_Two_Channel_DSA_PU.cpp, as described in the documentation, is meant to act as a primary user (hence PU), so that we can measure the impact that the CRs have on a PU link (in many cases the main concern of CR design is to avoid negative effects to a PU network). In either case we don't care about the need for the PU radios to synchronize with one another. CE_Two_Channel_DSA_PU.cpp is actually a good example of an unapproved use of knowledge that the clocks are synchronized across nodes. Also, for future phases of the challenge, please ask questions if you are unsure about whether or not you are using the clocks in an appropriate way.
Q. In the first round, do we have to compete with other teams (i.e simultaneously) or just our CEs are running on two nodes and you just place interference/PU users to interfere two nodes' transmission?
A. No, only your radios and interfering radios will be running at the same time.
Q. If there are primary users what is the bandwidth of a primary user? Do primary users also use OFDM to transmit? Do we know any additional information at all about the primary users (frequency of transmission, waveform, etc.)?
A. We are not concerned with primary users in this first round. We've decided to make the situation as open-ended as possible so we aren't providing any specific details on the interference. In general you should expect us to be running a variety of tests i.e. some where the interference is changing relatively quickly and others where it changes much more slowly. In terms of the waveform it might be any of the waveforms supported by the CRTS_interferer and/or the ECR (OFDM, GMSK, RRC, CW, and random noise).
Q. Do we need to protect primary users as well when we transmit in the first round? How do you penalize interference to primary users and how does it get reflected to the score? I.e., do you penalize if we can not distinguish primary users from noise and interfere with them? (i.e. when our optimal target is maximizing our throughput)
A. For this round we're not concerned with primary users. The score is based solely on the amount of data you get across the link in the presence of unknown interference. Most likely the future rounds will consider the impact to a primary user link, so it wouldn't hurt to consider how this might affect your CE design.
Q. Do we have separate frequency bands for transmitter and receiver (i.e 10MHz for node 1 and another 10Mhz for node 2)?
A. No, we've specified one 10 MHz band (760-770 MHz) which you can use however you want
Q. What is the maximum gain we can use for transmission?
A. You can use any gain that the USRP can support. You can check the specs for the USRP on a given node by running $ uhd_usrp_probe
Q. What exactly is the problem statement for this challenge?
A. The initial competition involves transmitting packets of data over a radio channel that has some impairments due to noise and / or interference. The goal is to adapt transmission parameters to achieve the maximum number of error-free packets per second for a given number of packets or time. There is no requirement to assemble the packets into a file. That is, missed packets do not have to be retransmitted.
Q. How do teams access the CORNET testbed?
A. A single CORNET account is created for each team in the challenge. One of the supervisors for each team has received an email from firstname.lastname@example.org with the account information. This account can be shared among all members of the team and can be used to remotely access CORNET according to this schedule: http://trac.cornet.wireless.vt.edu/trac/wiki/CORNET/Reservations.
Please see http://trac.cornet.wireless.vt.edu/trac/wiki/CORNET/HowToUseCORNET for information on different ways to access the CORNET testbed.
Q. Where to safely store data on CORNET?
A. Please use your personal folder for storing any data. Your user folder is named after your team's login. It is located under /users and is accessible from any CORNET node. Please safeguard and save your data frequently and before your 8-hour schedule expires. We recommend that you back up your data on your own computers as well as on CORNET. The CORNET admin is not backing up user data.
Q. Is there a limit on the number of students per team from an institution?
A. Yes, the most students you can have is 10.
Q. Is there a limit on the number of teams per institution?
A. No, there is not.
Q: Can one faculty member advise more than one team?
Q. Is it possible to have students from different universities together in the same team?
A. Yes, but each student should have his/her university listed beside their name.
Q. Is it possible to partner with an institution in the United States and make one single team?
A. Yes, it is.
Q. Does the faculty advisor have to be an instructor at the institution from where the team is originating? Can there be more than one faculty advisor?
A. Advisors would typically be faculty but if the institution has staff who work with students in similar roles, they can be advisors.
Q. Are there any constraints in the year in which the students are enrolled? Can they be freshmen? or last year senior? or super senior/graduate?
A. There are no constraints. We will have special recognition and possibly a prize to the highest-performing team among those that are made up entirely of undergraduates.
Q. Can you add and remove members of your team after we submit the entry form?
A. Yes, you can amend your entry forms to add members or indicate that members have left the team by filling out and submitting another form, however there are some stipulations. If a student stops participating voluntarily or is no longer qualified (e.g., no longer enrolled or graduates during the challenge period) he/she will still count as part of the total number of 10. The ten-student limit is intended to be high enough to allow for some students to discontinue participation.
Q. The only thing due on October 15 is the registration form, is that correct?
A. Yes, the code is not due until November 15.