Overhearing Supported BuckshotDV

In the previous section (4.2) BuckshotDV was introduced, which focuses on reducing the size of the messages transmitted by Buckshot Routing. While a reduction of the number of bytes that need to be transmitted is of course a reduction of energy consumption and network load, its gain is only limited for small networks. This is due to the fact that only a few node identities can be removed. But even in larger networks, the number of messages will presumably be the most important factor, as each routing message may also be fitted with a MAC header. Even if it is not, some of the current hardware used in sensor networks needs quite long preambles to synchronize sender and receiver, thus increasing bandwidth consumption drastically. For this reason, Overhearing Supported BuckshotDV (OSBRDV) focuses on possibilities to reduce the number of transmissions while keeping messages nearly as small as in BuckshotDV.

The basic idea behind OSBRDV is to delay messages on nodes that are not on the original route, and refrain from sending them if the node on the original route forwarded the message. This can be determined by overhearing the next-but-one hop node (as listed in the message, i.e. the direct successor of this node) sending the message in question to a node further along the path. The problem that arises with this new approach is that nodes now need to know whether or not they are on the original path.

This leads to the need of transmitting not only the identity of the next-but-one hop inside a data message, but also including the direct next hop. Thus the message size is increased again, by the size of one identity. But as the size of an identity is assumed to be small in wireless sensor networks, it can be safely assumed that reducing the number of messages only by a fraction will already be enough to even out the additional identity transmitted.

In an optimal case, if all links on the path and those to all neighboring nodes are bidirectional, only nodes that are on the path would transmit the message. But this case is very unlikely as the experiments described in section 2 have shown. Normally, there will be unidirectional links around which messages have to be routed by OSBRDV.

4.3.1 Message Types

OSBRDV uses the same three message types BuckshotDV uses: Route Request, Route Reply and DATA. The Route Request message format stays exactly the same, only the other two are changed. However, the handling of a RREQ message is slightly different:

Instead of storing only one node identity upon reception of a RREQ or RREP, two are stored in the routing table now (table 4.4).

Table 4.4: Routing Tables in OSBRDV

Destination Next Hop Next but one Hop Hop Count

D A B 3

Figure 4.14 shows the message formats for RREP (l) and DATA messages (r). The RREP now contains four node identities in the variable area: The next-but-one hop is used to determine whether a node is a candidate for forwarding or whether it has to discard the message right away. If the value found in the field ”next hop” equals the identity of the node that is working on the message, the message is retransmitted without delay, otherwise it is delayed for a certain time, depending on parameters like MAC protocol, per-hop-delay and similar. The current and previous hop identities are needed to build the reversed route on this node and on the next one, just like in BuckshotDV.

Type = RREP = 2 Source Seq. Num.

Destination Source Hop Count next-but-one Hop

Previous Hop Current Hop

Next Hop Route Reply

Type = DATA = 3 Source Seq. Num.

Destination Source next-but-one Hop

Next Hop Current Hop

DATA Data

Figure 4.14: RREP and DATA Message Format in OSBRDV

The DATA message only contains three varying fields, the next-but-one hop, the next hop and the current hop. The first two fields are used to determine if the node that has received the message is a forwarding candidate or even on the direct path.

Depending on this, the forwarding is delayed or not. The current hop is used upon message reception to determine if the message has already been entered into the list of deferred messages during its previous hop.

S A B D

C 1

1

2 3

3 6

Figure 4.15: Transmission of a RREP or DATA Message in OSBRDV

Figure 4.15 shows an example transmission of a RREP or Data message in OSBRDV.

In the first step, the source (S) transmits a message for the destination (D) with next hop A and next-but-one hop B. This message is received by nodes A and C. Node A is the intended next hop and forwards the message in step 2, after the current hop, next hop and next-but-one hop are adjusted. Node C, on the other hand, is not on the direct path. It stores the message in its list of deferred messages. When node B receives the message, it acts exactly like node A and forwards the message after the necessary adjustments.

Now there are two different scenarios: Either node C receives the message from node B in step 3, or it does not. If node C receives the message, it searches in its list of deferred messages for the source and sequence number. In the stored message, the next-but-one hop is denoted as node B. If this entry matches the current hop of the received message (and it does), the received message has already traveled closer to the destination. Therefore, node C discards its stored message, thus reducing network load.

If node C does not receive the message from node B in step 3 (or later), it assumes that the intended forwarder was unable to forward the message, and transmits the stored message after a certain timeout. In the example, a timeout of five time units has been chosen, therefore the message is forwarded in step 6.

4.3.2 Variations

To keep the routing tables up to date, it could be possible to learn routes from DATA messages. But that would require including the previous hop, as in the route reply messages. Also, it could be possible to replace the handling of messages by nodes that are not on the direct route: A probabilistic forwarding could be used. Using a random number generator, two thresholds (F and D) could be customized. If the random number R was below F, the message would be forwarded directly. If R was between F and D, the message would be discarded. If R was higher than D, the message would be deferred and forwarded if no retransmission by the next hop was overheard.

The first case is used to increase the chance of successful message delivery to the next but one hop. The second case reduces the network load while the third case represents the normal operation of OSBRDV and the redundant transmission needed to guarantee a certain delivery ratio.

Actual values for F and D should be chosen according to the average route length, frequency of changes and frequency of unidirectional links.

4.3.3 Advantages and Disadvantages

OSBRDV needs to transmit less messages than the previous two versions of Buckshot Routing. How much less depends strongly on the network topology and the number of unidirectional links involved. On the other hand, it gets more complicated, since a timer has to be set at configuration time and evaluated at runtime. If the configured timeout is too low, more messages than necessary will be transmitted. If it is too high, long delays will be introduced on lossy networks. The additional identity that is needed to determine whether or not a node lies on the original path must be stored in the routing tables and transmitted in data packets, thus increasing local storage and message size.

But the fact that less messages need to be transmitted could be worth these side effects (see chapter 5).