**4.3. Architecture of low-power transceivers**

Wireless sensor nodes are very limited in terms of computational power and memory. The small receive buffer of low-power transceivers has to be considered when developing a preamble-based MAC protocol. Typical low-power transceivers, like the TI's CC2400 [40] and ATMEL's AT86RF231 [42], are only equipped with a 128 byte RXFIFO. The RXFIFO of the CC2500 [41] transceiver family is even limited to 64 bytes. Therefore, a received frame has to be immediately read from the FIFO in order to avoid buffer overflows caused by consecutive transmissions which would lead to loss of information. This issue can become a major problem for non real-time operating systems such as TinyOS which is only able to handle up to ≈170 packets per second. However, this packet reception rate only applies for small packets with a size of less than approximately 30 bytes. Moreover, there should no other time-consuming tasks be running on the sensor node. Otherwise, the packet reception rate drops down significantly as a result of the non-preemptive task scheduler.

#### 20 Will-be-set-by-IN-TECH 158 Wireless Sensor Networks – Technology and Protocols

## *4.3.1. Performance limitation factor - RXFIFO*

In the following a brief introduction of the packet reception procedure for the CC2420 is given to provide MAC protocol designers useful information regarding the implementation. Upon detection of the Start Frame Delimiter (SFD) field, the chip begins to buffer the received data in its 128 byte RXFIFO [40]. In case the default Auto Cyclic Redundancy Check (AUTOCRC) settings are not changed, the chip replaces the first byte of the Frame Check Sequence (FCS) with a RSSI value estimated over the first 8 symbols after the SFD field. The second FCS byte is replaced by a 7 bit correlation value used for Link Quality Indication (LQI) computation and by a 1 bit field which indicates whether the frame was correctly received. The resulting data frame is shown in Figure 11.

### **Figure 11.** Data Frame in RXFIFO

The main limitation of this strategy is that damaged frames remain in the RXFIFO until they are read. In case of an overflow, the chip is not able to receive data until all correctly received frames are read and the buffer is flushed. Furthermore, the CC2420 does not protect the length field of the physical header. If the field is damaged and indicates, for example, that the stored frame is larger than the default frame size, TinyOS will *immediately* flush the buffer regardless of whether it contains correctly received frames since it does not know when the next correctly received packet starts. This means that if a MAC protocol fails to recognize a busy channel, a possible frame collision may cause correctly received frames to be flushed at the receiver before they are forwarded to the application. Listing 1 describes the reception routine in detail.

```
async event void RXFIFO . readDone ( . . . ) {
       ...
       i f ( rxFrameLength + 1 > m_bytes_left ) {
         flush ( );
       }
       else {
          i f ( ! call FIFO . ge t ( ) && ! call FIFOP . ge t ( ) ) {
            m_bytes_left −= rxFrameLength + 1;
          }
          i f ( rxFrameLength <= MAC_FRAME_SIZE ) {
            // further frame processing
          }
         else {
            flush ( );
          }
       }
       ...
}
```
### **Listing 1.** Frame Length Field Processing

In general, a frame stored in the RXFIFO is read in three steps. The first step involves the interpretation of the first byte, which represents the length field, to detect the end of the frame. The second step includes the processing of the FCF header. During this phase the receiver may generate an acknowledgment when the acknowledgment request bit is set. The last step is needed to determine whether the received frame is correctly received and to signal reception to the upper layer components.

After evaluation of the length field, TinyOS tries to determine whether the received frame has a size larger than the RXFIFO. If this condition is true, the flush() function, which immediately erases the receive buffer, is called. Note that TinyOS uses the variable m\_bytes\_left to store the size of the buffer. This variable is initialized with a value of 128, but is decremented when an overflow occurs. With each frame which is still in the RXFIFO m\_bytes\_left gets decremented until the last incomplete frame. For this frame, the condition rxFrameLength + 1 > m\_bytes\_left is true and the queue is flushed. This action is required to enable reception of new data and reset m\_bytes\_left.

TinyOS checks whether the frame size is smaller than MAC\_FRAME\_SIZE. If the frame size is larger, the received frame is assumed to be corrupted and the RXFIFO is flushed. Thus, frames that were received correctly but have arrived after the corrupted frame will be lost.
