Background
Several people have asked us about the availability of the network traces we used in our MONET paper, A Trace-based Evaluation of Adaptive Error Correction for a Wireless Local Area Network, so we are making them available here.Error Trace Collection
To characterize error environments, we monitored data transfers between two identical DECpc 425SL laptops (25 MHz 80486) running NetBSD 1.1. For different tests, we placed the PCs in different environments or added competing radiation sources. Our laptops used PCMCIA WaveLAN interfaces operating in the 902-928 MHz frequency band. Note that these were "original WaveLAN" cards, which predated 802.11 and used a different MAC.
Sample Error Trace Excerpt
@2738775 {352 349} [40 2 4 1] 151:
lost 152 153
@2757194 {352 30} [34 40 10 1] 154: 156 160 163 320 324 327 411 415 418
@2780328 {-1 7} [34 40 6 0] alien
In general, each post-processed trace event contains a timestamp (expressed as microseconds from initiation of trace collection, though not actually that precise), the transmitted and received packet lengths (expressed as a count of 32-bit words), signal information from the RF modem (signal level during reception (related to the receiver's auto-gain-control level), ``silence level'' (signal level just after packet reception), signal quality, and selected receive antenna), a packet sequence number, and a list of corrupted (inverted) bits. In this example, packet 151 was missing 3 out of 352 32-bit words, but was otherwise undamaged; packets 152 and 153 were lost; packet 154 was severely truncated and nine bits of the remainder were corrupted; after packet 154 a 7-word packet of unrecognizable contents was received.
A small number of trace records (28, or 0.5%, in the "walls" trace, fewer in the other traces) contain a flipped-bit list of "-1". These packets failed CRC, but had zero flipped bits in the UDP packet body. Thus one or more bits were flipped somewhere in the IP or Ethernet envelopes. While we might have been able to reconstruct the IP header in many cases (the challenge would have been the packet id field), we did not pursue this given the small number of packets in this category.
It has been pointed out to us that the timestamps only approximately monotonically increase. This is probably due to a heuristic used by the NetBSD 1.1 PC hardware clock driver to disambiguate an ambiguity in the interrupt information provided by the timer chip. Given the strength of the Hadamard-Walsh code words used to encode the packet sequence numbers in the packet bodies, we believe it is reasonable to trust the sequence number more than the timestamp (which we do not use for anything beyond a sanity check).
Traces provided
To explore the range of error severity due to interference, we investigated 30-second traces in four different situations. In the "office" scenario, the communicating machines were separated by a distance of approximately 5 feet, and there were no known interference sources.
In the "walking" scenario, the communicating machines were separated by roughly 3 feet. A cordless telephone base station was a few inches from the receiver's modem unit (as might be the case on an office desk), and the telephone handset moved repeatedly at walking speed back and forth from roughly a foot away from the base station to a point approximately 30 feet away (where the handset complained about signal loss). The cordless phone used was a Radio Shack ET-909, which uses spread spectrum modulation in the same band as our WaveLAN units.
The "adjacent" case was the same as the "walking" case except that the handset was fixed adjacent to the receiver's modem unit and was power-cycled at a rate of approximately twice per second (in an attempt to provide an error environment with more challenging variability than the "walking" case).
In the "table" case, two communicating units were approximately three feet apart, with the telephone handset and base station about an inch and about five inches from the receiver's modem unit. In these traces we observe packet loss rates of up to 30% and packet truncation rates of up to 23%. We notice that the bit error rate varies by more than an order of magnitude, and that this variation is not straightforwardly linked to the other error rates.
While attenuation can be reduced by provisioning a network more densely with base stations, mobile users may still encounter occasional coverage "holes." Therefore, we investigated the effects of attenuation to see how they differed from those of active interference sources. The fifth, "walls," trace represents a path with significant attenuation: we separated two units by placing them in two rooms across a hallway. The direct path was approximately 17 feet long and passed through two thick concrete block walls, a metal display case, and some classroom furniture. As compared to the interference environments, attenuation has an almost insignificant truncation rate, but has significant packet corruption.
Context
To see the "big picture" of where these traces led me, you may consult my Ph.D. dissertation, available from my research page.
Traces have been made of the IEEE 802.11 PHY by a research group at TU Berlin, see their web site for more information.
