Synchronous Broadcast-based Aggregation

The proposed synchronous broadcast-based aggregation is designed based on the synchronous unicast-based protocol described in Section 3.3.1. With synchronous aggregation protocols, within each round of communication, all sensor nodes at the same distance (number of hops) from the sink are given the same interval of time in which to transmit. Nodes farther away from the sink are given earlier transmission intervals, so as to allow their data to be aggregated with that of nodes closer to the sink before these latter nodes make their own transmissions.

In the synchronous broadcast-based aggregation protocol, nodes are organized into a ring topology [67], as shown in Fig. 4.1. The sink is the only node that is located in ring 0, nodes one hop away from the sink are in ring 1, etc. As in the unicast-based protocol, nodes in different rings are allotted different time intervals within each round of communication for their transmissions. It is assumed that each node i knows its hop count hi to the sink and the maximum hop count H in the

tree, and accordingly chooses its transmission interval within each round. As before, the duration of the period between sensor readings is denoted by τ , and the interval duration by I. In a tree topology, each node forwards its data to its parent. In the ring topology, node i in ring hi may forward its data to multiple nodes in ring hi− 1,

as long as these nodes are within node i’s transmission range.

Unlike the synchronous unicast-based protocol, in the proposed broadcast-based protocol each interval is divided into a first and second phase with durations λI and

Ring 0 Ring 2 Ring 1 Sink Ring 2 Ring 1 Ring 3 T0 Ring 3

First phase of the interval Second phase of the interval

Sink

Time

I I I

Figure 4.1: Synchronous Broadcast-based Aggregation

(1 − λ)I, respectively. Each broadcast packet includes a bit vector indicating the nodes whose data is aggregated in the packet. Some applications may require the corresponding node ID of each value the sink collects to keep track of the changes that happen at the location where the node is deployed. The bit vector is not an overhead in this case, and the unicast-based protocols also have to carry such a bit vector. One method to implement the bit vector is to pre-configure the nodes with a running number starting at 0, then only one bit is needed for each node. If such preconfiguration is not doable, instead of carrying a long node ID, such as the 64-bit ID for mote-class devices, bloom filter, a space-efficient randomized data structure can be used to encode node information [10]. When the node ID for each value is not needed by the sink, the overhead of the bit vector can be further reduced through network partition. The bit vector only carries the IDs of the nodes that are located in the same network partition of the sender. The construction of the bit vector is not modelled in this work.

Each node (except for the sink) broadcasts a packet containing (possibly aggre- gated) sensor data during the first phase of its interval in each round. Nodes may also make a second broadcast during the second phase, as described below. To keep the data consistent, each node only collects one sampling value during each round, i.e., all data is collected when the node makes its first broadcast. Nodes aggregate all of the data they have received from broadcasts for the current round (including broadcasts from neighbouring nodes in the same ring), for their own broadcasts.

Specifically, in each round j, node i picks a random value r1ji between 0 and

(λ − 0.1)I, aggregates the data from the broadcasts it has received for this round, and makes its own first broadcast at time T0+ τ (j − 1) + (H − hi)I + r1ji. For nodes

that happen to choose a random value close to (λ−0.1)I, there is a 0.1I interval that allows their packets to get through before the second phase starts. Here it has been assumed that all nodes agree on the same base time T0 defining the beginning of the

first round. All neighbouring nodes that heard node i’s first broadcast for round j include node i’s data in the broadcasts they make later for that round. Node i then picks another random value r2ji between 0 and (1 − λ − 0.1)I. A broadcast is made

in the second phase of the round, at time T0+ τ (j − 1) + (H − hi)I + λI + r2ji, if, by

this time, node i has not heard a broadcast transmission from some other node in the same ring that has included node i’s data. There is a gap of 0.1I separating the second phase from the beginning of the next interval. Similar to the unicast-based protocol, randomizing the transmissions within each phase yields better performance than when all of the nodes in the same ring attempt to transmit at approximately the same time.

The second broadcasts are important to improve reliability. For nodes with few neighbours, or nodes that are the last among the nodes in the same ring to make their first phase broadcast, a second broadcast increases the likelihood that their data is received by at least one node in the next ring. This two-phase strategy can reduce the overall end-to-end loss rate significantly, at minimal additional cost in terms of numbers of transmissions.

aggregation that is performed, but rather attempts to model a range of scenarios in the performance experiments through consideration of two extreme cases with respect to how packet size grows with the number of aggregated values.