# A Low Power IoT Sensor Node Architecture for Waste Management Within Smart Cities Context
## 3 Related Works
A heterogeneous multiprocessor sensor node is one of those, whose general idea is also exploited in our paper. Indeed, a sensor node generally has a workload that can be split into two rough parts depending on the amount of fulfilled operations. That amount directly implies a proportional power consumption resulting in a low workload period and a high workload one. Therefore, a sensor node could be equipped with two microcontrollers/microprocessors (both of them share elements like sensors and actuators, communication modules and power supply) each of which is in charge of managing the appropriate workload period (i.e., during the lower one the energy-thriftier microcontroller runs keeping turned off the energy-hungrier one and viceversa). As it will be verified in the rest of this paper, we commit to that paradigm: the two workload phases are managed by a microcontroller (for the higher one) and by a counter (for the lower one). Even though a counter is not an actual microcontroller, it has been chosen since no computational power is needed during the relative workload period. The survey [26] exposes different strategies to reduce the consumption of sensor nodes that rely on a limited budget of energy. Among many alternatives, the authors also point out the duty cycling method claiming that it has a main impact on energy waste sources. In particular, such a method is at the same time more effective on multiple causes of energy waste (like the sensing and processing phase, the communication phase or the idle phase) than other methods (like the topology control of the network or energy efficient routing algorithms). Of course, by combining those methods better results would be achieved. However, the sensor node we are proposing has not been included within a multi-hop network (it will be explained later on that our node was successfully tested by setting up a point-to-point wireless communication with a remote gateway, nonetheless it is expected to be part of a single star wireless network in the future), therefore only the management of duty cycle has been accounted. Other energy-saving techniques reside in thrifty communication protocols from the consumption point of view: at the network layer, by using energy aware routing algorithms [27; 28; 29; 30; 31; 32; 33; 34; 35; 36; 37], and at the medium access control layer as well [38; 39; 40; 41; 42; 43; 44; 45]. Also the network topology, as well as the node position within it, influences energy consumption. Regarding the former, a sparse topology could be an energy efficient solution [46]. Briefly, the idea proposed in this paper is to turn on each sensor node only when it detects an occurrence of the monitored event and then to turn it off once the transmission phase is completed; of course, some circuitry capable of detecting such an event should be constantly turned on and therefore it has to be carefully designed so as to limit its energy requirement. Regarding the position of the node within the network, it is well known that the higher the amount of data processed and transmitted by the node, the more power it requires. For instance, in a star network topology the central node requires much more power than the other ones. On the contrary, a node of a chain-type network with multi-hop communication methods requires more power as it is closer to the base station, since it is subject to a more intense data traffic compared with the one of the most peripheral nodes. This issue is addressed in several papers like [47; 48; 49; 50; 51]. There are also some surveys and papers that investigated power optimization algorithms for WSN [52; 53; 54; 55; 56]. Basically, they pointed out multi-objective paradigms, and some open problems as well, in order to improve lifetime in WSN. Due to all these reasons, a single star topology, rather than a chain-type one, will be preferred for the future realization of the WSN discussed in this paper, having replicas of our sensor node as components.