(Last Mod: 04 November 2010 18:12:51 )
The goal of this project is to design and implement a radio suitable for use in an upcoming exercise (May 2009) to demonstrate the effective jam-resistance of a BBC-based communications system in which the radio will be flown in a UAV (unmanned aerial vehicle) and will transmit packets back-and-forth to a ground station while a military jamming transmitter engages it. The performance specs are quite flexible and I am willing to adjust them shamelessly to match what can actually be achieved within the necessary time frame.
Here are the original target performance goals:
The choice of frequency band is to deconflict with other communications that will/may be occurring at the same time. The other possible bands are the 915 MHz, the 1.8 GHz band, and the 2.4 GHz band. The 915 MHz band is commonly used for aircraft control and telemetry by the aircraft that will be carrying the radio and the 1.8 and 2.4 GHz bands are used by many of the aircraft payloads that may be sharing space with the radio on any given mission. While I definitely want to avoid the 915 MHz band, I am willing to shift to the other two bands if that turns out to be advantageous.
The data rate was chosen simply because it is known, anecdotally, that a 9600 baud data link is sufficient to control at least some of the UAVs that some of the teams are using. However, the choice is quite arbitrary and this target goal will be the first to be relaxed if necessary.
The level of jam resistance is also arbitrary, but much less so. A level of 30 dB means that the jammer is being required to use 1000 times the average power of the legitimate sender (all else being equal) to disrupt communications. Not only is this a nice number to be able to throw out when presenting results, but it also appears to be in the vicinity of the limit of what present spread spectrum systems are able to attain, at least not without very high receiver complexities (Fontana 2000).
The peak power goal is driven by the opposition's jamming capabilities. They have two 50W jammers with high gain antennas. We would like to put out enough power to force them to operate at a significant portion of their power capability, if at all possible. However, this is really not too important. They will attenuate their signal as needed to map out the threshold of where our system begins to fail. All that is important is the ratio of their effective isotropic radiated power and ours. None-the-less, the resulting report will require less hand waving about the differences between what the demonstrator could do and what a practical real-world implementation can achieve if we can operate at reasonably high peak powers.
The next step in spec'ing out the system is to see what the above goals translate to as far as required performance. To achieve a processing gain of 30 dB, we need to force the attacker to put out 1000 times as many marks as the legitimate sender. Assuming that only one of the legitimate stations transmits at a time, this requires a packet expansion factor of 2,000 for standard, vanilla BBC encoding. If 2/3-multimark BBC is used, this rises to a factor of 6,000. If 1/1-interstitial checksum bits are added, this requirement increases to 12,000. Assuming we are using 1000-bit packets, this means that the packet length would be 12 million bits long. Even with the tolerance of BBC to oscillator mismatch, this would probably require oscillator accuracies on the order of 1ppm, although 10ppm may work, particularly if the oscillators are from the same lot (which is frequently the case when they are purchased together).
To send data at a rate of 960 Bytes/sec with an expansion factor of 12,000 requires a packet bit rate of 92 Mb/s, which in turn requires a signal bandwidth of 184 MHz for ASK/OOK. This definitely makes it a very wideband system at 400 MHz and may make the system infeasible to design and implement in the necessary time frame. At 2.4 GHz, on the other hand, this is less than 10% of the center frequency making it a reasonably narrowband signal.
Let's reverse the discussion and consider the achievable data rate using the USRP hardware. This hardware has a data bottleneck of about 6 MSa/sec due to the USB link. However, those are quadrature samples and so the achievable signal bandwidth is also 6 MHz, or 3 Mbps using ASK/OOK. With an expansion of 12,000 this then translates to a data bit rate of 250 bits per second. A person typing at a keyboard at 50 words per minute is producing about 40 bps. Similarly, the GPS almanac and ephemeris data is transmitted at 50 bps. So, for a demonstration system, this is not entirely unreasonable. However, it is unlikely that the USRP has adequate oscillator matching to achieve this.
The following table summarizes these results for various configurations.
| FIXED DATA RATE | 960 bytes/sec | FIXED BANDWIDTH | 6 MHz | |
Like most development projects, what we would like the software to do, what we are likely to be able to get it to do in the time available, and what we absolutely need it to be able to do are three very different things. As long as the last is a subset of the first two, we are in good shape. Toward that end, we will first describe the basic information we are trying to obtain from the exercise along with a discussion of which information is nice to have, which is important to have, and which is crucial to have. We will then describe the software that we would like to have to capture this information in a nice, convenient manner. Finally, we will discuss the minimum set of features needed to get only the crucial information and then an enhancement plan to incrementally add features as time permits.
The basic information we are trying to obtain from the use of this demonstrator is how jam resistant this technology actually is in the real world. It should be noted that the quality of the information obtained at this stage is going to be somewhat marginal - there's a reason it is being called a "demonstrator" and not a "test bed". That's because another key objective is simply to demonstrate the basic technology to several parties that are, or might be persuaded to become, interested in pursuing further development. In order to get as much utility out of the data as possible, it would be highly desirable to collect not only absolute data on the performance of BBC encoding against the jammer, but also similar data on the performance of traditional spread spectrum against the same jammer while running on the same hardware. This will permit stronger conclusions to be drawn about the relative performance of BBC and traditional techniques.
The basic approach to collecting the data is very straightforward. After mounting the radio in the UAV, both it and the ground station are set to broadcast a signal as well as record what it receives. At the appropriate point in the UAV's flight profile the jammer engages the UAV and/or the ground station. The needed data is simply that required to correlate packet transfer reliability with jammer average power output level. There are practically limitless schemes that could be used to collect the needed data, both real-time and through post-mission analysis. Since the jammer is a cooperating party in these exercises, the simplest way is probably for the jammer to log the information necessary to determine the relevant effective output power at any sufficiently fine-grained point in the profile for use in post-mission analysis. Similarly, the UAVs, base station, and each of the radios themselves make similar records of their relevant data.
In order to collect as much breadth of information as possible from a limited amount of mission time, it is not feasible to have the jammer and radios operate with a static set of parameters. Instead, the jammer should be ramping its output power up and down as well as changing the jamming strategy in use. Similarly, the radios should be altering their configurations in order map against those variables.
Next, it must be determined what data needs to be logged by each entity in order to perform the necessary post-mission analysis. The simplest of these is for the base station since most of it's configuration is static. All that needs to be recorded here is the geographical location of the base station, including any changes that are made and when they are made, and the physical configuration of the radio, such as type of antenna, daughter board, power amplifier selection, etc. These logs can be hand written, if necessary or convenient. Also if convenient, the base station logs can track the physical configuration of the airborne radio, since this information only changed (with intent, anyway) between flights. The jammer needs to maintain logs of its physical configuration, which again are probably sufficiently static so as to allow manual logging, and also output power level, jamming strategy in use, jamming parameters for that strategy, and antenna direction angles. For it's part, the UAV needs to log its location in space and, ideally, its orientation angles. Between the jammer logs and the UAV logs, it should be possible to estimate the power level received at the radio antennas, particularly if sensor calibration periods are included in the flight profiles. The radios need to log their configuration parameters, both for the transmitter and for the receiver. The actual logging should be very straightforward and can be accomplished by inserting the necessary information into the message traffic and then simply maintaining a record of all messages sent and received. Needless to say, all of the dynamic logs must be time-stamped in such a way as to allow adequate synchronization of their contents during post-mission analysis; part of this time stamping must involve synchronization of the system clocks either through pre-mission synchronization or by embedding sentinel signals that all logging systems can see directly or infer indirectly during post-mission analysis.
In theory, the dynamic logs maintained by the radios can be generated artificially since the radio profiles will be known a priori. This will be particularly important in the event of the loss of a UAV, however, the issue of whether the artificial profile can be adequately synchronized to the missing log data is problematic. However, since the base station will have a record of all messages successfully received, it will have a partial copy of the missing logbook which should aid in the effort. Similarly, the UAV's log data, at least as far as geographical location based on GPS data, is down-linked in real time and recorded for a variety of purposes, hence that data should be available even in the event of an aircraft casualty.
With this overview and understanding of the high level requirements, we can now begin discussing the features of the radio software itself that are needed and/or desired. On the absolute minimalist side of the house, one radio could be a transmit only and the other could be a receive only. A single configuration would be used for a given mission and the transmitting radio would simply prepare messages containing a time-stamp and sequence number and then transmit them at a regular interval. The receiver would then simply record the messages it receives and nothing more.
An even more basic approach would be for the receiver to not even attempt to decode the packet or even generate a bit stream, but instead to simply record the baseband or IF data directly for later processing. This method has the strong advantage that the it is then possible to play with most receiver parameters in post-processing in order to create additional virtual missions and extract significantly more data. The biggest disadvantage is the large data payload the receiver must generate and store. At a sampling rate of 16MSaps using 8 bit samples for both I and Q data, a thirty minute flight would produce a total 55GB of data at a rate of 32MB/s. As obscene as this sounds, it is actually a quite feasible option. Present USB FLASH drives are available in 64GB capacities that can write at (or acceptably near) this speed. A quick search indicates that they are, indeed, pricey at a cost of several hundred dollars each. However, only three or fewer would be needed. Another alternative is to use a solid state hard drive - suitable 64GB models are available at a cost under two hundred dollars each. Assuming that all of the data from all of the radios was captured this way and that three radios were used, each mission would produce approximately 165GB of data. After each mission this data could be transferred to large spinning drives which are now readily available in 1TB+ capacities in the one hundred dollar range. Using one such drive per radio, both to speed turn-around time and for logistical considerations since the radios will not all be at the same location, each set of drives could store 20 to 25 missions worth of data. This will almost certainly be greater than the total number of missions available to us. Hence, for a cost of around $1000, three radios could be configured to enable capturing all baseband data coming from the USRP during the entire exercise.
Even if this approach is not adopted - and there are strong advantages for being able to do real-time message processing, if nothing else than from a demonstration perspective - the radios should still be configured to operate in this primitive mode on at least some flights or, less primitively, to have it be one of several configurations used in each mission's profile. If the radio periodically records its baseband waveforms then, independent of the logs from the jammer, it can estimate what the jamming power at the receiver actually is, at least compared to the actual signal. This utility alone significantly increases the utility and reliability of the test results.
The next step up in system capability would be for each radio to be able to change its configuration on the fly under the control of a mission profile. Ideally, the profile should be prepared and placed in a text file that the radio reads and that tells it what each configuration is and when to change configurations. The radio then prepares, logs, and transmits messages using the present transmitter configuration; it also receives and logs any messages it recovers using the present receiver configuration. The first version of this could be nothing more complex than the existing scripting capabilities of the BBC Research Engine. In fact, this is probably the best starting point and all that must be done is for the a few new commands to be added.
Perhaps the ultimate step, at this stage, would be to have a real-time interface that need be nothing more than a console window in which a live chat session can be carried on by two parties. For this exercise, the airborne unit could act as a chat relay between two ground stations. Not only would this make for an interesting and touchy-feely demo, but it would also demonstrate key features about the ability of a BBC-based wireless network to operate in an uncoordinated fashion and while no MAC protocol.
Fast Universal Hash Functions: (downloaded 29 Jan 09)
Analog Devices fast RSSI detector: http://www.analog.com/static/imported-files/data_sheets/AD8318.pdf
http://www.discovercircuits.com/A/a-rf.htm
http://www.microsemi.com/micnotes/APT9801.pdf
http://www.ramayes.com/Data%20Files/Ophir%20RF/5300796.pdf
http://www.henryradio.com/amp_specs/ss_specs.htm
http://www.drft.com/datashts/P250-300-350-15%200.a.pdf
http://www.readyheli.com/Western_Robotics_Hercules_5amp_5_AMP_Battery_Elimi_p/wrl-hbechc.htm
http://www.innovativepp.com/index.html