[ ] Resiliance to network outages. The solution functions when the network connection is
temporarily lost. This means buffering data, retransmissions, reconnecting, etc.
[ ] Data encryption. You can think of different methods of integrating security into your solution,
either using public-key cryptography or other methods.
[ ] Automated generation of unique identifiers (addresses) for sensor nodes. By default, the pro
grammer can assign static addresses to sensor nodes when running them (as a command-line
argument). But you can design automated-address assignments as part of your protocol. For
example, look at DHCP as an inspiration.
[ ] Images/files as sensor data. Imagine a scenario when a web camera is attached to a sensor
node and the image frames it captures could be transmitted to the control panel. Image
transfer poses some extra challenges. It is therefore considered an extra feature if you manage
to integrate it in your protocol and implement it in your source code.
[ ] Support of more flexible actuator commands. By default, it is expected that a command is
sent to a specific sensor node, specific actuator. If you manage to support also either broadcast
commands (to all sensor nodes at a time), or multicast (to specific groups of sensor nodes),
this is considered an extra.
[ ] Support data of different resolutions. For example, the sensor nodes could buffer and aggregate
data, and the actuator nodes could request the 1- 1-minute averages, 1-hour averages, etc.
Ideas from the teachers to increase our grade
Our ideas to increase our grade
....