We begin by explaining the details of our simulation setup, including the precise way in which energy is measured, transmission interference is handled and transmission success is measured. We start with an analysis of the hardware we are simulating.
5.1.1
Radio Hardware Model
Energy use, timing characteristics, bit rate, and radio signal interaction are the most impor- tant parameters in testing a MAC protocol in software. We review energy use in detail, and then note other elements. We use published information about typical WSN motes to form the basis of our energy use model for radio and CPU [10, 11, 13, 1, 2].
Low complexity radio hardware such as the Chipcon 1000 [10] supports straight- forward encoding schemes such as Manchester encoding. Manchester encoding uses two sym- bols per bit for redundancy and error detection. The baud rate is 38400 which makes the bit rate 19200 since overhead is 2 symbols per bit. The energy ratio for transmit, receive (listen) and sleep for the cc1000 at 915 MHz ranges from 27000:10000:1 to 10000:10000:1 (depending on the transmission power which can range from 5 dBm to -20 dBm). This energy ratio is common in WSN motes with the cc1000 or similar radio chip. We use a ratio of 20000:10000:1 range that approximates prior testing [45, 33] and is near the maximum transmission power. Interestingly, when testing is done on hardware, energy is generally estimated using such a model. The reason is that using physical energy monitors on every mote in a test network is generally not practical (motes do not come with hardware for measuring energy usage).
High complexity radio hardware such as the Chipcon 2420 [11] supports much higher data rates and complex encoding such as O-QPSK (offset - quadrature phase shift keying). The transmit, receive, sleep ratio is closer to 20000:20000:1 for this chip and encoding scheme. Note the receive power per second is twice as high per second and about equal to typical transmit power. However, the bit rate is ten times higher (250 kbps vs. 19.2 kbps) so the node can support a much lower duty cycle and ultimately conserve more energy while main- taining throughput and low latency. SMAC and RSMAC are intended for simpler hardware represented by the cc1000 that is available on the smallest WSN nodes such as Mica 2 and Mica 2 Dot [3], so we use the cc1000 specs in our current testing model.
To simulate radio interaction, we use an aggressive model in which a small amount of signal overlap destroys a packet. This is justified because intelligent jamming is about detecting and exploiting MAC timing, hence in using an aggressive interference model we’re giving the jammer every advantage and focusing on confounding the timing of the jammer rather than relying on physical characteristics (such as jammer distance) to partially miti- gate jamming. This also means that bad MAC layer timing (slight packet collisions due to uncorrected clock drift) will also fail with a very high rate in our simulation.
To simulate timing, we give each simulated node an independent software clock and simulate random clock drift based on physical measurements. For the MICA2, we have a maximum drift of 40µs and drift tends to be consistent over the short term according to research done by Maroti et al. Hence, we simulate MICA2 drift rates by having each node maintain a drift rate ranging from −20µs to +20µs plus or minus random jitter of 0 to 2 µs as measured by Maroti et al [30]. In summary, we use tx, rx, radio-sleep, cpu, cpu-sleep ratio of 20000:10000:1:8500:10, a bit rate of 19200 bits per second, and the interference and clock drift models described above.
5.1.2
SMAC and RSMAC Packet Comparison
The logical SYNC packet size for SMAC is 9 bytes. The packet fields and size in bits are: length (8), type (8), source (16), sync-node (16), timestamp (8) and CRC (16) [44]. For RSMAC, we add a 16 bit PRNG seed for a 12 byte packet. However, we must add a preamble to this to get the physical packet. The preamble on the cc1000 must be set to one of four settling states that listen for at least 23, 34, 55 or 98 chips. That means preambles must be at least 2, 5, 7 or 13 bytes long depending on transmission strength and distance. In practice, preambles are longer than the minimum for reliable transmission. We use a minimal preamble of 3 bytes for SMAC and RSMAC. A minimal preamble gives SMAC a slight advantage in overhead comparisons (a larger preamble would make the percentage increase in RSMAC packet size less significant). The final packet sizes are 12 bytes and 14 bytes after the preamble is added (13 bytes for CTRL packets, described in more detail below).
5.1.3
Packet Encryption
TinySec is a component of TinyOS that has been expanded over the years to include different encryption options [23, 22]. It defaults to Skipjack encryption which uses an 80 bit key and has very low energy overhead but relatively high memory overhead. Shepherd explains Tiny Encryption Algorithm (TEA) in detail which is optimized for 32 bit CPUs and operate on 64 bit blocks [37]. The complexity of the algorithm depends on the number of cycles in which permutation and substitution are performed. The recommended number of cycles is 32, but Shepherd shows that 16 cycles is realistically enough. Lee et al present a review of WSN packet encryption including software algorithms, hardware AES support in the cc2420, and sensor optimized encryption using Skipjack and XXTEA, a corrected form of TEA [27].
We have a difficult choice between XXTEA and Skipjack. Skipjack uses much less energy per byte, but requires 12 times the RAM and 3 times the program memory on the Mica
2. That is, TinySec’s Skipjack uses 10 KB (almost 10%) of the program memory on a Mica 2 and 0.6 KB (15%) of the 4 KB of RAM. XXTEA is also more efficient when encrypting larger packets which may be useful if we encrypt data as well as headers (which we probably want to do), while Skipjack scales linearly with additional data. Although the memory requirements are high, we choose Skipjack since the energy savings vs XXTEA are between 4:1 and 2:1 (packet size ranging from 16 to 128 bytes). It takes approximately 220 µs to encode or decode an 8 byte block with Skipjack on a Mica 2 mote, however this can be done concurrently with transmission and reception. For example, for transmission, encryption can occur while the preamble is being sent with one 8 byte block taking approximately half a byte’s worth of transmission time to encrypt, it is not difficult to stay ahead of the transmission speed). Finally ,we note that energy cost of hardware AES encryption on the Mica Z’s cc2420 radio controller is so low as to be negligible [27]. It’s about 1% of software encryption time/energy or less). Clearly hardware encryption is far more desirable when possible.
Since efficient block encryption ciphers are intended to work on 64 bit blocks, we have to address the question of packet size and what part of the packet to encrypt. SMAC SYNC packets are 9 bytes and the length field cannot be encrypted (it would be rendered useless to the physical layer), so we encrypt the last 8 bytes, including the CRC. Ideally, we would not encrypt the CRC because it might disqualify the packet before the costly decryption algorithm is run, however the cost of transmitting even 1 extra byte exceeds the cost of decrypting. For the RSMAC packet, we can encrypt from type to RNG seed leaving the CRC unencrypted. If we want DATA encryption using a 64 bit block cipher, the payload must conform to 8 byte increments. Using the energy model established, we will wait with the CPU active for 4 ticks to simulate the time taken for encryption. This will cause the appropriate amount of energy to be recorded. Encryption changes the send and receive
ratios for 64 encrypted bits in each MAC header from 20000:10000 to about 20531:10531 representing a relatively small increase in energy usage (2.5 and 5 percent respectively).
The CTRL packet fields for SMAC and RSMAC are identical at 10 bytes logical and 13 bytes physical (plus data bytes in a DATA packet). The packet fields and size in bits are: length (8), type (8), destination (16), group (8), source (16), duration (8), CRC (16) [44]. The group field designates the receiver group for broadcast packets and duration is used to specify the total transmission length (so that an RTS or CTS contains some hint of the length of the expected DATA transmission allowing temporary sleep). Since there is little sensitive information here, we may only wish to encrypt the data. If we did encrypt the header starting at the type field, the 64 bit block cipher would have two bytes left to encrypt which would encompass the CRC for non-DATA packets and the first two bytes of data otherwise. If DATA payload encryption was desired, it would have to begin at the third byte and the data length would have to be 8 byte increments plus 0, 1 or 2 bytes (precisely 2 would leave the CRC unencrypted which would optimal for long DATA packets).
5.1.4
Reducing Packet Header Size
Packet headers could be made more efficient by packing some fields to the shortest necessary length instead of following byte boundaries. This requires a small amount of CPU overhead for unpacking packed fields, but considering the cost of using the radio it should be well worth it. For SMAC packets, we cannot pack without decreasing the length below 64 bits. The RSMAC packet remains long enough to pack if we encrypt the CRC field. The type field encodes 8 types in RSMAC which fits comfortably in 4 bits. Node ID fields may be reduced in software to fit the maximum expected network size. A network size of 216 would be extraordinary for a WSN, however 28 could be limiting. We could use 11 bits to represent 211 nodes. The relative timestamp is transmitted as the number of slots remaining in the
senders SYNC period. Based on the packet size, packet arrival time and known slot size, the receiver can calculate the clock state of the sender. The field only needs to be large enough to represent the maximum number of slots. The original implementation of SMAC used 15 SYNC slots (a large amount needed only for very dense node configurations since SYNC traffic is periodic and based on a fixed frequency) which would require only 4 bits to represent. Since packet size must fall on byte boundaries, we can provide 6 bits which is more than enough. In conclusion, an efficient packet size for RSMAC might be 12 bytes. Since we are implementing a 64 bit block cipher, we do not test with the reduced packet size. However, we note that the Skipjack block cipher is ideal for constrained WSN hardware and RSMAC can use a reduced packet size even in this case, while SMAC would require padding the packet to RSMAC size or a cipher that supports arbitrary sized data (which are less CPU and memory efficient and less secure).
5.1.5
Jammers
We use constant jamming as a baseline [43] and cluster based jamming [26] to determine the efficacy of RSMAC in achieving its primary goal. We will use the deceptive jammer of Xu et al to test robustness of global synchronization in the face of captured, rebroadcast SYNC packets. Repeated packets may be a significant threat to an unprotected synchronization algorithm.