# A Low Power IoT Sensor Node Architecture for Waste Management Within Smart Cities Context
## 3 Related Works  
One of the targets of this study is to design a node whose power requirement is limited. If such a characteristic is satisfied, then a direct consequence would be an extension of the batteries lifetime which directly entails a minimization of human intervention to replace them. However, the fulfillment of this project specification is pretty challenging during the design phase of a wireless sensor node since it is mandatory to include a data transmission module. This component is one of the most power-hungry though, therefore at least one energy-saving approach (i.e., a strategy), or even more than one at the same time, must be adopted. Concerning the energy-saving aspect, in references [14; 15] event driven architectures are exploited in the Smart Cities perspective. Such an option has been avoided since the most suitable event for the application scenario (i.e., a waste disposal) is not reliable. Indeed, the realization of this event could have a relatively high frequency implying an almost constant powering of the IoT sensor node. That is the reason why a time-based policy is preferable. From the point of view of the consumption optimization, the core process resides in the employment of both a low power transceiver and a low power microcontroller since they are the components that most affect the available energy budget. With respect to consumption optimization, some papers, such as [16; 17], treat the issue proposing some studies and ideas to improve the node lifetime. In general, the most immediate energy-saving strategy obviously is to provide the sensor node with an energy harvesting solution [18]: the most common is the use of photovoltaic panels [19] but also other strategies have been proposed [20; 21]. An hydroelectrically powered sensor node was already discussed by the authors in [22]. While all these solutions are able to continuously power the monitoring system, they are unsustainable in term of costs. Even the cheapest energy harvesting solution has costs in the order of tens of euros, in the same order of magnitude of the overall cost of the components of the proposed node. Moreover, as it will be discussed in Section 4, the application scenario is not suitable for the use of renewable energy sources. A more cost-effective way to improve energy efficiency is to control the duty cycle of the node in an adaptive fashion, as it is shown in [23] where the authors present a control law for the duty cycle of the sensor node supposing that it is able to harvest energy form a certain source within the application scenario and that it relies on a rechargeable battery. The aim of the control law is to maintain a constant charge level of the battery by adjusting in real-time the duty cycle. Unfortunately though, the sensor node we are presenting cannot make use of any harvestable source of energy as it will be seen later on. Other methods based on mixed techniques of energy management are described in [24; 25; 26]. For instance, reference [24] gives a dichotomous division of energy management of sensor nodes: duty cycling and adaptive sensing. Concerning the latter, a classification of the strategies based on the way sampling is performed is provided pinpointing three macro-strategy paragons: hierarchical sensing, adaptive sampling and model-based active sensing. The last named could be one of the targets of future work related to the one we are showing. Indeed, such a technique develops a predictive model of the sensed phenomenon starting form set of data preliminary acquired. Those data could be the ones gathered with our prototype. Once the model is accomplished, energy consumption could be limited by sampling whenever it is supposed to be necessary according to the prediction of the model rather than on a periodic basis as it is done by means of duty cycling. Moreover, new acquired data could be useful to tune the predictive model as well. Some inspirations from which one can take advantage could be found in [25].