Models for delay estimation

In this section, several models are proposed for estimating sending and receiving delays with respect to input payload sizes. Sending delays include fire-to-send (F2S), send command and transmission delays whilst receiving delays include reception and receive delays. In each delay, the coefficients of source and base station are obtained and the maximum values shown in Table 5.1 are used.

A) Decomposition of sending delay

There are three components in the sending delay and they are described as follows:

1. Fire-to-send (F2S) delay: This represents the interval required after a timer is fired. The timer is used to schedule the transmission. After it is fired, the source sets its parameters such as id and transmission power into the payload. The send() command is called after all parameters are set. The F2S delay is expressed in Equation (5.6). The payload size is represented by p.

122

2. Send command delay: This is the duration from the send() command being called until

the SFD (Start of Frame Delimiter) is transmitted at the MAC (Medium Access Control) layer. Equation (5.7) shows the send command delay.

Send command delay = 11.367 + 0.043p (5.7)

3. Transmission delay: This is the duration from the SFD transmission until the

sendDone() event is signaled by the application layer. Equation (5.8) represents the transmission delay.

Transmission delay = 0.552 + 0.033p (5.8)

According to Equation (5.8), one additional byte transmission requires 0.033ms. The CC2420 radio provides the data rate of 250kbps, or it takes approximately 0.032ms for sending a byte of message. In total 0.585ms is required for a 1-byte data payload. By taking the CC2420 header of 11 bytes into account, a 12-byte packet takes 0.585ms, or approximately a 65% data rate (12*8/0.585 = 164kbps) is achieved.

B) Decomposition of receiving delay

There are two components in the receiving delay and they are described as follows:

1. Reception delay: It represents the interval from the SFD being received by the radio unit until the CC2420Transmit.sendDone() event is signaled by the radio. The reception delay is expressed in Equation (5.9).

Reception delay = 1.521 + 0.076p (5.9)

By comparing Equation (5.9) to (5.8), the reception delay is greater than transmission delay. As the Tmote Invent and Sky employ the CC2420 radio, they should be equal. An additional duration is required for the radio before signaling the CC2420Transmit.sendDone() event.

2. Receive delay: This represents the interval required for delivering the message to

application layer. The receive delay is expressed in Equation (5.10).

Receive delay = 0.22 (5.10)

C) Propagation delay

According to the results, the maximum two-way propagation is two ticks which is much less than 1ms. Most of the outputs are either 0 or 1 tick. The propagation delay is therefore very small compared to the other delays. A 1ms is reserved for the two-way propagation delay in this research.

D) Guard time length determination

A schedule-based protocol requires an acceptable clock accuracy. Clock drift is an important aspect which should be considered. A guard time aims to avoid an overlapping between slots while their durations are dependent upon the sources’ local clocks. An additional duration is required for accommodating the clock drift impacts.

The Tmote platform employs a MSP430 F1611 microcontroller from Texas Instruments. The MSP430’s clock system consists of three clock signals generated by ACLK (Auxiliary Clock), MCLK (Master Clock) and SMCLK (Sub-Main Clock). The microcontroller provides low power modes where some or all of the modules are disabled for power conservation. The LPM3 (Low Power Mode 3) is used in the Tmote platform and ACLK is the only operating clock in the LPM3. The ACLK uses a 32-KHz watch crystal to generate oscillations and it has clock drift of 20ppm (part per million). The clock drift should not be neglected as sensors may be running for a long period and the drift may accumulate into seconds. The clock drift is crucial in determining guard length.

Figure 5.8 demonstrates a scenario where slot overlapping occurs.

Figure 5.8: Overlapping of slots

The gs and d respectively denote guard length and the remaining part of slot. There may be a case where the clock of Node n runs more quickly than the other clocks. The node misunderstands that its slot has arrived and the packet is transmitted too early. Hence, an overlap has occurred.

124

According to Figure 5.8, the total slot length is equal to (gs + d) ms. Prior to the packet of Node n being transmitted, a total of (n-1) slots have been processed. The g is required to be greater than or equal to 20ppm. The duration taken by (n-1) slots is (n - 1) times (gs + d). The drift caused by such slots is shown in Equation (5.11).

Drift = (n -1)(gs + d)(20 * 10-6) (5.11)

Equation (5.12) demonstrates the required guard length.

gs≥ (n -1)(gs + d)(20 * 10-6) (5.12)

According to Equation (5.12), the term gs (20 x 10 -6) is significantly less than gs. The above equation can be rearranged and displayed in Equation (5.13).

gs≥ (n -1)(d)(20 * 10-6) (5.13)

The required guard length is therefore dependent upon the length of the remaining part of the slot (d) and number of allocated slots (n). According to Equation (5.13), a 1-ms gap can accommodate the product of (n -1)(d) up to 50,000. Assuming that there are 100 allocated slots, the reserved 1- ms duration is capable of accommodating the slot length of 500ms which is significantly greater than the duration required for transmitting and receiving the maximum packet size limited by the CC2420 radio.