Assignment 2: CTP with in-tree aggregations

Since	08.01
Till	29.01 23:59 CET
Points	15

Extend Contiki’s RIME netstack with a CTP-like (Collection Tree Protocol) mechanism with in-tree aggregations.

The RIME implements a tree-based hop-by-hop reliable data collection (see examples/rime/example-collect.c): packets sent by all nodes in a network are routed in a tree-like way to a sink which recieves all these messages. Your task is to implement a similar data collection but with simple aggregations (sum, count, avg, min, max): the sink receives only the aggregated result of messages sent by all nodes in the network. Moreover, to minimize amount of transmitted data, the aggregations are performed in-tree: each mote sends an aggregated result from its subtree instead of forwarding all messages from its subtree. The aggregate function for the network is set by the sink. The sink can change the current aggregate function while the network is running: past values are discarded and calculations of the new aggregation are started.

The detailed specification is provided as the aggregate.h header file. There is also an example Contiki app example-aggregate.tgz. Your solution must implement the interface and be compatible with the example app. (However, if you feel that they can be improved, you are encouraged to discuss it).

Only the sink is notified (via a callback) about the aggregated result. However, for debugging and grading purposes each mote should printf:

[DS2019 A2] In-tree <current aggregate function>: <aggregated result from its subtree>

each time the aggregated value from the subtree where this mote is its root changes.

The evaluation of your solution will mainly assess:

• accuracy of the result: how accurate the aggregated values received by the sink are,

• latency of values: how long it takes for a mote’s value to be included in the final result,

• latency of the aggregate function changes: how long it takes for the network to start calculating the next aggregation when the sink changes it,

• amount of transmitted data: how many messages are transmitted within the network,

• power usage: how long motes’ radios are active.

Your solution will be evaluated using Cooja, UDGM Distance Loss medium model, Sky mote type, up to 100 motes. You can assume that there will be at most 1 sink in each network and that apps will be build without defining custom values for netstack-related constants.

Submit your solution by sending a <your-login-on-students>.tgz archive by e-mail with topic: “[DS2019] Solution 2”. The archive should contain:

• source of your implementation,

• a README file with a brief description of your solution (main ideas, created components, etc.) and optionally additional information concerning building, running and evaluating your solution.

Please do not include any unnecessary files.

Mind that you are allowed to talk about your ideas with your colleagues, but you are not allowed to share your source (any part in any form).

Evaluation

The evaluation is based on test simulations. Three kinds of test are run (see their descriptions below). The final score is calculated as the sum of points from the tests minus deductions (faults spotted in a solution).

Solutions which pass a simple test (like the example app) receive 8 points.

Solutions which pass manual tests receive additional 4 points. Manual tests use a simulation with 1 sink and 6 non-sink motes. TX and RX ratios are set to 99.0%. At the begining each mote waits 120 seconds (time for the network to settle), then the sink sets an initial aggregate function (max) and all motes wait 60s (time for the aggregate function to be propagated). The sink sends a constant value every 15 seconds. Non-sink motes send once a single value within randomized 0-15s. Then motes wait for serial commands to change the aggregate function (sink) or to send a new value (non-sink motes). The manual tests are passed when, in general, the sink reports correct aggregated results. Possible deductions:

Faulty aggregate function change

Changing the aggregate function gives no effect, the change is not propagated successfully, the new aggregation is not calculated, …

High latency of values

It takes relatively long time for a mote’s value to be included in the final result.

Sink must be sending values

When the sink doesn’t send its own values, it doesn’t report any aggregated results.

Values from before the aggregate function change are not disregarded

After changing the aggregate function past values are also included in the new aggregation.

Solutions which pass an automatic test receive additional 3 points. The test use a simulation with 1 sink, 9 non-sink motes and 1 special non-sink mote. TX and RX ratios are set to 75%. At the begining each mote waits 120 seconds (time for the network to settle), then sink sets an initial aggregate function (max) and all nodes wait 60s (time for the aggregate function to be propagated). All motes send their values every randomized 15-20s. The sink and non-sink motes send a constant value, whereas the special non-sink mote increases its value each time. The automatic test is passed when, in general, the sink reports correct aggregated results. Possible deductions:

Faults in reported results

The callback is called also when the result doesn’t change, some results during the test are missing, some incorrect results are reported, …

High power usage

Cooja reports high radio activity ratio. In most cases an info is propageted through the tree although the aggregated result in a subtree doesn’t change.