An approach for comprehensive Life Cycle Assessment and effective eco design of IoT systems: data-driven modeling of reference flows

An approach for comprehensive Life Cycle Assessment and effective eco design of IoT systems: data-driven modeling of reference flows | Research Square window.SnipcartSettings = { analytics: { enabled: false } }; (function() { var accessVector = localStorage.getItem('access_vector') || ''; window.dataLayer = window.dataLayer || []; if (accessVector) { window.dataLayer.push({ user: { profile: { profileInfo: { snid: accessVector } } } }); } })(); (function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src='https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);})(window,document,'script','dataLayer','GTM-K279D39R'); Browse Preprints In Review Journals COVID-19 Preprints AJE Video Bytes Research Tools Research Promotion AJE Professional Editing AJE Rubriq About Preprint Platform In Review Editorial Policies Our Team Advisory Board Help Center Sign In Submit a Preprint Cite Share Download PDF Case Report An approach for comprehensive Life Cycle Assessment and effective eco design of IoT systems: data-driven modeling of reference flows Ernesto Quisbert-Trujillo, Panagiota Morfouli This is a preprint; it has not been peer reviewed by a journal. https://doi.org/ 10.21203/rs.3.rs-3247380/v1 This work is licensed under a CC BY 4.0 License Status: Published Journal Publication published 20 Nov, 2023 Read the published version in Discover Internet of Things → Version 1 posted 7 You are reading this latest preprint version Abstract As we approach the limits of our technologies and the number of connected devices grows, scientists put more efforts to estimate and reduce the ecological damage of the Internet of Things. Unfortunately, environmental studies and eco design of IoT systems suffer from a major inconvenience so far: it does not put sensor data in the focus of attention. This paper aims to point out explicitly the essential role of this aspect for modeling reference flows and demonstrate its relevance for agile environmental assessment and sustainable design. Also, it aims to illustrate that such modeling process must happen in a comprehensive way. For this, our work relies on a case study addressing smart metering, and we proceed as follows. Based on available documentation and inspired by certain aspects of different technologies, we imagine the maximal capacities of key components, and we construct an unfavorable data flow scenario to get a rough idea of the reference flow and the long-term impact of our system during its use phase. Results from this procedure are later contrasted with results obtained from a packet traffic analysis, in which local and internet data flow are examined carefully. At the end, we verify the importance of data empirically, and we conclude that the reference flow and the impact contributors of a system could be affected not only by the local data transit but also by the complex interactions between edge devices and cloud resources. All our findings are discussed to produce generic guidelines for sustainable IoT systems. Internet of Things IoT IoT Systems Sensor systems Life Cycle Assessment LCA Eco design Reference flow Packet traffic analysis LoRa Figures Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 1. Introduction In 2020, it was said that the number of sensor devices exceeded the global Information and Communication Technology (ICT) fleet by an approximate factor of 1,2 [ 1 ], and by the end of 2023, it is expected 1,8 IoT-based connections on internet for each member of the global population [ 2 ]. As similar estimates project a steady, or even an exponential growth of connected devices; researchers have started to wonder what the ecological cost of using IoT systems will be. The advancements in transistor scaling and energy efficient systems over the last decades allow imagining optimistic scenarios. For example, recent projections show that the operational energy footprint share of specialized electronic components inside IoT devices will decrease to an insignificant level of 0,01% by the end of 2025 [ 3 ]; and estimations report a low increase of only 6% in total electricity consumption of data centers in a period of 8 years [ 4 ]. However, as more scientists foresee the limits of our technologies and embrace progressively a new beginning [ 5 , 6 ] —clearly steeped in massive data and pervasive computing, authors become more prudent with their projections. For instance, Koot, M., & Wijnhoven, F. [ 7 ] explain that the required electricity to power data centers only for industrial IoT in 2030 could amount to 364 TWh (considering an endless transistor scaling); but they also clarify that it could go up to 752 TWh, considering a progressive decay of the Law of Moore. On the other hand, although it has been already alerted a continuous growth of data centers and communication networks due to the booming of IoT [ 8 ], and recommended the correct dimensioning of sensor data [ 9 ]; little is said about these aspects in environmental assessments and eco design literature. We believe that one of the possible reasons that could explain this disregard is that, in general, reference flows of IoT systems tends to be modeled exclusively on the basis of energy and local equipment. According to the environmental management standard ISO 14040, the reference flow is the quantity of material, energy, or even additional subproducts and supplies needed to fulfill a functional unit as it is expressed [ 10 ]. As the basic functional unit of IoT systems is providing meaningful information to humans and/or machines in an autonomous way, an IoT system may have different environmental impacts from different reference flows (e.g., different sensor systems, edge devices, mutualized infrastructures or even different supplies, energy sources and consumption patterns), depending on the unique way by which it collects and transforms raw data, and sends information. This work develops this approach to highlight its relevance for impact estimation and eco design of the Internet of Things. It extends an initial design standpoint outlined in [ 11 ], and it has the following structure. section 2 presents the related work that help to understand our posture, and recalls our previous framework, which will be later implemented in section 3. Section 3 presents our case study, and the theoretical and empirical estimations of its reference flow and environmental impact from a cross-typed lifecycle model. Section 4 presents a discussion on our results in the context of impact assessment and eco design, and offers concrete guidelines for sustainable IoT systems. Section 5 concludes this work by summarizing our main findings and mentioning our parallel work in progress. 2. Related work In the last years, more attention has been putted on measuring the impact of partial [ 12 – 21 ] or full IoT systems [ 7 , 9 , 22 – 25 ]; and recently, on mitigating this impact in a methodologic way [ 12 , 15 , 26 – 30 ]. From this body of literature, Lelah, A. et al. [ 9 ] show that an increase in the circulation of data between sensors nodes and gateways (from a daily to an hourly transmission frequency) provokes significant modifications on the reference flow of local equipment (i.e.; scaling up photovoltaic cells, accumulators and batteries). Köhler, A. R. et al. [ 14 ] demonstrated for their part, that a reduction of the sensing spatial resolution of a textile-based sensor network decreases its reference flow per square meter in both sensor modules and energy consumption. What is more, they showed that more than 98% of power dissipation can be avoid only by switching off radio receivers, putting microcontrollers (MCUs) in sleep mode (when possible) and reducing the sampling rate of sensors from 10Hz to 2Hz (sticking the data resolution to the strict necessary). Dimensioning correctly sensor data is crucial for sober design, but other related aspects, such as determining how information is transmitted are fundamental too. In their study in eco design of wireless sensor networks, Bonvoisin, J. et al [ 15 ] show that lowing the hearing sensibility of sensor nodes to the strict necessary (by adjusting the probability of successful reception of messages to 95%) provokes a reduction of 10% on their energy needs, but also provokes more replacements of edge devices (embedded, battery-powered repeaters), because they spend more energy to maintain poorer communication links. This later drawback highlights two important aspects for impact estimation and eco design. Firstly, it uncovers the distinction between the physical and abstract definitions of sensor devices in a network (clearly stablished by the authors), and secondly, it introduces our posture, which says that modeling of reference flows must happen in a comprehensive way and on the basis of data flow, as Fig. 1 suggest (that is, by considering data, that flows through different devices (D) and electronic components (C), which execute specific functions with defined capacities (FC)). We believe that this is capital for accurate impact estimation and effective eco design of IoT systems. Indeed, Morin, E. et al. [ 31 ] have already suggested that the lifetime of IoT devices —in terms of the depletion rate of batteries, is drastically conditioned not only by the energy required in transmission and receiving functions, but also by a combination of additional factors linked to data manipulation and quality, including the data size required by the application, the data rate, and even the distance range at which wireless components operate in relation to other devices. In order to illustrate our approach and demonstrate its relevance in the context of IoT systems, the next section estimates theoretically and empirically the reference flow and the environmental impact of a case study from an analysis of its inner data flow, by implementing our proposed framework in a cross-typed lifecycle model. 3. Case study Our case study consists on an IoT system oriented to track water consumption in domestic environments. Its local infrastructure is composed of a sensor system [ 32 ] equipped with an induction emitter [ 33 ]; and a Long Range (LoRa)-Internet gateway [ 34 ]. The induction emitter (Fig. 2 ) is a separated sensor device powered by one 2/3AA-sized Li-ion battery. It is wired to the sensor system and generates electronic pulses by a bank of low voltage capacitors and inductors found in its electronic card (both in the front and the back side of its electronic card, within red frame in Fig. 2 b). The sensor system (Fig. 3 ) is a 9V-battery-powered device that has to be located no more than 30 meters from the induction emitter. It is equipped with a RN2483 LoRa module [ 35 ] (the bottom red frame of Fig. 3 b) and a YWW-BLEMOD Bluetooth module [ 36 ] (the top red frame of Fig. 3 b). Contrary to our preliminary assumptions presented in our previous work [ 11 ], its electronic card lacks of MCU and memory components. Because of that, it is believed that the device uses at least the embedded microprocessor of the System-on-Chip (SoC) subcomponent of its LoRa module to manage processing and transmissions tasks; and at least its embedded memory, to keep transitory data and metering configuration settings. The gateway (Fig. 4 ) is a device powered by the electric grid and plays the role of an edge device of the IoT system. It is equipped with the same LoRa and Bluetooth modules of the sensor system (Fig. 4 a); a WiFi ESP8266EX module [ 37 ] (left red frame in Fig. 4 b), an ARM Microcontroller and a Flash memory (right red frames in Fig. 4 b). According to the manufacturer, this device must be placed to no more than 800 meters from the sensor system. The most basic functioning of the IoT system is shown in Fig. 5 below (illustrated in terms of our proposed framework recalled in Fig. 1 ). The induction emitter is attached to a conventional jet meter and sends electronic pulses to the sensor system whenever the spinning disk of the jet meter indicates water consumption. In this sense, the sensor system plays the role of a flowmeter, tracking the pulses generated by the induction emitter. Periodically, the flowmeter communicates with the gateway wirelessly using LoRa technology. For its part, the gateway communicates with the cloud server through an Internet Access Point (IAP) device (e.g., an internet modem) by its WiFi module. On the other hand, a smartphone can stablish Bluetooth connections with the flowmeter and the gateway to either set/modify their initial configurations (e.g., security settings or sampling rate accuracy) or consult water consumption locally (consultations and metering configuration changes can be also held online, at mySolem.com). The flowmeter transforms the tracked pulses (raw data) into information (count of pulses), and send this information to the gateway every 3 minutes (according to technical documentation). Because the flowmeter records the counts every 15 minutes (as declared by the manufacturer), it is believed that the gateway accumulates the periodic LoRa packets transmitted by the flowmeter and update the cloud server every 15 minutes, to keep synchronized the water consumption statistics on the local and the cloud equipment. Bearing in mind all these aspects and based on technical documentation, Fig. 6 presents a customized implementation of our framework, which is oriented to estimate the data flow within the IoT system of our case study starting from the maximal capacities of key components, and from that, the reference flow and impact of its use phase in the long term, assuming an unfavorable data flow scenario. The Functional unit that leads this analysis is defined as “facilitating the hourly monitoring of water consumption of an area of 1 km 2 , during 2 years”. For obtaining the embodied global warming damage, environmental data from the CML-IA 2001 Life Cycle Impact Assessment (LCIA) method was used. Because this work is focused on the use phase of our case study, the implementation presents all the physical elements that allows the functioning of the local equipment (i.e.; the dotted elements) but their respective manufacturing and disposal life cycle phases are not taken into account. Also, notice that a battery can be seen as a component itself (power unit) and, at the same time, as a part of the reference flow (whose number vary according to the operational context of the system). Double-sensed red arrows in Fig. 6 indicate data application flow or additional traffic related to internet protocol mechanisms. We assume the IAP device as an element of the internet infrastructure (access network) . To define the maximal capacities of the system and establish an unfavorable data flow scenario for our analysis, in this work we focus on some features of the LoRa technology. LoRa is a modulation technique optimized for long-range, low-power-consumption communications in IoT environments [ 38 ]. In order to cover long distances and keep high Quality of Service (QoS), LoRa uses an Adaptive Datarate Routine (ADR) that regulates the bitrate at which data is encoded in a determined bandwidth, according to a Spreading Factor (SF). The spreading factor is a parameter that determines the number of bits transmitted per LoRa symbol and it is inversely proportional to the bitrate. When the distance range between two devices increases, the established link in LoRa communications degrades. To assure quality in transmissions, the ADR mechanism regulates the spreading factor to high values, which lowers the data encoded per second (the bitrate reduces), extends the time-on-air of a data sequence and consequently, prolongs the transmission states of transceivers. Table 1 gives the optimal data application size (data payload) that a LoRa packet can carry efficiently in different bandwidths and distance ranges, according to given Spreading Factors (the affected bitrates are also showed). Table 1 Data application size (payload) that a LoRa packet can carry according to different parameters Spreading factor Bandwidth Data application (payload) Bitrate Range SF12 125 kHz 51 Bytes 290 bps 14 km SF11 125 kHz 51 Bytes 440 bps 11 km SF10 125 kHz 51 Bytes 980 bps 8 km SF9 125 kHz 115 Bytes 1760 bps 6 km SF8 125 kHz 242 Bytes 3125 bps 4 km SF7 125 kHz 242 Bytes 5470 bps 2 km In this sense, to construct an unfavorable data flow scenario for the analysis, we assume that the data application size of the case study is equal to the maximal data payload allowed within a bandwidth of 125 kHz and a spreading factor of 7 (242 Bytes). This corresponds to a distance range of 2 Km, which is close to the maximal distance range recommended by the manufacturer (800 meters). We also assume that any data reduction task is applied on the gateway (the accumulated counts are simple resent to the cloud server). 3.1. Theoretical estimations This section models the reference flow of the case study under the unfavorable data flow scenario suggested above, and based on available information. The sampling rate of the induction emitter is assumed to 10 pulses per second. Under this configuration, the lifetime of its battery is approximately 10 years (according to the manufacturer). Consequently, the reference flow of using this device in normal conditions for two years (as is defined by the functional unit) is only one battery, and its associated impact is 3,82 🞫 10 − 2 Kg CO 2 -eq. This damage corresponds to the impact of producing a single Li-ion battery of one-dry-cell that weights 5,65 grams. On the other hand, the reference flow of the flowmeter (in terms of the number of batteries ( \({B}_{fm}\) ) required during two years) is given by the following equation. $${B}_{fm}=TT{E}_{LoRa}\left({BD}_{{T}_{x}}\times {t}_{{T}_{x}}+{BD}_{s} \times {t}_{s}\right)$$ 1 Where, $$TT{E}_{LoRa}= Total LoRa Transmission Events in two years \left(350333\right)$$ $${t}_{{T}_{x}}=Time elapsed in transmission state during a LoRa trans. event$$ $${t}_{s}= Time elapsed in sleeping state during a LoRa trans. event$$ $${BD}_{{T}_{x}}=Battery Depletion factor trans. mode \left(1 battery per \text{25,6} hours\right)$$ $${BD}_{s}= Battery Depletion factor sleep mode \left(1 battery per 712500 hours\right)$$ Below, we present the main assumptions and calculations to obtain every component of Eq. 1 . Firstly, we assumed that the energy consumption for simply counting the electrical pulses depends on the current consumption of the sleep mode, and the time elapsed in this state ( \({t}_{s}\) ); and for transmitting the counts, on the current consumption of the transmitting mode, and the time elapsed in this state ( \({t}_{{T}_{x}}\) ), as showed in Fig. 7 . Secondly, the time elapsed in the transmission state in a LoRa transmission event is the quotient between the final size of a LoRa packet ( \(P{S}_{LoRa}\) ) and the bitrate capacity ( \(B{R}_{SF}\) ) of the LoRa module, which is determined by a SF of 7 in a bandwidth of 125 kHz (Eq. 2 ). $${t}_{{T}_{x}}=\frac{P{S}_{LoRa}}{B{R}_{SF}}$$ 2 Where, $$P{S}_{LoRa}= final size of a LoRa packet \left(2256 bits\right)$$ $$B{R}_{SF}= bitrate capacity under a SF7 and a 125kHz bandwidth \left(5470 bps\right)$$ Thirdly, according to technical data and the established unfavorable data flow scenario, we assume that the microprocessor of the flowmeter’s LoRa Module collects and counts the electrical pulses generated by the induction emitter during 3 minutes (180 seconds), creating a maximal payload of 242 bytes. To send this data payload, the LoRa module adds to it headers and footers, conforming full LoRa packets of 282 bytes. Thus, by considering this packet size in bits (2256 bits), the time that the LoRa module is in transmission mode ( \({t}_{{T}_{x}}\) ) in a transmission event is 0,41 secs (or 1,14 🞫 10 − 4 hours); and in sleeping mode, ( \({t}_{s}\) ), 179,59 secs (or 4,98 🞫 10 − 2 hours). Fourthly, if the flowmeter would have to transmit continuously, the Battery Depletion factor for the transmission mode ( \({BD}_{{T}_{x}}\) ) would be 25,6 hours. This is the quotient between the nominal capacity of a 9V PP3-typed battery (1200 mAh) and the current consumption of the flowmeter’s LoRa module in transmission mode (44,5 mA), all multiplied by an output current performance rate of the battery of 95%. Similarly, if the flowmeter would have to sleep continuously, the Battery Depletion factor for sleeping mode ( \({BD}_{s}\) ) would be 712500 hours (considering the same nominal capacity of the battery and a current consumption of the flowmeter’s LoRa module in sleeping mode of 1,6 🞫 10 − 3 mA). Thus, by considering all these aspects in equation one, and by knowing that the total LoRa transmission events in two years amount to 350333 (one every 3 minutes), the reference flow for the flowmeter is two batteries . This generates a damage of 0,458 Kg CO 2 -eq, which corresponds to the impact of producing 2 Li-ion 9V pp3-typed batteries of six dry cells that weights 33,9 grams). Regarding the gateway, it is believed that this device (1) accumulates the LoRa packets generated by the flowmeter during 15 minutes (which generates a data payload of 1410 Bytes), and (2) transmits these data to the cloud server in a Hypertext Transfer Protocol (HTTP) post request (which generates a packet of 1480 bytes). To do all this, the device requires 6 🞫 10 − 3 kW (according to technical documentation), which means a total electricity consumption of 105,12 kWh during two years. This generates an impact of 5,15 Kg CO 2 -eq, according to the CML-IA LCIA methodology and assuming a French electricity mix. To estimate the reference flow and the impact of the cloud layer, we determine the data traffic from the gateway to the cloud server (regular operational mode) and the data traffic from the smartphone to the cloud server (consultation operational mode). For the regular operational mode, one considers the total number of transmission events (assumed to one every 15 minutes, during two years), the final packet size of HTTP POST requests (packets of 1480 bytes generated by the Gateway, and addressed to the Cloud server (we call these packets “HTTP post GC”)), and the additional data generated by the Transmission Control / Internet protocols (TCP/IP) overhead (packets regarding acknowledgements (TCP ack), TCP three-way handshake (“TCP ths”) and TCP teardown (“TCP t”) mechanisms). Thus, by considering a total of 70066 transmissions events during two years, the total data traffic flowing between the gateway and the cloud server amount to 0,1331 Gigabytes (GB). For the consultation operational mode, one considers the total number of transmission events (one every hour, during two years), the packet size of HTTP GET requests (assumed to one byte each), the packet size of HTTP responses (assumed to one byte each), and the additional data generated by the TCP/IP protocol overhead. Thus, by considering a total of 17520 transmission events during two years, the total traffic flowing from the smartphone to the cloud server amounts to 1,03 🞫 10 − 2 GB. From this, the reference flow related to the internet networks and cloud server amounts to 2,15 🞫 10 − 2 kWh and 2,01 🞫 10 − 2 kWh respectively (assuming an electricity intensity factor of 0,15 kWh/GB for the internet infrastructure, which is a median value between that one proposed by Malmodin, J. et al. [ 39 ] and Krug, L. et al. [ 40 ]; and an electricity intensity factor of 0,14 kWh/GB for the cloud server infrastructure, as reported by Andrae, A. S., & Edler, T. [ 41 ]). Thus, the impact generated by the internet networks amounts to 1,7 🞫 10 − 2 Kg CO 2 -eq; and the impact generated by the cloud server to 1,6 🞫 10 − 2 Kg CO 2 -eq (both assuming a global electricity mix and according to the CML-IA LCIA methodology ). Finally, the estimation of the reference flow from using the smartphone considers only the energy needed for powering its WiFi module in the transmitting and receiving modes (1,62 🞫 10 − 3 and 1,375 🞫 10 − 3 kW respectively, according to Perrucci, G.P. et al. [ 42 ]), multiplied by the total time that the WiFi module works in two years (292 hours, if one assumes that the user turns on the WiFi function of the phone during one minute to consult his or her water consumption hourly). Thus, the reference flow of the smartphone for sending consultation requests and receiving responses amounts to 0,5 kWh and 0,423 kWh respectively. Both reference flows add up an impact of 4,5 🞫 10 − 2 Kg CO 2 -eq, which correspond to the impact of charging a smartphone oriented only to the functional unit of this analysis, and by assuming a French electricity mix . Table 2 below offers a summary of all these assumptions and calculations oriented to establish the reference flow of the case study in the use phase, which generates a total impact of 5,7235 Kg CO 2 -eq. Table 2 Summary of the electronic components, functions and capacities considered to estimated theoretically the reference flow and the impact of the case study Device E. Component Function Capacity Reference flow Impact a Pulse meter Cap. & Ind. Generate pulses Sampling rate (10 pulses/sec) 1 Li-ion battery 0,038 Li-ion battery Power supply Nominal capacity (1650 mAh) Flowmeter LoRa module Counting pulses Current cons. Sleep mode (0,0016 mA) 2 Li-ion 9V Batteries 0,458 LoRa module Sending counts Bitrate (5470 bps) LoRa module Sending counts Current cons. Tx mode (44,5 mA) Li-ion 9V battery Power supply Nominal capacity (1200 mAh) Gateway LoRa & WiFi mod. Rec. Prep. and Resend counts Power cons. (0,006 kW) 105,12 kWh 5,150 Smartphone WiFi module Hourly consultation Power cons. Send (1629 mW) 0,501 kWh 0,045 WiFi module Hourly consultation Power cons. Rec. (1375 mW) 0,423 kWh Internet Net. Electricity cons. (0,15 kWh/GB) b 0,0215 kWh 0,017 Cloud server Electricity cons. (0,14 kWh/GB) c 0,020 kWh 0,016 Total 5,723 a Expressed in Kg CO 2 -eq b Median electricity intensity factor considering the values suggested by Malmodin, J. et al. [ 39 ] and Krug, L. et al. [ 40 ] c Electricity intensity factor reported by Andrae, A. S., & Edler, T. [ 41 ] 3.2. Empirical estimations This section models the reference flow of the case study from a data traffic analysis. It was conducted by implanting two network analyzers (sniffers) into the IoT system, according to the experimental deployment presented in Fig. 8 . In Fig. 8 , a Wireshark-based sniffer (packet sniffer A) equipped with a RTL2832U-based dongle and GNU-radio companion software (running in a Linux PC) is placed to capture the LoRa packet traffic between the flowmeter and the gateway. A customized GNU-radio companion model based on gr-lora implementation [ 43 ] was developed to allow the dongle intercept LoRa transmissions. The second sniffer (packet sniffer B) is a Wireshark-based sniffer using the wireless Network Interface Controller of a desktop Windows PC (in promiscuous mode). It aims to capture and analyze the WiFi traffic of the system. The distance between the flowmeter and the gateway is 4 meters. The packet traffic analysis was conducted as follows. The network operated approximately 10 hours (from 11h40 to 22h20). During this period, regular water consumption was emulated by applying compressed air to the jet meter, and hourly consultation were made, by acceding the user’s interface in the cloud server via a smartphone equipped with a WiFi module. Sniffer A and B were initialized before starting up the network. To capture the LoRa transmissions, the GNU-Radio companion model considered a spreading factor of 7, a frequency band of 868 MHz hearing in three frequency channels, and a bandwidth of 125kHz. The LoRa transmissions were intercept by the RTL-RDS bundle and transformed into User Datagram Protocol (UDP) packets, which were reoriented to the Wireshark interface by the ports 40868, 40869 and 40870 of sniffer A (one for every frequency channel). In the packet traffic captured and reported by sniffer B, specific Wireshark filters were applied. Figure A2 in the Supplementary Information shows a sample of the packet traffic between the flowmeter and the gateway captured by the sniffer A (from 21h06 to 22h06). Each point represents the aggregated data size of a LoRa transmission in minute resolution (excluding UDP headers). On it, it can be observed that transmissions occur effectively every 3 minutes (with some exceptions, in which packet loss is assumed) and, besides some outliers, it could be said that the generic size of LoRa packets is 57 Bytes (as it is documented in the section 4 of the Supplementary Information). By considering this packet size in equation two, the time elapsed in transmission mode ( \({t}_{{T}_{x}}\) ) is rather 0,083 secs (and the time that it sleeps ( \({t}_{s}\) ) is 179,92 secs). In this sense, the flowmeter requires only one battery to operate during two years (according to equation one). This provokes an impact of 0,229 Kg CO 2 -eq, which corresponds to the impact of producing only one 9V-PP3-typed battery (more details about these results are available in the section 6 of the supplementary material). With respect to the data traffic within the internet network and cloud server, figure A3 in the Supplementary Information (section 5) shows a refined sample of the WiFi traffic of the system (for the regular and the consultation operational modes) occurred in approximately two minutes (from 21h58m03s to 21h59m51s). On it, each point represents the aggregated data size of Domain Name System (DNS), TCP and HTTP transmissions occurred in second resolution, and it is observed that, in the regular operational mode, the transmission events between the gateway and the cloud server occur every 18 seconds (contrary to our assumptions stated in the previous section). Moreover, a detailed inspection of the TCP traffic (which is also illustrated in the table A3 of the Supplementary Information) shows that the three-way handshake and the teardown TCP mechanisms generates packets (SYN, SYN/ACK, ACK, FIN or FIN/ACK types indistinctly) with a mean size that range from 54 to 58 bytes (this suggests that the TCP, IP or MAC headers of these packets do not include certain optional fields). Another inspection on the HTTP traffic shows that the POST request-typed packets with data application are fixed to 200 Bytes. This suggest that the gateway executes processing tasks oriented to transform the data payload of the incoming LoRa packets into formatted HTTP POST-type packets with constant size addressed to the cloud server. On the other hand, the cloud server generates HTTP timeout-request packets of approximately 468 bytes before starting a TCP teardown routine. A timeout request allows a server announce and close an unused connection, and the continuous presence of this type of request in our case study would suggest that the gateway waits for this request to start a TCP teardown routine. Beside of this, the Intensive HTTP traffic observed in figure A3 (from 21h59m13s to 21h59m31s) during a water consultation request via the cloud server (by acceding the user’s dashboard at www.mySolem.com ) would suggest extra transmissions stablished between the gateway and the cloud server, in which the server asks the gateway for additional data (data that probably differs from counts). This generates high volumes of data that seems to be fragmented on packets (7 approximately) of less than 800 Bytes (as it is documented in table A3 of the supplementary material). Finally, in the packets traffic analysis one can observe unexpected Domain Name System (DNS) packets too. DNS is an upper-layer protocol in charge of finding the IP address from a Uniform Resource Locator (URL); in this case www.mySolem.com . When a device needs to find and save the IP address of a remote server from an URL, it sends a query request to a DNS server —usually hosted in the cloud, which sends the response information in a query response [ 44 ]. This operation takes place usually in early connections and the recurrent presence of DNS requests (with a mean size of 71 bytes each) and DNS responses (with approximately 87 bytes each) in the regular operation of our case study (sending counts every 18 seconds) suggest that the gateway do not keep in memory the IP address of the cloud server (generating extra traffic in mutualized infrastructures). Table A4 in the Supplementary Information (part 7) synthesizes the data flow observed in the packet traffic analysis for the regular and consultation operational modes, highlighting the new behavior disclosed above (gray cells) and disclosing a total data volume of 4,305 GB. From this, the reference flow of the internet networks and cloud server amounts to 0,6457 kWh and 0,6027 kWh respectively (assuming the electricity intensity factors mentioned before). This provokes an impact of 0,5 Kg CO 2 -eq for the internet use, and 0,467 Kg CO 2 -eq for the cloud server (both assuming a global electricity mix). In this way, and considering the same impact coming from the same reference flow of the induction emitter, the gateway and the smartphone; the total impact estimated from the packet traffic analysis of the case study amounts to 6,4296 Kg CO 2 -eq. 4. Discussion The absolute impact calculated from the packet traffic analysis in section 3.2 exceeds than one calculated from the proposed implementation of our framework in section 3.1 by 12,34%. The difference is explained mainly by the additional data revealed in the regular and consultation operational modes (red texts in Fig. 9 ), which increased significantly the reference flow of the Internet & Access networks and the cloud server (in terms of electricity used per GB generated by the gateway and the cloud server). Importantly, the impact contribution of the Internet & Access networks and the cloud server went from being insignificant in the theoretical estimation of the reference flow of the system, to relevant in the empirical estimation (overcoming the impact contribution of the flowmeter, as is showed in Fig. 10 ). In this sense, three redesign initiatives could be discussed. Firstly, designers could reconfigure the gateway to keep in memory the IP address of the cloud server and trigger mechanisms to reobtained it, whenever it changes (this would avoid unnecessary DNS traffic in every transmission event of the regular operational mode). Secondly, designers could set the gateway to initialize a TCP teardown routine automatically (this would prevent the server from sending HTTP timeout requests after uploading data application). In this line, designer could consider alternatively the use of connectionless protocols. Thirdly, designers could configure the gateway to execute preprocessing routines (data aggregation or data reduction techniques) to avoid massive HTTP traffic (POST requests) whenever an online consultation of water consumption occurs. However, designer should proceed with caution, as the synthesis or reduction of information may damage the accuracy of the system and/or require more energy. On the other hand, the impact contribution of the gateway is undeniable. To mitigate it, designers should consider alternative self-powered versions of this device. However, in order to this drastic change makes sense, it should be accompanied by a redesign of the entire data flow of the system, oriented to manage only the necessary transmission frequency, with sufficient quality (in this sense, an analysis on the reasons that provokes the high frequency of transmission events in the regular operational mode need to be conducted). Beside of that, it is intriguing to see that the manufacturer recommends a maximal distance range of 800 meters between the flowmeter and the gateway, when the LoRa technology offers longer communication ranges (from 2 to 14 km). Although revealing the reasons why the manufacturer suggests this distance is beyond the scope of this work, it is believed that a probable motivation is assuring high QoS and maximizing the lifetime of the flowmeters’ batteries (by avoiding long time-on-air periods, as it was explained in section 3). However, this would lead to drawbacks, because the number of gateways in a network could increase, depending on their locations and especially on the extension of terrains, as explained below. Figure 11 shows for example that, to cover an area of 2,56 km 2 , (1,6 🞫 1,6 km), a deployment of at least three gateways is required (according to the recommendations of the manufacturer). However, this does not necessarily have to be so. The packet traffic analysis conducted in this work shows that the flowmeter does not generate significant volumes of data application (approximately 57 Bytes per LoRa transmission event). By considering that this load was perfectly managed by one gateway in a 125 kHz bandwidth and a Spreading Factor of 7, there is sufficient evidence to believe that, under the same conditions, a flowmeter could be covered perfectly within a distance range of 2 km and for more than 5 years, as estimations in the second row of Table 3 suggest. Table 3 Estimation of the maximal lifetime of one Li-ion 9V battery for transmitting periodic LoRa packets of 57 Bytes, under different operational conditions of the flowmeter (in years) In a transmission (s) Distance (km) SF Band. (kHz) Payload (bytes) Bitrate (bps) \({\varvec{t}}_{{\varvec{T}}_{\varvec{x}}}\) \({\varvec{t}}_{\varvec{s}}\) \({\varvec{B}}_{\varvec{f}\varvec{m}}\) (In 2 years) Lifetime (In years) 2 SF7 250 242 11000 0,041 179,96 0,182 11,0 2 SF7 125 242 5470 0,083 179,92 0,341 5,9 4 SF8 125 242 3125 0,146 179,85 0,579 3,5 6 SF9 125 115 1760 0,259 179,74 1,009 2,0 8 SF10 125 51 980 0,465 179,53 1,793 1,1 11 SF11 125 51 440 1,036 178,96 3,964 0,5 14 SF12 125 51 290 1,572 178,43 6,002 0,3 The detailed calculations to obtain the maximal lifetime of the flowmeter’s battery in years are available in the section 8 of the Supplementary Information. On the other hand, the 2 rightest columns of Table 3 reveals two interesting aspects for the reference flow of the case study and its eco design. Firstly, intentions of replacing the battery-powered design of the flowmeter by another self-powered design would be beneficial only in specific contexts. For example, if the distance range is about 14 km, switching to a self-powered version of the flowmeter would avoid the continuous replacement of batteries in the short-term (i.e.; approximately six batteries every two years). However, if the local transmissions involve distance ranges of 2 or 4 km, and a selected bandwidth of 125 kHz, a self-powered design would bring only marginal benefits (one would avoid just changing one battery approximately every 6 or 3 years). What is worse, one could transfer impacts from the use-phase of the flowmeter to its manufacturing phase (depending on the complexity of its self-powered design). Secondly, maximal benefits could be obtained by using a bitrate of 11kbps in a 250 kHz bandwidth (a battery would be replaced approximately once every 11 years). Although this analysis on distance ranges and technical capacities could reveal even more tradeoffs in design stages, it should be taken into account prudently, as more variables influencing the quality of LoRa transmission may exits (further research and estimations should be conducted, as long as documentation about the design of the flowmeter, gateway and the dataflow between them becomes publicly available). Finally, the packet traffic analysis presented in this work demonstrates that the frequency at which the local infrastructure connects with the cloud infrastructure, the volume of data generated and transmitted, and the protocol overhead of transmissions in regular and / or user-driver operations are all fundamental aspects to be considered in the modeling of reference flows and impact estimation of full IoT systems. This aspect warns Life Cycle Assessment (LCA) practitioners from be cautious about the postures of Malmodin, J. et al. [ 39 ] and Coroama, V.C., et al. [ 45 ] who suggest that, for estimating the electricity intensity of ICT (which is different from estimating its ecological impact), end devices —such as sensor systems— should be consider only from a use time perspective. To extend this discussion, and nourish further research and works in the context of similar case studies, the following guidelines are offered to the LCA and eco design communities. Guideline 1 The protocol overhead is relevant, depending on the transmission frequency and the reliability degree of applications. When low-accuracy applications characterize an IoT system, high frequency is not necessary and approximate computing can be applied. Guideline 2 When invariable behavior characterizes an application (i.e.; uniform water consumption, unchanging lighting pattern in households, etc.) information can be extrapolated from historical or redundant data in the cloud infrastructure so that massive local-to-cloud transmissions can be avoid. Guideline 3 When high transmission frequency is necessaire, consider connectionless protocols and reinforce security (for example by using message authentication, rate throttling, robust encryption, etc.). However, evaluate simultaneously the additional energy requirements of security routines and find a balanced solution distributed over the sensing, edge and cloud layers. Guideline 4 When estimating the reference flow of an IoT system for its (re)design, consider not only the operational time of local devices but also their energy consumption patterns in time affected by different circumstances and different capacities of different electronic components, in the context of functions and data flow (e.g., sampling rates in data collection, maximal payloads in data processing, bitrates, frequency bandwidths or distance range in data transmission, etc.). Guideline 5 When estimating the impact of the use phase of an IoT system whose design documentation is unavailable, consider that additional communication between IoT layers may occurs when a user or a device retrieves information directly from cloud resources. Guideline 6 Study functions-capacities of electronic components in an exhaustive way, so that to find those ones that boost or challenge a design. For example, wireless modules with high bitrates makes sense only when irreducible big payloads are expected (e.g., image, video, etc.). Guideline 7 Study functions-capacities of electronic components and operational contexts carefully, so that to propose reasonable designs. For example, in the context of LoRa-based IoT systems, using the Frequency-Shift Keying (FSK) modulation makes sense only when the application type generates big payloads. Guideline 8 Consider several aspects of the operational context that may affect not only the efficiency of electronic components, but also the data flow design (and consequently the reference flow) of an IoT system. For example, in the context of LoRa-based IoT Systems, long distance ranges would force designers to consider either energy intensive data preprocessing routines in local microprocessors (increasing energy consumption in the sensing and edge equipment, but reducing energy consumption in the mutualized infrastructure), or change the planned sampling rate of a sensor component (lowing energy needs in the local and mutualized infrastructure, but scarifying data resolution). 5. Conclusions and on-going research In our increasingly connected world, this research aims to point out the capital role of sensor data for modeling the reference flow of IoT systems and, in this way, illuminate the way for LCA practitioners and IoT designers to conduct comprehensive assessments and efficient eco design. To do this, we proceed in three parts. Firstly, we presented the previous literature that reports significant variations on reference flows and impact from changes made on data flows. Secondly, we proposed a customized implementation of our previous framework to estimate the reference flow of a case study and, in this manner, to have a rough idea of its impact in the use phase, in a long-term, and in an unfavorable data flow context. Thirdly, we conduct a packet traffic analysis to estimate empirically the real reference flow of the case study. From the first part, although the reviewed authors do not state explicitly the relevance of sensor data or data flow for modeling reference flows and estimating impacts, they provide solid evidence that helps to understand our posture and defend our simple yet powerful framework oriented to facilitate integral impact assessment and effective eco design. From the second part, it was showed that comprehensive and agile estimations can be conducted from available information (technical specifications) of key electronic components applied in a cross-type life cycle model. From the third part, the central role of data has been verified by demonstrating that its flow can modify the reference flow of a system and even redistribute the impact contribution of the local and mutualized infrastructure calculated theoretically. In this part, it was also observed the potential complexity of interactions between local and mutualized infrastructures and it was noted that, in the long-term, the absolute impact of the internet and cloud components of and IoT system should not be neglected. To reach to these conclusions and present a fruitful discussion that facilitate the production of generic guidelines for agile impact estimation and eco design, in the second and the third parts we made use of a customized implementation derived from our previous framework, which is based on the simple, yet powerful association of functions-capacities of electronic components. This framework, together with another one oriented to facilitate the integration of ecological aspects into the New Product Development (NPD) of local IoT prototypes [ 46 ] are being tested in parallel in the industrial and educational context. Both conform a methodology for sustainable IoT systems. LCA practitioners and designers should apply them simultaneously in the context of their own projects, as a sort of roadmap that recalls that each parts, such as data, information, devices, function, capacities, and electronic components (including its physical and technical characteristics and circularity potential) must be examined holistically and carefully. Declarations Acknowledgements This work was supported by the French National Research Agency in the framework of the "Investissements d’avenir” program (ANR-15-IDEX-02). This work was also funded thanks to the French National program « programme d’invertissements d’avenir, IRT Nanoelec » ANR-10-AIRT-05. Authors’ contributions Conceptualization, Methodology and Writing —original draft preparation: Ernesto Quisbert-Trujillo; Writing —review and editing: Panagiota Morfouli; All authors read and approved the final manuscript. Data Availability Statement The authors declare that the data supporting the findings of this study are available within the paper, its reference section and its supplementary information files. Full pcapng Wireshark files generated during the Packet Traffic Analysis and used for producing Figure 9 are available from the corresponding author on reasonable request. Funding This work was supported by the French National Research Agency in the framework of the "Investissements d’avenir” program (ANR-15-IDEX-02). This work was also funded thanks to the French National program « programme d’invertissements d’avenir, IRT Nanoelec » ANR-10-AIRT-05. Competing interests The authors declare no conflict of interest. References Figliola PM. The Internet of Things (IoT): An Overview. Congressional Research Service; 2020. CISCO., "CISCO Annual Internet Report (2018–2023)," 2020. Das S, Mao E. The global energy footprint of information and communication technology electronics in connected Internet-of-Things devices. Sustainable Energy Grids and Networks. 2020;24:100408. Masanet E, Shehabi A, Lei N, Smith S, Koomey J. "Recalibrating global data center energy-use estimates," Science , vol. 367, no. 6481, pp. 984–986, 2020. Track E, Forbes N, Strawn G. The End of Moore's Law. Comput Sci Eng. 2017;19(2):4–6. Theis TN, Wong H-SP. The End of Moore's Law: A New Beginning for Information Technology. Comput Sci Eng. 2017;19(2):41–50. Koot M, Wijnhoven F. Usage impact on data center electricity needs: A system dynamic forecasting model. Appl Energy. 2021;291:116798. Belkhir L, Elmeligi A. Assessing ICT global emissions footprint: Trends to 2040 & recommendations. J Clean Prod. 2018;177:448–63. Lelah A, Mathieux F, Brissaud D. Contributions to eco-design of machine-to-machine product service systems: the example of waste glass collection. J Clean Prod. 2011;19:9–10. International Organization for Standardization, Technical Committee. : ISO/TC 207/SC 5, ISO 14040:2006 Environmental management - Life cycle assessment - Principles and framework , 2006. Quisbert-Trujillo E, Ernst T, Samuel KE, Cor E, Monnier E. "Lifecycle Model eco Des Internet Things " Procedia CIRP, 2020. Bonvoisin J, Lelah A, Mathieux F, Brissaud D. An integrated method for environmental assessment and ecodesign of ICT-based optimization services. J Clean Prod. 2014;68:144–54. Wagner E, Bohme C, Benecke S, Nissen NN, Lang K-D. "Advanced packaging for wireless sensor nodes in cyber-physical systems - impacts of multifunctionality and miniaturization on the environment," in 2017 IEEE International Conference on Prognostics and Health Management (ICPHM) , 2017. Köhler AR, Lauterbach C, Steinhage A, Buiterv JC, Techmer A. "Life cycle assessment and eco-design of a textile-based large-area sensor system," in Electron Goes Green 2012+, 2012. Bonvoisin J, Lelah A, Mathieux F, Brissaud D. An environmental assessment method for wireless sensor networks. J Clean Prod. 2012;33:145–54. Van Dam S, Bakker C, Buiter J. Do home energy management systems make sense? Assessing their overall lifecycle impact. Energy Policy. 2013;63:398–407. Dubberley M, Agogino A, Horvath A. "Life-cycle assessment of an intelligent lighting system using a distributed wireless Mote network," in IEEE International Symposium on Electronics and the Environment , 2004. Conference Record. 2004, 2004. Pirson T, Bol D. Assessing the embodied carbon footprint of IoT edge devices with a bottom-up life-cycle approach. J Clean Prod. 2021;322:128966. Glogic E, Futsch R, Thenot V, Iglesias A, Joyard-Pitiot B, Depres G, Rougier A, Sonnemann G. Development of Eco-Efficient Smart Electronics for Anticounterfeiting and Shock Detection Based on Printable Inks. ACS Sustain Chem Eng. 2021;9(35):11691–704. Van Der Velden NM, Kuusk K, Köhler AR. Life cycle assessment and eco-design of smart textiles: The importance of material selection demonstrated through e-textile product redesign. Mater Design. 2015;84:313–24. Brun GL, Raskin J-P. "Material and manufacturing process selection for electronics eco-design: Case study on paper-based water quality sensors," in Procedia CIRP , 2020. Ingemarsdotter E, Diener D, Andersson S, Jonasson C, Mellquist A-C, Nyström T, Jamsin E, Balkenende R. Quantifying the Net Environmental Impact of Using IoT to Support Circular Strategies—The Case of Heavy-Duty Truck Tires in Sweden. Circular Econ Sustain. 2021;1(2):613–50. Dekoninck E, Barbaccia F. "Streamlined Assessment to Assist in the Design of Internet-of-Things (IOT) Enabled Products: A Case Study of the Smart Fridge," in Proceedings of the Design Society: International Conference on Engineering Design , 2019. Sarkar S, Chatterjee S, Misra S. Assessment of the Suitability of Fog Computing in the Context of Internet of Things. IEEE Trans Cloud Comput. 2018;6(1):46–59. Manz O, Meyer S, Baumgartner C. "Life cycle assessment of an Internet of Things product: Environmental impact of an intelligent smoke detector," in IoT '21: 11th International Conference on the Internet of Things , 2021. Arshad R, Zahoor S, Shah MA, Wahid A, Yu H. Green IoT: An Investigation on Energy Saving Practices for 2020 and Beyond. IEEE Access. 2017;5:15667–81. Huang J, Meng Y, Gong X, Liu Y, Duan Q. A Novel Deployment Scheme for Green Internet of Things. IEEE Internet of Things Journal. 2014;1(2):196–205. Gurova O, Merritt TR, Papachristos E, Vaajakari J. "Sustainable Solutions for Wearable Technologies: Mapping the Product Development Life Cycle," Sustainability , vol. 12, no. 20, p. 8444, 2020. Zhu C, Leung VCM, Shu L, Ngai EC-H. Green Internet of Things for Smart World. IEEE Access. 2015;3:2151–62. Middendorf A, Deyter S, Gausemeier J, Nissen NF, Reichl H. "Integration of reliability and environmental aspects in early design stages of mechatronics," in 2009 IEEE International Symposium on Sustainable Systems and Technology (ISSST) , 2009. Morin E, Maman M, Guizzetti R, Duda A. Comparison of the Device Lifetime in Wireless Networks for the Internet of Things. IEEE Access. 2017;5:7097–114. Solem "LR-. IP-FL Irrigation controller for large spaces and water flow monitoring," [Online]. Available: https://solem-irrigation.com/en/product/lr-ip-fl-longue-portee-800m/ . [Accessed 31 07 2023]. Meters B. "Pulse Output IWM-PL3," [Online]. Available: https://www.bmeters.com/en/products/iwm-pl3/ . [Accessed 31 07 2023]. Solem "LR-. MB-10 LoRa™/Wi-Fi connected gateway," [Online]. Available: https://solem-irrigation.com/en/product/lr-mb-10-pilotable-a-distance/ . [Accessed 31 07 2023]. Microchip. "Low-Power Long range LoRa Technology Transceiver Module," [Online]. Available: http://ww1.microchip.com/downloads/en/DeviceDoc/RN2483-Low-Power-Long-Range-LoRa-Technology-Transceiver-Module-Data-Sheet-DS50002346D.pdf . [Accessed 31 07 2023]. Laboratoire de, Moirans. "BLEMOD BLE Solem Module," [Online]. Available: https://fccid.io/YWW-BLEMOD/Internal-Photos/Internal-Photos-3795789 . [Accessed 31 07 2023]. Espressif. "ESP-WROOM-S2 WiFi/WLAN module," [Online]. Available: https://www.espressif.com/en/producttype/esp-wroom-s2 . [Accessed 31 07 2023]. Hanes D, Salgueiro G, Grossetete P, Barton R, Henry J. IoT fundamentals: networking technologies, protocols, and use cases for the Internet of things. Cisco Press; 2017. Malmodin J, Lundén D, Moberg Ã, Andersson G, Nilsson M. Life Cycle Assessment of ICT: Carbon Footprint and Operational Electricity Use from the Operator, National, and Subscriber Perspective in Sweden. J Ind Ecol. 2014;18(6):829–45. Krug L, Shackleton M, Saffre F. "Understanding the Environmental Costs of Fixed Line Networking," in Proceedings of the 5th International Conference on Future Energy Systems , 2014. Andrae A, Edler T. "On Global Electricity Usage of Communication Technology: Trends to 2030," Challenges , vol. 6, no. 1, pp. 117–157, 2015. Perrucci GP, Fitzek FHP, Widmer J. "Survey on Energy Consumption Entities on the Smartphone Platform," in 2011 IEEE Vehicular Technology Conference (VTC 2011-Spring) , 2011. Robyns P, Quax P, Lamotte W, Thenaers W. gr-lora: An efficient LoRa decoder for GNU Radio , Zenodo ed., vol. 10, 2017, p. 5281. Sanders C. Practical packet analysis: Using Wireshark to solve real-world network problems. No Starch Press; 2017. Coroama VC, Schien D, Preist C, Hilty LM. "The Energy Intensity of the Internet: Home and Access Networks," in ICT Innovations for Sustainability , 2015, pp. 137–155. Quisbert-Trujillo E, Ernst T, Samuel KE, Monnier E, Gallardo M. "A methodology for supporting the sustainable future and eco design of the Internet of Things," in Oral presentation at the International Conference on Sustainable Technology and Development , Shenzhen, China, 2021. Aslan J, Mayers K, Koomey JG, France C. Electricity Intensity of Internet Data Transmission: Untangling the Estimates: Electricity Intensity of Data Transmission. J Ind Ecol. 2018;22(4):785–98. International Telecommunication Union., "Requirements of the network for the Internet of things," [Online]. Available: https://www.itu.int/rec/T-REC-Y.4113/en . [Accessed 31 07 2023]. Footnotes According to Aslan, J. et al [47] and to the network architecture for IoT systems proposed by the ITU-T Y.4113 recommendation [48], the IAP device belongs to the cloud layer because it interconnects the local devices with Internet Service Providers (ISPs) and internet core networks. The detailed calculations to obtain the number of batteries, as is defined in equation one, as well as the respective environmental impact are available on the section 1 of the Supplementary Information. For more details about the data volume generated in the regular and consultation operational modes of the edge and cloud equipement, the respective reference flows and the associated impact, the reader can consult the section 2 of the supplementary material. For more details about the estimated reference flow and the associated impact of the smartphone, the reader can consult the section 3 of the Supplementary Information. Additional Declarations No competing interests reported. Supplementary Files AnapproachforintegralLifecycleassessmentandeffectiveecodesignofIoTsystemsAnnexesFinal.docx Cite Share Download PDF Status: Published Journal Publication published 20 Nov, 2023 Read the published version in Discover Internet of Things → Version 1 posted Editorial decision: Major revision 15 Oct, 2023 Reviews received at journal 25 Sep, 2023 Reviewers agreed at journal 18 Sep, 2023 Reviewers invited by journal 14 Sep, 2023 Editor assigned by journal 24 Aug, 2023 Submission checks completed at journal 24 Aug, 2023 First submitted to journal 09 Aug, 2023 You are reading this latest preprint version Research Square lets you share your work early, gain feedback from the community, and start making changes to your manuscript prior to peer review in a journal. As a division of Research Square Company, we’re committed to making research communication faster, fairer, and more useful. We do this by developing innovative software and high quality services for the global research community. Our growing team is made up of researchers and industry professionals working together to solve the most critical problems facing scientific publishing. Also discoverable on Platform About Our Team In Review Editorial Policies Advisory Board Help Center Resources Author Services Accessibility API Access RSS feed Manage Cookie Preferences © Research Square 2026 | ISSN 2693-5015 (online) Privacy Policy Terms of Service Do Not Sell My Personal Information {"props":{"pageProps":{"initialData":{"identity":"rs-3247380","acceptedTermsAndConditions":true,"allowDirectSubmit":false,"archivedVersions":[],"articleType":"Case Report","associatedPublications":[],"authors":[{"id":228587356,"identity":"0cc1e84a-5e2f-4d05-a456-45ba4ceb08d9","order_by":0,"name":"Ernesto Quisbert-Trujillo","email":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAZAAAAAyAQMAAABI0h/eAAAABlBMVEX///8AAABVwtN+AAAACXBIWXMAAA7EAAAOxAGVKw4bAAABdklEQVRIie3SMWvCQBQH8BcOkuXFrBci+hVSBHUI+FVOAuki1uLSoUhAyGQ7V/pFHFMCulzXYhGKIrSrkkWhLT0v0aTtFyg0f0juknc/7h0JQJEifzuKT05zajfLoPlyzkriForLyK9mGaGgSkIRMEyKakpM/ycByIgYESjLCGTEsB4fVvudA6W5O4x7Vy8DqN680maPomG+PW22E6erar4SXU6ANqQxb7tuDZkH5rwdWHe8L3bR6vTQmHnf6Y/H3OurosNozIGWZac2x7oFLAJbEKIHjLamqiqJvei44k3UDujFJtIDGFDZWItjY79LyDDWP5nY5UieuUs+DqS6hAOhCbER64AJ8S3dz5O5FhFF7gJ5QjnWLPQ8NPlKnGXKTF/1SFOeZdQhyk1wOAsThNOUGCM82+4cp1Kana/j3jUzgEyVBX13KoY2W8M+cLqGFpJYnzgpOQYhzD2RpIh2/t/4DiD9vqf6Rg7aMk9+iSJFihT5L/kCk6V7xn87StwAAAAASUVORK5CYII=","orcid":"","institution":"* G-SCOP, Univ. Grenoble Alpes - Grenoble INP","correspondingAuthor":true,"prefix":"","firstName":"Ernesto","middleName":"","lastName":"Quisbert-Trujillo","suffix":""},{"id":228587357,"identity":"82a1767a-4e0f-4c72-b4ed-dcdf31037a7f","order_by":1,"name":"Panagiota Morfouli","email":"","orcid":"","institution":"IMEP-LAHC, Univ. Grenoble Alpes - Grenoble INP PHELMA","correspondingAuthor":false,"prefix":"","firstName":"Panagiota","middleName":"","lastName":"Morfouli","suffix":""}],"badges":[],"createdAt":"2023-08-09 04:44:15","currentVersionCode":1,"declarations":"","doi":"10.21203/rs.3.rs-3247380/v1","doiUrl":"https://doi.org/10.21203/rs.3.rs-3247380/v1","draftVersion":[],"editorialEvents":[{"content":"https://doi.org/10.1007/s43926-023-00051-4","type":"published","date":"2023-11-20T15:01:25+00:00"}],"editorialNote":"","failedWorkflow":false,"files":[{"id":42307429,"identity":"c90a97c3-9ca7-4a2f-98ae-4bdc1dc7bb60","added_by":"auto","created_at":"2023-08-29 14:07:32","extension":"png","order_by":1,"title":"Figure 1","display":"","copyAsset":false,"role":"figure","size":192949,"visible":true,"origin":"","legend":"\u003cp\u003eProposed framework for comprehensive impact estimation and effective eco design of IoT Systems [11]\u003c/p\u003e","description":"","filename":"1.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/a88b7b18bc6538865f78fc7d.png"},{"id":42309733,"identity":"017dbc1e-b668-4f36-9b7c-715be6c6da35","added_by":"auto","created_at":"2023-08-29 14:23:32","extension":"png","order_by":2,"title":"Figure 2","display":"","copyAsset":false,"role":"figure","size":387243,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003ea\u003c/strong\u003e The induction emitter; \u003cstrong\u003eb\u003c/strong\u003e front side of its electronic card\u003c/p\u003e","description":"","filename":"2.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/b228499135a0673e35834f14.png"},{"id":42307430,"identity":"9b0a6c9c-b144-45a1-9d14-72d8a2f7a334","added_by":"auto","created_at":"2023-08-29 14:07:32","extension":"png","order_by":3,"title":"Figure 3","display":"","copyAsset":false,"role":"figure","size":598003,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003ea\u003c/strong\u003e The sensor system; \u003cstrong\u003eb\u003c/strong\u003e front side of its electronic card\u003c/p\u003e","description":"","filename":"3.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/0bde48891b84843c6c4e1952.png"},{"id":42307436,"identity":"eed10f28-21fc-4412-8fb2-79794abd26b5","added_by":"auto","created_at":"2023-08-29 14:07:33","extension":"png","order_by":4,"title":"Figure 4","display":"","copyAsset":false,"role":"figure","size":778275,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003ea\u003c/strong\u003e The front side of the electronic card of the gateway; \u003cstrong\u003eb\u003c/strong\u003e its back side\u003c/p\u003e","description":"","filename":"4.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/1bed60d57a8e20ebb18b9d22.png"},{"id":42308724,"identity":"402c2a6b-ed74-4f07-bfaa-5498f772b8cb","added_by":"auto","created_at":"2023-08-29 14:15:33","extension":"png","order_by":5,"title":"Figure 5","display":"","copyAsset":false,"role":"figure","size":139833,"visible":true,"origin":"","legend":"\u003cp\u003eBasic deployment of the IoT system\u003c/p\u003e","description":"","filename":"5.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/4ca4475623b51a3eda9c17d7.png"},{"id":42307441,"identity":"3a5379bd-ca17-4a58-9329-38b7592e444c","added_by":"auto","created_at":"2023-08-29 14:07:35","extension":"png","order_by":6,"title":"Figure 6","display":"","copyAsset":false,"role":"figure","size":306205,"visible":true,"origin":"","legend":"\u003cp\u003eImplementation of a cross-typed lifecycle model for the case study (focused on its use phase)\u003c/p\u003e","description":"","filename":"6.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/9ea7787530b2097760f68312.png"},{"id":42310986,"identity":"5594166b-38cf-49e2-9d38-0b8ce5e1ed7c","added_by":"auto","created_at":"2023-08-29 14:31:32","extension":"png","order_by":7,"title":"Figure 7","display":"","copyAsset":false,"role":"figure","size":89194,"visible":true,"origin":"","legend":"\u003cp\u003eEnergy consumption pattern of the LoRa module of the flowmeter based on its current consumption (no scale)\u003c/p\u003e","description":"","filename":"7.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/83bf2e19cfa99d1499b99145.png"},{"id":42308722,"identity":"5dca304d-36c7-40c6-9d58-ea79ab7b788a","added_by":"auto","created_at":"2023-08-29 14:15:33","extension":"png","order_by":8,"title":"Figure 8","display":"","copyAsset":false,"role":"figure","size":177418,"visible":true,"origin":"","legend":"\u003cp\u003eExperimental deployment of the IoT system for the packet traffic analysis\u003c/p\u003e","description":"","filename":"8.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/7ec724f0760e2fdc578492bc.png"},{"id":42307432,"identity":"33f6ac91-88da-498f-82e7-e2f85c65b2f5","added_by":"auto","created_at":"2023-08-29 14:07:32","extension":"png","order_by":9,"title":"Figure 9","display":"","copyAsset":false,"role":"figure","size":82730,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003ea\u003c/strong\u003e Packet traffic share in the regular operational mode of the case study; \u003cstrong\u003eb\u003c/strong\u003e in the consultation operational mode\u003c/p\u003e","description":"","filename":"9.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/6741d020f9247275ec77bfa5.png"},{"id":42308720,"identity":"fa8bab99-5366-4c09-a972-ef2137384ca9","added_by":"auto","created_at":"2023-08-29 14:15:32","extension":"png","order_by":10,"title":"Figure 10","display":"","copyAsset":false,"role":"figure","size":71874,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003ea\u003c/strong\u003e Impact contributors calculated from the theoretical estimation of the reference flow of the case study; \u003cstrong\u003eb\u003c/strong\u003e from the empirical estimation\u003c/p\u003e","description":"","filename":"10.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/bad76f3a7c54567f580cf9df.png"},{"id":42307439,"identity":"db0c5196-bd4b-4422-b2d1-776804c52889","added_by":"auto","created_at":"2023-08-29 14:07:33","extension":"png","order_by":11,"title":"Figure 11","display":"","copyAsset":false,"role":"figure","size":68952,"visible":true,"origin":"","legend":"\u003cp\u003e\u003cstrong\u003ea\u003c/strong\u003e Coverage shortcomings (shaded zones) of one gateway in an area of 2,56 Km\u003csup\u003e2\u003c/sup\u003e according to the manufacturer (scale 1:75000); \u003cstrong\u003eb\u003c/strong\u003e recommended network deployments according to manufacturer (scale 1:150000)\u003c/p\u003e","description":"","filename":"11.png","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/b54eb977ae8ad4b1641628a3.png"},{"id":47146546,"identity":"3f112373-14c2-433e-ae3c-a6356c1e460c","added_by":"auto","created_at":"2023-11-27 15:08:36","extension":"pdf","order_by":0,"title":"","display":"","copyAsset":false,"role":"manuscript-pdf","size":4036441,"visible":true,"origin":"","legend":"","description":"","filename":"manuscript.pdf","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/9d11c1af-b690-4406-bace-d511aa09000c.pdf"},{"id":42309734,"identity":"19e65783-66cf-40ca-8e7e-bfa07c6ce0e5","added_by":"auto","created_at":"2023-08-29 14:23:33","extension":"docx","order_by":1,"title":"","display":"","copyAsset":false,"role":"supplement","size":870343,"visible":true,"origin":"","legend":"","description":"","filename":"AnapproachforintegralLifecycleassessmentandeffectiveecodesignofIoTsystemsAnnexesFinal.docx","url":"https://assets-eu.researchsquare.com/files/rs-3247380/v1/0f7cea9a60a96b659336c096.docx"}],"financialInterests":"No competing interests reported.","formattedTitle":"An approach for comprehensive Life Cycle Assessment and effective eco design of IoT systems: data-driven modeling of reference flows","fulltext":[{"header":"1. Introduction","content":"\u003cp\u003eIn 2020, it was said that the number of sensor devices exceeded the global Information and Communication Technology (ICT) fleet by an approximate factor of 1,2 [\u003cspan citationid=\"CR1\" class=\"CitationRef\"\u003e1\u003c/span\u003e], and by the end of 2023, it is expected 1,8 IoT-based connections on internet for each member of the global population [\u003cspan citationid=\"CR2\" class=\"CitationRef\"\u003e2\u003c/span\u003e]. As similar estimates project a steady, or even an exponential growth of connected devices; researchers have started to wonder what the ecological cost of using IoT systems will be.\u003c/p\u003e \u003cp\u003eThe advancements in transistor scaling and energy efficient systems over the last decades allow imagining optimistic scenarios. For example, recent projections show that the operational energy footprint share of specialized electronic components inside IoT devices will decrease to an insignificant level of 0,01% by the end of 2025 [\u003cspan citationid=\"CR3\" class=\"CitationRef\"\u003e3\u003c/span\u003e]; and estimations report a low increase of only 6% in total electricity consumption of data centers in a period of 8 years [\u003cspan citationid=\"CR4\" class=\"CitationRef\"\u003e4\u003c/span\u003e].\u003c/p\u003e \u003cp\u003eHowever, as more scientists foresee the limits of our technologies and embrace progressively a new beginning [\u003cspan citationid=\"CR5\" class=\"CitationRef\"\u003e5\u003c/span\u003e, \u003cspan citationid=\"CR6\" class=\"CitationRef\"\u003e6\u003c/span\u003e] \u0026mdash;clearly steeped in massive data and pervasive computing, authors become more prudent with their projections. For instance, Koot, M., \u0026amp; Wijnhoven, F. [\u003cspan citationid=\"CR7\" class=\"CitationRef\"\u003e7\u003c/span\u003e] explain that the required electricity to power data centers only for industrial IoT in 2030 could amount to 364 TWh (considering an endless transistor scaling); but they also clarify that it could go up to 752 TWh, considering a progressive decay of the Law of Moore.\u003c/p\u003e \u003cp\u003eOn the other hand, although it has been already alerted a continuous growth of data centers and communication networks due to the booming of IoT [\u003cspan citationid=\"CR8\" class=\"CitationRef\"\u003e8\u003c/span\u003e], and recommended the correct dimensioning of sensor data [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e]; little is said about these aspects in environmental assessments and eco design literature. We believe that one of the possible reasons that could explain this disregard is that, in general, reference flows of IoT systems tends to be modeled exclusively on the basis of energy and local equipment.\u003c/p\u003e \u003cp\u003eAccording to the environmental management standard ISO 14040, the reference flow is the quantity of material, energy, or even additional subproducts and supplies needed to fulfill a functional unit as it is expressed [\u003cspan citationid=\"CR10\" class=\"CitationRef\"\u003e10\u003c/span\u003e]. As the basic functional unit of IoT systems is providing meaningful information to humans and/or machines in an autonomous way, an IoT system may have different environmental impacts from different reference flows (e.g., different sensor systems, edge devices, mutualized infrastructures or even different supplies, energy sources and consumption patterns), depending on the unique way by which it collects and transforms raw data, and sends information.\u003c/p\u003e \u003cp\u003eThis work develops this approach to highlight its relevance for impact estimation and eco design of the Internet of Things. It extends an initial design standpoint outlined in [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e], and it has the following structure. section 2 presents the related work that help to understand our posture, and recalls our previous framework, which will be later implemented in section 3. Section 3 presents our case study, and the theoretical and empirical estimations of its reference flow and environmental impact from a cross-typed lifecycle model. Section 4 presents a discussion on our results in the context of impact assessment and eco design, and offers concrete guidelines for sustainable IoT systems. Section 5 concludes this work by summarizing our main findings and mentioning our parallel work in progress.\u003c/p\u003e"},{"header":"2. Related work","content":"\u003cp\u003eIn the last years, more attention has been putted on measuring the impact of partial [\u003cspan additionalcitationids=\"CR13 CR14 CR15 CR16 CR17 CR18 CR19 CR20\" citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR21\" class=\"CitationRef\"\u003e21\u003c/span\u003e] or full IoT systems [\u003cspan citationid=\"CR7\" class=\"CitationRef\"\u003e7\u003c/span\u003e, \u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e, \u003cspan additionalcitationids=\"CR23 CR24\" citationid=\"CR22\" class=\"CitationRef\"\u003e22\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR25\" class=\"CitationRef\"\u003e25\u003c/span\u003e]; and recently, on mitigating this impact in a methodologic way [\u003cspan citationid=\"CR12\" class=\"CitationRef\"\u003e12\u003c/span\u003e, \u003cspan citationid=\"CR15\" class=\"CitationRef\"\u003e15\u003c/span\u003e, \u003cspan additionalcitationids=\"CR27 CR28 CR29\" citationid=\"CR26\" class=\"CitationRef\"\u003e26\u003c/span\u003e\u0026ndash;\u003cspan citationid=\"CR30\" class=\"CitationRef\"\u003e30\u003c/span\u003e]. From this body of literature, Lelah, A. et al. [\u003cspan citationid=\"CR9\" class=\"CitationRef\"\u003e9\u003c/span\u003e] show that an increase in the circulation of data between sensors nodes and gateways (from a daily to an hourly transmission frequency) provokes significant modifications on the reference flow of local equipment (i.e.; scaling up photovoltaic cells, accumulators and batteries). K\u0026ouml;hler, A. R. et al. [\u003cspan citationid=\"CR14\" class=\"CitationRef\"\u003e14\u003c/span\u003e] demonstrated for their part, that a reduction of the sensing spatial resolution of a textile-based sensor network decreases its reference flow per square meter in both sensor modules and energy consumption. What is more, they showed that more than 98% of power dissipation can be avoid only by switching off radio receivers, putting microcontrollers (MCUs) in sleep mode (when possible) and reducing the sampling rate of sensors from 10Hz to 2Hz (sticking the data resolution to the strict necessary).\u003c/p\u003e \u003cp\u003eDimensioning correctly sensor data is crucial for sober design, but other related aspects, such as determining how information is transmitted are fundamental too. In their study in eco design of wireless sensor networks, Bonvoisin, J. et al [\u003cspan citationid=\"CR15\" class=\"CitationRef\"\u003e15\u003c/span\u003e] show that lowing the hearing sensibility of sensor nodes to the strict necessary (by adjusting the probability of successful reception of messages to 95%) provokes a reduction of 10% on their energy needs, but also provokes more replacements of edge devices (embedded, battery-powered repeaters), because they spend more energy to maintain poorer communication links. This later drawback highlights two important aspects for impact estimation and eco design. Firstly, it uncovers the distinction between the physical and abstract definitions of sensor devices in a network (clearly stablished by the authors), and secondly, it introduces our posture, which says that modeling of reference flows must happen in a comprehensive way and on the basis of data flow, as Fig.\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e1\u003c/span\u003e suggest (that is, by considering data, that flows through different devices (D) and electronic components (C), which execute specific functions with defined capacities (FC)).\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eWe believe that this is capital for accurate impact estimation and effective eco design of IoT systems. Indeed, Morin, E. et al. [\u003cspan citationid=\"CR31\" class=\"CitationRef\"\u003e31\u003c/span\u003e] have already suggested that the lifetime of IoT devices \u0026mdash;in terms of the depletion rate of batteries, is drastically conditioned not only by the energy required in transmission and receiving functions, but also by a combination of additional factors linked to data manipulation and quality, including the data size required by the application, the data rate, and even the distance range at which wireless components operate in relation to other devices.\u003c/p\u003e \u003cp\u003eIn order to illustrate our approach and demonstrate its relevance in the context of IoT systems, the next section estimates theoretically and empirically the reference flow and the environmental impact of a case study from an analysis of its inner data flow, by implementing our proposed framework in a cross-typed lifecycle model.\u003c/p\u003e"},{"header":"3. Case study","content":"\u003cp\u003eOur case study consists on an IoT system oriented to track water consumption in domestic environments. Its local infrastructure is composed of a sensor system [\u003cspan citationid=\"CR32\" class=\"CitationRef\"\u003e32\u003c/span\u003e] equipped with an induction emitter [\u003cspan citationid=\"CR33\" class=\"CitationRef\"\u003e33\u003c/span\u003e]; and a Long Range (LoRa)-Internet gateway [\u003cspan citationid=\"CR34\" class=\"CitationRef\"\u003e34\u003c/span\u003e].\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eThe induction emitter (Fig.\u0026nbsp;\u003cspan refid=\"Fig2\" class=\"InternalRef\"\u003e2\u003c/span\u003e) is a separated sensor device powered by one 2/3AA-sized Li-ion battery. It is wired to the sensor system and generates electronic pulses by a bank of low voltage capacitors and inductors found in its electronic card (both in the front and the back side of its electronic card, within red frame in Fig.\u0026nbsp;\u003cspan refid=\"Fig2\" class=\"InternalRef\"\u003e2\u003c/span\u003eb).\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eThe sensor system (Fig.\u0026nbsp;\u003cspan refid=\"Fig3\" class=\"InternalRef\"\u003e3\u003c/span\u003e) is a 9V-battery-powered device that has to be located no more than 30 meters from the induction emitter. It is equipped with a RN2483 LoRa module [\u003cspan citationid=\"CR35\" class=\"CitationRef\"\u003e35\u003c/span\u003e] (the bottom red frame of Fig.\u0026nbsp;\u003cspan refid=\"Fig3\" class=\"InternalRef\"\u003e3\u003c/span\u003eb) and a YWW-BLEMOD Bluetooth module [\u003cspan citationid=\"CR36\" class=\"CitationRef\"\u003e36\u003c/span\u003e] (the top red frame of Fig.\u0026nbsp;\u003cspan refid=\"Fig3\" class=\"InternalRef\"\u003e3\u003c/span\u003eb). Contrary to our preliminary assumptions presented in our previous work [\u003cspan citationid=\"CR11\" class=\"CitationRef\"\u003e11\u003c/span\u003e], its electronic card lacks of MCU and memory components. Because of that, it is believed that the device uses at least the embedded microprocessor of the System-on-Chip (SoC) subcomponent of its LoRa module to manage processing and transmissions tasks; and at least its embedded memory, to keep transitory data and metering configuration settings.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eThe gateway (Fig.\u0026nbsp;\u003cspan refid=\"Fig4\" class=\"InternalRef\"\u003e4\u003c/span\u003e) is a device powered by the electric grid and plays the role of an edge device of the IoT system. It is equipped with the same LoRa and Bluetooth modules of the sensor system (Fig.\u0026nbsp;\u003cspan refid=\"Fig4\" class=\"InternalRef\"\u003e4\u003c/span\u003ea); a WiFi ESP8266EX module [\u003cspan citationid=\"CR37\" class=\"CitationRef\"\u003e37\u003c/span\u003e] (left red frame in Fig.\u0026nbsp;\u003cspan refid=\"Fig4\" class=\"InternalRef\"\u003e4\u003c/span\u003eb), an ARM Microcontroller and a Flash memory (right red frames in Fig.\u0026nbsp;\u003cspan refid=\"Fig4\" class=\"InternalRef\"\u003e4\u003c/span\u003eb). According to the manufacturer, this device must be placed to no more than 800 meters from the sensor system.\u003c/p\u003e \u003cp\u003eThe most basic functioning of the IoT system is shown in Fig.\u0026nbsp;\u003cspan refid=\"Fig5\" class=\"InternalRef\"\u003e5\u003c/span\u003e below (illustrated in terms of our proposed framework recalled in Fig.\u0026nbsp;\u003cspan refid=\"Fig1\" class=\"InternalRef\"\u003e1\u003c/span\u003e).\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eThe induction emitter is attached to a conventional jet meter and sends electronic pulses to the sensor system whenever the spinning disk of the jet meter indicates water consumption. In this sense, the sensor system plays the role of a flowmeter, tracking the pulses generated by the induction emitter. Periodically, the flowmeter communicates with the gateway wirelessly using LoRa technology. For its part, the gateway communicates with the cloud server through an Internet Access Point (IAP) device (e.g., an internet modem) by its WiFi module.\u003c/p\u003e \u003cp\u003eOn the other hand, a smartphone can stablish Bluetooth connections with the flowmeter and the gateway to either set/modify their initial configurations (e.g., security settings or sampling rate accuracy) or consult water consumption locally (consultations and metering configuration changes can be also held online, at mySolem.com).\u003c/p\u003e \u003cp\u003eThe flowmeter transforms the tracked pulses (raw data) into information (count of pulses), and send this information to the gateway every 3 minutes (according to technical documentation). Because the flowmeter records the counts every 15 minutes (as declared by the manufacturer), it is believed that the gateway accumulates the periodic LoRa packets transmitted by the flowmeter and update the cloud server every 15 minutes, to keep synchronized the water consumption statistics on the local and the cloud equipment.\u003c/p\u003e \u003cp\u003eBearing in mind all these aspects and based on technical documentation, Fig.\u0026nbsp;\u003cspan refid=\"Fig6\" class=\"InternalRef\"\u003e6\u003c/span\u003e presents a customized implementation of our framework, which is oriented to estimate the data flow within the IoT system of our case study starting from the maximal capacities of key components, and from that, the reference flow and impact of its use phase in the long term, assuming an unfavorable data flow scenario. The Functional unit that leads this analysis is defined as \u0026ldquo;facilitating the hourly monitoring of water consumption of an area of 1 km\u003csup\u003e2\u003c/sup\u003e, during 2 years\u0026rdquo;. For obtaining the embodied global warming damage, environmental data from the CML-IA 2001 Life Cycle Impact Assessment (LCIA) method was used.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eBecause this work is focused on the use phase of our case study, the implementation presents all the physical elements that allows the functioning of the local equipment (i.e.; the dotted elements) but their respective manufacturing and disposal life cycle phases are not taken into account. Also, notice that a battery can be seen as a component itself (power unit) and, at the same time, as a part of the reference flow (whose number vary according to the operational context of the system).\u003c/p\u003e \u003cp\u003eDouble-sensed red arrows in Fig.\u0026nbsp;\u003cspan refid=\"Fig6\" class=\"InternalRef\"\u003e6\u003c/span\u003e indicate data application flow or additional traffic related to internet protocol mechanisms. We assume the IAP device as an element of the internet infrastructure (access network)\u003ca class=\"FNLink\" href=\"#Fn1\" id=\"#FNLinkFn1\"\u003e\u003c/a\u003e.\u003c/p\u003e \u003cp\u003eTo define the maximal capacities of the system and establish an unfavorable data flow scenario for our analysis, in this work we focus on some features of the LoRa technology. LoRa is a modulation technique optimized for long-range, low-power-consumption communications in IoT environments [\u003cspan citationid=\"CR38\" class=\"CitationRef\"\u003e38\u003c/span\u003e]. In order to cover long distances and keep high Quality of Service (QoS), LoRa uses an Adaptive Datarate Routine (ADR) that regulates the bitrate at which data is encoded in a determined bandwidth, according to a Spreading Factor (SF). The spreading factor is a parameter that determines the number of bits transmitted per LoRa symbol and it is inversely proportional to the bitrate.\u003c/p\u003e \u003cp\u003eWhen the distance range between two devices increases, the established link in LoRa communications degrades. To assure quality in transmissions, the ADR mechanism regulates the spreading factor to high values, which lowers the data encoded per second (the bitrate reduces), extends the time-on-air of a data sequence and consequently, prolongs the transmission states of transceivers.\u003c/p\u003e \u003cp\u003eTable\u0026nbsp;\u003cspan refid=\"Tab1\" class=\"InternalRef\"\u003e1\u003c/span\u003e gives the optimal data application size (data payload) that a LoRa packet can carry efficiently in different bandwidths and distance ranges, according to given Spreading Factors (the affected bitrates are also showed).\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab1\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 1\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eData application size (payload) that a LoRa packet can carry according to different parameters\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"5\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c5\" colnum=\"5\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSpreading\u003c/p\u003e \u003cp\u003efactor\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eBandwidth\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003eData application (payload)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c4\"\u003e \u003cp\u003eBitrate\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c5\"\u003e \u003cp\u003eRange\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSF12\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e125 kHz\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e51 Bytes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e290 bps\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e14 km\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSF11\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e125 kHz\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e51 Bytes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e440 bps\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e11 km\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSF10\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e125 kHz\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e51 Bytes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e980 bps\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e8 km\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSF9\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e125 kHz\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e115 Bytes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e1760 bps\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e6 km\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSF8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e125 kHz\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e242 Bytes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e3125 bps\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e4 km\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eSF7\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e125 kHz\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e242 Bytes\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e5470 bps\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e2 km\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eIn this sense, to construct an unfavorable data flow scenario for the analysis, we assume that the data application size of the case study is equal to the maximal data payload allowed within a bandwidth of 125 kHz and a spreading factor of 7 (242 Bytes). This corresponds to a distance range of 2 Km, which is close to the maximal distance range recommended by the manufacturer (800 meters). We also assume that any data reduction task is applied on the gateway (the accumulated counts are simple resent to the cloud server).\u003c/p\u003e \u003cdiv id=\"Sec4\" class=\"Section2\"\u003e \u003ch2\u003e3.1. Theoretical estimations\u003c/h2\u003e \u003cp\u003eThis section models the reference flow of the case study under the unfavorable data flow scenario suggested above, and based on available information. The sampling rate of the induction emitter is assumed to 10 pulses per second. Under this configuration, the lifetime of its battery is approximately 10 years (according to the manufacturer). Consequently, the reference flow of using this device in normal conditions for two years (as is defined by the functional unit) is only one battery, and its associated impact is 3,82 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e Kg CO\u003csub\u003e2\u003c/sub\u003e-eq.\u0026nbsp;This damage corresponds to the impact of producing a single Li-ion battery of one-dry-cell that weights 5,65 grams.\u003c/p\u003e \u003cp\u003eOn the other hand, the reference flow of the flowmeter (in terms of the number of batteries (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({B}_{fm}\\)\u003c/span\u003e\u003c/span\u003e) required during two years) is given by the following equation.\u003cdiv id=\"Equ1\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equ1\" name=\"EquationSource\"\u003e\n$${B}_{fm}=TT{E}_{LoRa}\\left({BD}_{{T}_{x}}\\times {t}_{{T}_{x}}+{BD}_{s} \\times {t}_{s}\\right)$$\u003c/div\u003e\u003cdiv class=\"EquationNumber\"\u003e1\u003c/div\u003e\u003c/div\u003e\u003c/p\u003e \u003cp\u003eWhere,\u003cdiv id=\"Equa\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equa\" name=\"EquationSource\"\u003e\n$$TT{E}_{LoRa}= Total LoRa Transmission Events in two years \\left(350333\\right)$$\u003c/div\u003e\u003c/div\u003e\u003cdiv id=\"Equb\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equb\" name=\"EquationSource\"\u003e\n$${t}_{{T}_{x}}=Time elapsed in transmission state during a LoRa trans. event$$\u003c/div\u003e\u003c/div\u003e\u003cdiv id=\"Equc\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equc\" name=\"EquationSource\"\u003e\n$${t}_{s}= Time elapsed in sleeping state during a LoRa trans. event$$\u003c/div\u003e\u003c/div\u003e\u003cdiv id=\"Equd\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equd\" name=\"EquationSource\"\u003e\n$${BD}_{{T}_{x}}=Battery Depletion factor trans. mode \\left(1 battery per \\text{25,6} hours\\right)$$\u003c/div\u003e\u003c/div\u003e\u003cdiv id=\"Eque\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Eque\" name=\"EquationSource\"\u003e\n$${BD}_{s}= Battery Depletion factor sleep mode \\left(1 battery per 712500 hours\\right)$$\u003c/div\u003e\u003c/div\u003e\u003c/p\u003e \u003cp\u003eBelow, we present the main assumptions and calculations to obtain every component of Eq.\u0026nbsp;\u003cspan refid=\"Equ1\" class=\"InternalRef\"\u003e1\u003c/span\u003e.\u003c/p\u003e \u003cp\u003eFirstly, we assumed that the energy consumption for simply counting the electrical pulses depends on the current consumption of the sleep mode, and the time elapsed in this state (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({t}_{s}\\)\u003c/span\u003e\u003c/span\u003e); and for transmitting the counts, on the current consumption of the transmitting mode, and the time elapsed in this state (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({t}_{{T}_{x}}\\)\u003c/span\u003e\u003c/span\u003e), as showed in Fig.\u0026nbsp;\u003cspan refid=\"Fig7\" class=\"InternalRef\"\u003e7\u003c/span\u003e.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eSecondly, the time elapsed in the transmission state in a LoRa transmission event is the quotient between the final size of a LoRa packet (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(P{S}_{LoRa}\\)\u003c/span\u003e\u003c/span\u003e) and the bitrate capacity (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\(B{R}_{SF}\\)\u003c/span\u003e\u003c/span\u003e) of the LoRa module, which is determined by a SF of 7 in a bandwidth of 125 kHz (Eq.\u0026nbsp;\u003cspan refid=\"Equ2\" class=\"InternalRef\"\u003e2\u003c/span\u003e).\u003cdiv id=\"Equ2\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equ2\" name=\"EquationSource\"\u003e\n$${t}_{{T}_{x}}=\\frac{P{S}_{LoRa}}{B{R}_{SF}}$$\u003c/div\u003e\u003cdiv class=\"EquationNumber\"\u003e2\u003c/div\u003e\u003c/div\u003e\u003c/p\u003e \u003cp\u003eWhere,\u003cdiv id=\"Equf\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equf\" name=\"EquationSource\"\u003e\n$$P{S}_{LoRa}= final size of a LoRa packet \\left(2256 bits\\right)$$\u003c/div\u003e\u003c/div\u003e\u003cdiv id=\"Equg\" class=\"Equation\"\u003e\u003cdiv format=\"TEX\" class=\"mathdisplay\" id=\"FileID_Equg\" name=\"EquationSource\"\u003e\n$$B{R}_{SF}= bitrate capacity under a SF7 and a 125kHz bandwidth \\left(5470 bps\\right)$$\u003c/div\u003e\u003c/div\u003e\u003c/p\u003e \u003cp\u003eThirdly, according to technical data and the established unfavorable data flow scenario, we assume that the microprocessor of the flowmeter\u0026rsquo;s LoRa Module collects and counts the electrical pulses generated by the induction emitter during 3 minutes (180 seconds), creating a maximal payload of 242 bytes. To send this data payload, the LoRa module adds to it headers and footers, conforming full LoRa packets of 282 bytes.\u003c/p\u003e \u003cp\u003eThus, by considering this packet size in bits (2256 bits), the time that the LoRa module is in transmission mode (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({t}_{{T}_{x}}\\)\u003c/span\u003e\u003c/span\u003e) in a transmission event is 0,41 secs (or 1,14 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;4\u003c/sup\u003e hours); and in sleeping mode, (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({t}_{s}\\)\u003c/span\u003e\u003c/span\u003e), 179,59 secs (or 4,98 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e hours).\u003c/p\u003e \u003cp\u003eFourthly, if the flowmeter would have to transmit continuously, the Battery Depletion factor for the transmission mode (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({BD}_{{T}_{x}}\\)\u003c/span\u003e\u003c/span\u003e) would be 25,6 hours. This is the quotient between the nominal capacity of a 9V PP3-typed battery (1200 mAh) and the current consumption of the flowmeter\u0026rsquo;s LoRa module in transmission mode (44,5 mA), all multiplied by an output current performance rate of the battery of 95%. Similarly, if the flowmeter would have to sleep continuously, the Battery Depletion factor for sleeping mode (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({BD}_{s}\\)\u003c/span\u003e\u003c/span\u003e) would be 712500 hours (considering the same nominal capacity of the battery and a current consumption of the flowmeter\u0026rsquo;s LoRa module in sleeping mode of 1,6 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;3\u003c/sup\u003e mA).\u003c/p\u003e \u003cp\u003eThus, by considering all these aspects in equation one, and by knowing that the total LoRa transmission events in two years amount to 350333 (one every 3 minutes), the reference flow for the flowmeter is two batteries\u003ca class=\"FNLink\" href=\"#Fn2\" id=\"#FNLinkFn2\"\u003e\u003c/a\u003e. This generates a damage of 0,458 Kg CO\u003csub\u003e2\u003c/sub\u003e-eq, which corresponds to the impact of producing 2 Li-ion 9V pp3-typed batteries of six dry cells that weights 33,9 grams).\u003c/p\u003e \u003cp\u003eRegarding the gateway, it is believed that this device (1) accumulates the LoRa packets generated by the flowmeter during 15 minutes (which generates a data payload of 1410 Bytes), and (2) transmits these data to the cloud server in a Hypertext Transfer Protocol (HTTP) post request (which generates a packet of 1480 bytes). To do all this, the device requires 6 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;3\u003c/sup\u003e kW (according to technical documentation), which means a total electricity consumption of 105,12 kWh during two years. This generates an impact of 5,15 Kg CO\u003csub\u003e2\u003c/sub\u003e-eq, according to the CML-IA LCIA methodology and assuming a French electricity mix.\u003c/p\u003e \u003cp\u003eTo estimate the reference flow and the impact of the cloud layer, we determine the data traffic from the gateway to the cloud server (regular operational mode) and the data traffic from the smartphone to the cloud server (consultation operational mode).\u003c/p\u003e \u003cp\u003eFor the regular operational mode, one considers the total number of transmission events (assumed to one every 15 minutes, during two years), the final packet size of HTTP POST requests (packets of 1480 bytes generated by the Gateway, and addressed to the Cloud server (we call these packets \u0026ldquo;HTTP post GC\u0026rdquo;)), and the additional data generated by the Transmission Control / Internet protocols (TCP/IP) overhead (packets regarding acknowledgements (TCP ack), TCP three-way handshake (\u0026ldquo;TCP ths\u0026rdquo;) and TCP teardown (\u0026ldquo;TCP t\u0026rdquo;) mechanisms). Thus, by considering a total of 70066 transmissions events during two years, the total data traffic flowing between the gateway and the cloud server amount to 0,1331 Gigabytes (GB).\u003c/p\u003e \u003cp\u003eFor the consultation operational mode, one considers the total number of transmission events (one every hour, during two years), the packet size of HTTP GET requests (assumed to one byte each), the packet size of HTTP responses (assumed to one byte each), and the additional data generated by the TCP/IP protocol overhead.\u003c/p\u003e \u003cp\u003eThus, by considering a total of 17520 transmission events during two years, the total traffic flowing from the smartphone to the cloud server amounts to 1,03 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e GB.\u003c/p\u003e \u003cp\u003eFrom this, the reference flow related to the internet networks and cloud server amounts to 2,15 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e kWh and 2,01 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e kWh respectively (assuming an electricity intensity factor of 0,15 kWh/GB for the internet infrastructure, which is a median value between that one proposed by Malmodin, J. et al. [\u003cspan citationid=\"CR39\" class=\"CitationRef\"\u003e39\u003c/span\u003e] and Krug, L. et al. [\u003cspan citationid=\"CR40\" class=\"CitationRef\"\u003e40\u003c/span\u003e]; and an electricity intensity factor of 0,14 kWh/GB for the cloud server infrastructure, as reported by Andrae, A. S., \u0026amp; Edler, T. [\u003cspan citationid=\"CR41\" class=\"CitationRef\"\u003e41\u003c/span\u003e]).\u003c/p\u003e \u003cp\u003eThus, the impact generated by the internet networks amounts to 1,7 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e Kg CO\u003csub\u003e2\u003c/sub\u003e-eq; and the impact generated by the cloud server to 1,6 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e Kg CO\u003csub\u003e2\u003c/sub\u003e-eq (both assuming a global electricity mix and according to the CML-IA LCIA methodology\u003ca class=\"FNLink\" href=\"#Fn3\" id=\"#FNLinkFn3\"\u003e\u003c/a\u003e).\u003c/p\u003e \u003cp\u003eFinally, the estimation of the reference flow from using the smartphone considers only the energy needed for powering its WiFi module in the transmitting and receiving modes (1,62 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;3\u003c/sup\u003e and 1,375 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;3\u003c/sup\u003e kW respectively, according to Perrucci, G.P. et al. [\u003cspan citationid=\"CR42\" class=\"CitationRef\"\u003e42\u003c/span\u003e]), multiplied by the total time that the WiFi module works in two years (292 hours, if one assumes that the user turns on the WiFi function of the phone during one minute to consult his or her water consumption hourly).\u003c/p\u003e \u003cp\u003eThus, the reference flow of the smartphone for sending consultation requests and receiving responses amounts to 0,5 kWh and 0,423 kWh respectively. Both reference flows add up an impact of 4,5 \u0026#128939; 10\u003csup\u003e\u0026minus;\u0026thinsp;2\u003c/sup\u003e Kg CO\u003csub\u003e2\u003c/sub\u003e-eq, which correspond to the impact of charging a smartphone oriented only to the functional unit of this analysis, and by assuming a French electricity mix\u003ca class=\"FNLink\" href=\"#Fn4\" id=\"#FNLinkFn4\"\u003e\u003c/a\u003e.\u003c/p\u003e \u003cp\u003eTable\u0026nbsp;\u003cspan refid=\"Tab2\" class=\"InternalRef\"\u003e2\u003c/span\u003e below offers a summary of all these assumptions and calculations oriented to establish the reference flow of the case study in the use phase, which generates a total impact of 5,7235 Kg CO\u003csub\u003e2\u003c/sub\u003e-eq.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab2\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 2\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eSummary of the electronic components, functions and capacities considered to estimated theoretically the reference flow and the impact of the case study\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"6\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c5\" colnum=\"5\"\u003e\u003c/div\u003e \u003cdiv align=\"char\" char=\".\" class=\"colspec\" colname=\"c6\" colnum=\"6\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e \u003cp\u003eDevice\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e \u003cp\u003eE. Component\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e \u003cp\u003eFunction\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c4\"\u003e \u003cp\u003eCapacity\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c5\"\u003e \u003cp\u003eReference flow\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c6\"\u003e \u003cp\u003eImpact\u003csup\u003ea\u003c/sup\u003e\u003c/p\u003e \u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\" morerows=\"1\" rowspan=\"2\"\u003e \u003cp\u003ePulse meter\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eCap. \u0026amp; Ind.\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eGenerate pulses\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eSampling rate (10 pulses/sec)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\" morerows=\"1\" rowspan=\"2\"\u003e \u003cp\u003e1 Li-ion battery\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\" char=\".\" colname=\"c6\" morerows=\"1\" rowspan=\"2\"\u003e \u003cp\u003e0,038\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eLi-ion battery\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePower supply\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eNominal capacity (1650 mAh)\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\" morerows=\"3\" rowspan=\"4\"\u003e \u003cp\u003eFlowmeter\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eLoRa module\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eCounting pulses\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eCurrent cons. Sleep mode (0,0016 mA)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\" morerows=\"3\" rowspan=\"4\"\u003e \u003cp\u003e2 Li-ion 9V\u003c/p\u003e \u003cp\u003eBatteries\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\" char=\".\" colname=\"c6\" morerows=\"3\" rowspan=\"4\"\u003e \u003cp\u003e0,458\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eLoRa module\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eSending counts\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eBitrate (5470 bps)\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eLoRa module\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eSending counts\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eCurrent cons. Tx mode (44,5 mA)\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eLi-ion 9V battery\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003ePower supply\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eNominal capacity (1200 mAh)\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eGateway\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eLoRa \u0026amp; WiFi mod.\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eRec. Prep. and Resend counts\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003ePower cons. (0,006 kW)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e105,12 kWh\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\" char=\".\" colname=\"c6\"\u003e \u003cp\u003e5,150\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\" morerows=\"1\" rowspan=\"2\"\u003e \u003cp\u003eSmartphone\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eWiFi module\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eHourly consultation\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003ePower cons. Send (1629 mW)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e0,501 kWh\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\" char=\".\" colname=\"c6\" morerows=\"1\" rowspan=\"2\"\u003e \u003cp\u003e0,045\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eWiFi module\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003eHourly consultation\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003ePower cons. Rec. (1375 mW)\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e0,423 kWh\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eInternet Net.\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eElectricity cons. (0,15 kWh/GB)\u003csup\u003eb\u003c/sup\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e0,0215 kWh\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\" char=\".\" colname=\"c6\"\u003e \u003cp\u003e0,017\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003eCloud server\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003eElectricity cons. (0,14 kWh/GB)\u003csup\u003ec\u003c/sup\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e0,020 kWh\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\" char=\".\" colname=\"c6\"\u003e \u003cp\u003e0,016\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e\u0026nbsp;\u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003eTotal\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"char\" char=\".\" colname=\"c6\"\u003e \u003cp\u003e5,723\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003ctfoot\u003e \u003ctr\u003e\u003ctd colspan=\"6\"\u003e\u003csup\u003ea\u003c/sup\u003e Expressed in Kg CO\u003csub\u003e2\u003c/sub\u003e-eq\u003c/td\u003e\u003c/tr\u003e \u003ctr\u003e\u003ctd colspan=\"6\"\u003e\u003csup\u003eb\u003c/sup\u003e Median electricity intensity factor considering the values suggested by Malmodin, J. et al. [\u003cspan citationid=\"CR39\" class=\"CitationRef\"\u003e39\u003c/span\u003e] and Krug, L. et al. [\u003cspan citationid=\"CR40\" class=\"CitationRef\"\u003e40\u003c/span\u003e]\u003c/td\u003e\u003c/tr\u003e \u003ctr\u003e\u003ctd colspan=\"6\"\u003e\u003csup\u003ec\u003c/sup\u003e Electricity intensity factor reported by Andrae, A. S., \u0026amp; Edler, T. [\u003cspan citationid=\"CR41\" class=\"CitationRef\"\u003e41\u003c/span\u003e]\u003c/td\u003e\u003c/tr\u003e \u003c/tfoot\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003c/div\u003e \u003cdiv id=\"Sec5\" class=\"Section2\"\u003e \u003ch2\u003e3.2. Empirical estimations\u003c/h2\u003e \u003cp\u003eThis section models the reference flow of the case study from a data traffic analysis. It was conducted by implanting two network analyzers (sniffers) into the IoT system, according to the experimental deployment presented in Fig.\u0026nbsp;\u003cspan refid=\"Fig8\" class=\"InternalRef\"\u003e8\u003c/span\u003e.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eIn Fig.\u0026nbsp;\u003cspan refid=\"Fig8\" class=\"InternalRef\"\u003e8\u003c/span\u003e, a Wireshark-based sniffer (packet sniffer A) equipped with a RTL2832U-based dongle and GNU-radio companion software (running in a Linux PC) is placed to capture the LoRa packet traffic between the flowmeter and the gateway. A customized GNU-radio companion model based on gr-lora implementation [\u003cspan citationid=\"CR43\" class=\"CitationRef\"\u003e43\u003c/span\u003e] was developed to allow the dongle intercept LoRa transmissions. The second sniffer (packet sniffer B) is a Wireshark-based sniffer using the wireless Network Interface Controller of a desktop Windows PC (in promiscuous mode). It aims to capture and analyze the WiFi traffic of the system. The distance between the flowmeter and the gateway is 4 meters.\u003c/p\u003e \u003cp\u003eThe packet traffic analysis was conducted as follows. The network operated approximately 10 hours (from 11h40 to 22h20). During this period, regular water consumption was emulated by applying compressed air to the jet meter, and hourly consultation were made, by acceding the user\u0026rsquo;s interface in the cloud server via a smartphone equipped with a WiFi module. Sniffer A and B were initialized before starting up the network. To capture the LoRa transmissions, the GNU-Radio companion model considered a spreading factor of 7, a frequency band of 868 MHz hearing in three frequency channels, and a bandwidth of 125kHz. The LoRa transmissions were intercept by the RTL-RDS bundle and transformed into User Datagram Protocol (UDP) packets, which were reoriented to the Wireshark interface by the ports 40868, 40869 and 40870 of sniffer A (one for every frequency channel). In the packet traffic captured and reported by sniffer B, specific Wireshark filters were applied.\u003c/p\u003e \u003cp\u003eFigure A2 in the Supplementary Information shows a sample of the packet traffic between the flowmeter and the gateway captured by the sniffer A (from 21h06 to 22h06). Each point represents the aggregated data size of a LoRa transmission in minute resolution (excluding UDP headers). On it, it can be observed that transmissions occur effectively every 3 minutes (with some exceptions, in which packet loss is assumed) and, besides some outliers, it could be said that the generic size of LoRa packets is 57 Bytes (as it is documented in the section 4 of the Supplementary Information).\u003c/p\u003e \u003cp\u003eBy considering this packet size in equation two, the time elapsed in transmission mode (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({t}_{{T}_{x}}\\)\u003c/span\u003e\u003c/span\u003e) is rather 0,083 secs (and the time that it sleeps (\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({t}_{s}\\)\u003c/span\u003e\u003c/span\u003e) is 179,92 secs). In this sense, the flowmeter requires only one battery to operate during two years (according to equation one). This provokes an impact of 0,229 Kg CO\u003csub\u003e2\u003c/sub\u003e-eq, which corresponds to the impact of producing only one 9V-PP3-typed battery (more details about these results are available in the section 6 of the supplementary material).\u003c/p\u003e \u003cp\u003eWith respect to the data traffic within the internet network and cloud server, figure A3 in the Supplementary Information (section 5) shows a refined sample of the WiFi traffic of the system (for the regular and the consultation operational modes) occurred in approximately two minutes (from 21h58m03s to 21h59m51s). On it, each point represents the aggregated data size of Domain Name System (DNS), TCP and HTTP transmissions occurred in second resolution, and it is observed that, in the regular operational mode, the transmission events between the gateway and the cloud server occur every 18 seconds (contrary to our assumptions stated in the previous section). Moreover, a detailed inspection of the TCP traffic (which is also illustrated in the table A3 of the Supplementary Information) shows that the three-way handshake and the teardown TCP mechanisms generates packets (SYN, SYN/ACK, ACK, FIN or FIN/ACK types indistinctly) with a mean size that range from 54 to 58 bytes (this suggests that the TCP, IP or MAC headers of these packets do not include certain optional fields).\u003c/p\u003e \u003cp\u003eAnother inspection on the HTTP traffic shows that the POST request-typed packets with data application are fixed to 200 Bytes. This suggest that the gateway executes processing tasks oriented to transform the data payload of the incoming LoRa packets into formatted HTTP POST-type packets with constant size addressed to the cloud server. On the other hand, the cloud server generates HTTP timeout-request packets of approximately 468 bytes before starting a TCP teardown routine. A timeout request allows a server announce and close an unused connection, and the continuous presence of this type of request in our case study would suggest that the gateway waits for this request to start a TCP teardown routine. Beside of this, the Intensive HTTP traffic observed in figure A3 (from 21h59m13s to 21h59m31s) during a water consultation request via the cloud server (by acceding the user\u0026rsquo;s dashboard at \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e\u003ca href=\"http://www.mySolem.com\" target=\"_blank\"\u003ewww.mySolem.com\u003c/a\u003e\u003c/span\u003e\u003cspan address=\"http://www.mySolem.com\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e) would suggest extra transmissions stablished between the gateway and the cloud server, in which the server asks the gateway for additional data (data that probably differs from counts). This generates high volumes of data that seems to be fragmented on packets (7 approximately) of less than 800 Bytes (as it is documented in table A3 of the supplementary material).\u003c/p\u003e \u003cp\u003eFinally, in the packets traffic analysis one can observe unexpected Domain Name System (DNS) packets too. DNS is an upper-layer protocol in charge of finding the IP address from a Uniform Resource Locator (URL); in this case \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003e\u003ca href=\"http://www.mySolem.com\" target=\"_blank\"\u003ewww.mySolem.com\u003c/a\u003e\u003c/span\u003e\u003cspan address=\"http://www.mySolem.com\" targettype=\"URL\" class=\"RefTarget\"\u003e\u003c/span\u003e\u003c/span\u003e. When a device needs to find and save the IP address of a remote server from an URL, it sends a query request to a DNS server \u0026mdash;usually hosted in the cloud, which sends the response information in a query response [\u003cspan citationid=\"CR44\" class=\"CitationRef\"\u003e44\u003c/span\u003e]. This operation takes place usually in early connections and the recurrent presence of DNS requests (with a mean size of 71 bytes each) and DNS responses (with approximately 87 bytes each) in the regular operation of our case study (sending counts every 18 seconds) suggest that the gateway do not keep in memory the IP address of the cloud server (generating extra traffic in mutualized infrastructures).\u003c/p\u003e \u003cp\u003eTable A4 in the Supplementary Information (part 7) synthesizes the data flow observed in the packet traffic analysis for the regular and consultation operational modes, highlighting the new behavior disclosed above (gray cells) and disclosing a total data volume of 4,305 GB. From this, the reference flow of the internet networks and cloud server amounts to 0,6457 kWh and 0,6027 kWh respectively (assuming the electricity intensity factors mentioned before). This provokes an impact of 0,5 Kg CO\u003csub\u003e2\u003c/sub\u003e-eq for the internet use, and 0,467 Kg CO\u003csub\u003e2\u003c/sub\u003e-eq for the cloud server (both assuming a global electricity mix). In this way, and considering the same impact coming from the same reference flow of the induction emitter, the gateway and the smartphone; the total impact estimated from the packet traffic analysis of the case study amounts to 6,4296 Kg CO\u003csub\u003e2\u003c/sub\u003e-eq.\u003c/p\u003e \u003c/div\u003e"},{"header":"4. Discussion","content":"\u003cp\u003eThe absolute impact calculated from the packet traffic analysis in section 3.2 exceeds than one calculated from the proposed implementation of our framework in section 3.1 by 12,34%. The difference is explained mainly by the additional data revealed in the regular and consultation operational modes (red texts in Fig.\u0026nbsp;\u003cspan refid=\"Fig9\" class=\"InternalRef\"\u003e9\u003c/span\u003e), which increased significantly the reference flow of the Internet \u0026amp; Access networks and the cloud server (in terms of electricity used per GB generated by the gateway and the cloud server).\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eImportantly, the impact contribution of the Internet \u0026amp; Access networks and the cloud server went from being insignificant in the theoretical estimation of the reference flow of the system, to relevant in the empirical estimation (overcoming the impact contribution of the flowmeter, as is showed in Fig.\u0026nbsp;\u003cspan refid=\"Fig10\" class=\"InternalRef\"\u003e10\u003c/span\u003e).\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eIn this sense, three redesign initiatives could be discussed. Firstly, designers could reconfigure the gateway to keep in memory the IP address of the cloud server and trigger mechanisms to reobtained it, whenever it changes (this would avoid unnecessary DNS traffic in every transmission event of the regular operational mode). Secondly, designers could set the gateway to initialize a TCP teardown routine automatically (this would prevent the server from sending HTTP timeout requests after uploading data application). In this line, designer could consider alternatively the use of connectionless protocols. Thirdly, designers could configure the gateway to execute preprocessing routines (data aggregation or data reduction techniques) to avoid massive HTTP traffic (POST requests) whenever an online consultation of water consumption occurs. However, designer should proceed with caution, as the synthesis or reduction of information may damage the accuracy of the system and/or require more energy.\u003c/p\u003e \u003cp\u003eOn the other hand, the impact contribution of the gateway is undeniable. To mitigate it, designers should consider alternative self-powered versions of this device. However, in order to this drastic change makes sense, it should be accompanied by a redesign of the entire data flow of the system, oriented to manage only the necessary transmission frequency, with sufficient quality (in this sense, an analysis on the reasons that provokes the high frequency of transmission events in the regular operational mode need to be conducted).\u003c/p\u003e \u003cp\u003eBeside of that, it is intriguing to see that the manufacturer recommends a maximal distance range of 800 meters between the flowmeter and the gateway, when the LoRa technology offers longer communication ranges (from 2 to 14 km). Although revealing the reasons why the manufacturer suggests this distance is beyond the scope of this work, it is believed that a probable motivation is assuring high QoS and maximizing the lifetime of the flowmeters\u0026rsquo; batteries (by avoiding long time-on-air periods, as it was explained in section 3). However, this would lead to drawbacks, because the number of gateways in a network could increase, depending on their locations and especially on the extension of terrains, as explained below.\u003c/p\u003e \u003cp\u003e \u003c/p\u003e \u003cp\u003eFigure \u003cspan refid=\"Fig11\" class=\"InternalRef\"\u003e11\u003c/span\u003e shows for example that, to cover an area of 2,56 km\u003csup\u003e2\u003c/sup\u003e, (1,6 \u0026#128939; 1,6 km), a deployment of at least three gateways is required (according to the recommendations of the manufacturer). However, this does not necessarily have to be so. The packet traffic analysis conducted in this work shows that the flowmeter does not generate significant volumes of data application (approximately 57 Bytes per LoRa transmission event). By considering that this load was perfectly managed by one gateway in a 125 kHz bandwidth and a Spreading Factor of 7, there is sufficient evidence to believe that, under the same conditions, a flowmeter could be covered perfectly within a distance range of 2 km and for more than 5 years, as estimations in the second row of Table \u003cspan refid=\"Tab3\" class=\"InternalRef\"\u003e3\u003c/span\u003e suggest.\u003c/p\u003e \u003cp\u003e \u003cdiv class=\"gridtable\"\u003e\u003ctable float=\"Yes\" id=\"Tab3\" border=\"1\"\u003e \u003ccaption language=\"En\"\u003e \u003cdiv class=\"CaptionNumber\"\u003eTable 3\u003c/div\u003e \u003cdiv class=\"CaptionContent\"\u003e \u003cp\u003eEstimation of the maximal lifetime of one Li-ion 9V battery for transmitting periodic LoRa packets of 57 Bytes, under different operational conditions of the flowmeter (in years)\u003c/p\u003e \u003c/div\u003e \u003c/caption\u003e \u003ccolgroup cols=\"9\"\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c1\" colnum=\"1\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c2\" colnum=\"2\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c3\" colnum=\"3\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c4\" colnum=\"4\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c5\" colnum=\"5\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c6\" colnum=\"6\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c7\" colnum=\"7\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c8\" colnum=\"8\"\u003e\u003c/div\u003e \u003cdiv align=\"left\" class=\"colspec\" colname=\"c9\" colnum=\"9\"\u003e\u003c/div\u003e \u003cthead\u003e \u003ctr\u003e \u003cth align=\"left\" colname=\"c1\"\u003e\u0026nbsp;\u003c/th\u003e \u003cth align=\"left\" colname=\"c2\"\u003e\u0026nbsp;\u003c/th\u003e \u003cth align=\"left\" colname=\"c3\"\u003e\u0026nbsp;\u003c/th\u003e \u003cth align=\"left\" colname=\"c4\"\u003e\u0026nbsp;\u003c/th\u003e \u003cth align=\"left\" colname=\"c5\"\u003e\u0026nbsp;\u003c/th\u003e \u003cth align=\"left\" colspan=\"2\" nameend=\"c7\" namest=\"c6\"\u003e \u003cp\u003eIn a transmission (s)\u003c/p\u003e \u003c/th\u003e \u003cth align=\"left\" colname=\"c8\"\u003e\u0026nbsp;\u003c/th\u003e \u003cth align=\"left\" colname=\"c9\"\u003e\u0026nbsp;\u003c/th\u003e \u003c/tr\u003e \u003c/thead\u003e \u003ctbody\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cb\u003eDistance\u003c/b\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(km)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e\u003cb\u003eSF\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u003cb\u003eBand.\u003c/b\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(kHz)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u003cb\u003ePayload\u003c/b\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(bytes)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e\u003cb\u003eBitrate\u003c/b\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(bps)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({\\varvec{t}}_{{\\varvec{T}}_{\\varvec{x}}}\\)\u003c/span\u003e\u003c/span\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({\\varvec{t}}_{\\varvec{s}}\\)\u003c/span\u003e\u003c/span\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e\u003cspan class=\"InlineEquation\"\u003e\u003cspan class=\"mathinline\"\u003e\\({\\varvec{B}}_{\\varvec{f}\\varvec{m}}\\)\u003c/span\u003e\u003c/span\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(In 2 years)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e\u003cb\u003eLifetime\u003c/b\u003e\u003c/p\u003e \u003cp\u003e\u003cb\u003e(In years)\u003c/b\u003e\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e2\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSF7\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e250\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e242\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e11000\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e0,041\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e179,96\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e0,182\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e11,0\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e\u003cem\u003e2\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003e\u003cem\u003eSF7\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e\u003cem\u003e125\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e\u003cem\u003e242\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e\u003cem\u003e5470\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e\u003cem\u003e0,083\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e\u003cem\u003e179,92\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e\u003cem\u003e0,341\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e\u003cem\u003e5,9\u003c/em\u003e\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e4\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSF8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e125\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e242\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e3125\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e0,146\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e179,85\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e0,579\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e3,5\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e6\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSF9\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e125\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e115\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e1760\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e0,259\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e179,74\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e1,009\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e2,0\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e8\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSF10\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e125\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e51\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e980\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e0,465\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e179,53\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e1,793\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e1,1\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e11\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSF11\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e125\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e51\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e440\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e1,036\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e178,96\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e3,964\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e0,5\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003ctr\u003e \u003ctd align=\"left\" colname=\"c1\"\u003e \u003cp\u003e14\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c2\"\u003e \u003cp\u003eSF12\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c3\"\u003e \u003cp\u003e125\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c4\"\u003e \u003cp\u003e51\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c5\"\u003e \u003cp\u003e290\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c6\"\u003e \u003cp\u003e1,572\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c7\"\u003e \u003cp\u003e178,43\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c8\"\u003e \u003cp\u003e6,002\u003c/p\u003e \u003c/td\u003e \u003ctd align=\"left\" colname=\"c9\"\u003e \u003cp\u003e0,3\u003c/p\u003e \u003c/td\u003e \u003c/tr\u003e \u003c/tbody\u003e \u003c/colgroup\u003e \u003c/table\u003e\u003c/div\u003e \u003c/p\u003e \u003cp\u003eThe detailed calculations to obtain the maximal lifetime of the flowmeter\u0026rsquo;s battery in years are available in the section 8 of the Supplementary Information.\u003c/p\u003e \u003cp\u003eOn the other hand, the 2 rightest columns of Table \u003cspan refid=\"Tab3\" class=\"InternalRef\"\u003e3\u003c/span\u003e reveals two interesting aspects for the reference flow of the case study and its eco design. Firstly, intentions of replacing the battery-powered design of the flowmeter by another self-powered design would be beneficial only in specific contexts. For example, if the distance range is about 14 km, switching to a self-powered version of the flowmeter would avoid the continuous replacement of batteries in the short-term (i.e.; approximately six batteries every two years). However, if the local transmissions involve distance ranges of 2 or 4 km, and a selected bandwidth of 125 kHz, a self-powered design would bring only marginal benefits (one would avoid just changing one battery approximately every 6 or 3 years). What is worse, one could transfer impacts from the use-phase of the flowmeter to its manufacturing phase (depending on the complexity of its self-powered design). Secondly, maximal benefits could be obtained by using a bitrate of 11kbps in a 250 kHz bandwidth (a battery would be replaced approximately once every 11 years).\u003c/p\u003e \u003cp\u003eAlthough this analysis on distance ranges and technical capacities could reveal even more tradeoffs in design stages, it should be taken into account prudently, as more variables influencing the quality of LoRa transmission may exits (further research and estimations should be conducted, as long as documentation about the design of the flowmeter, gateway and the dataflow between them becomes publicly available).\u003c/p\u003e \u003cp\u003eFinally, the packet traffic analysis presented in this work demonstrates that the frequency at which the local infrastructure connects with the cloud infrastructure, the volume of data generated and transmitted, and the protocol overhead of transmissions in regular and / or user-driver operations are all fundamental aspects to be considered in the modeling of reference flows and impact estimation of full IoT systems. This aspect warns Life Cycle Assessment (LCA) practitioners from be cautious about the postures of Malmodin, J. et al. [\u003cspan citationid=\"CR39\" class=\"CitationRef\"\u003e39\u003c/span\u003e] and Coroama, V.C., et al. [\u003cspan citationid=\"CR45\" class=\"CitationRef\"\u003e45\u003c/span\u003e] who suggest that, for estimating the electricity intensity of ICT (which is different from estimating its ecological impact), end devices \u0026mdash;such as sensor systems\u0026mdash; should be consider only from a use time perspective.\u003c/p\u003e \u003cp\u003eTo extend this discussion, and nourish further research and works in the context of similar case studies, the following guidelines are offered to the LCA and eco design communities.\u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 1\u003c/strong\u003e \u003cp\u003eThe protocol overhead is relevant, depending on the transmission frequency and the reliability degree of applications. When low-accuracy applications characterize an IoT system, high frequency is not necessary and approximate computing can be applied.\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 2\u003c/strong\u003e \u003cp\u003eWhen invariable behavior characterizes an application (i.e.; uniform water consumption, unchanging lighting pattern in households, etc.) information can be extrapolated from historical or redundant data in the cloud infrastructure so that massive local-to-cloud transmissions can be avoid.\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 3\u003c/strong\u003e \u003cp\u003eWhen high transmission frequency is necessaire, consider connectionless protocols and reinforce security (for example by using message authentication, rate throttling, robust encryption, etc.). However, evaluate simultaneously the additional energy requirements of security routines and find a balanced solution distributed over the sensing, edge and cloud layers.\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 4\u003c/strong\u003e \u003cp\u003eWhen estimating the reference flow of an IoT system for its (re)design, consider not only the operational time of local devices but also their energy consumption patterns in time affected by different circumstances and different capacities of different electronic components, in the context of functions and data flow (e.g., sampling rates in data collection, maximal payloads in data processing, bitrates, frequency bandwidths or distance range in data transmission, etc.).\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 5\u003c/strong\u003e \u003cp\u003eWhen estimating the impact of the use phase of an IoT system whose design documentation is unavailable, consider that additional communication between IoT layers may occurs when a user or a device retrieves information directly from cloud resources.\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 6\u003c/strong\u003e \u003cp\u003eStudy functions-capacities of electronic components in an exhaustive way, so that to find those ones that boost or challenge a design. For example, wireless modules with high bitrates makes sense only when irreducible big payloads are expected (e.g., image, video, etc.).\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 7\u003c/strong\u003e \u003cp\u003eStudy functions-capacities of electronic components and operational contexts carefully, so that to propose reasonable designs. For example, in the context of LoRa-based IoT systems, using the Frequency-Shift Keying (FSK) modulation makes sense only when the application type generates big payloads.\u003c/p\u003e \u003c/p\u003e \u003cp\u003e \u003cstrong\u003eGuideline 8\u003c/strong\u003e \u003cp\u003eConsider several aspects of the operational context that may affect not only the efficiency of electronic components, but also the data flow design (and consequently the reference flow) of an IoT system. For example, in the context of LoRa-based IoT Systems, long distance ranges would force designers to consider either energy intensive data preprocessing routines in local microprocessors (increasing energy consumption in the sensing and edge equipment, but reducing energy consumption in the mutualized infrastructure), or change the planned sampling rate of a sensor component (lowing energy needs in the local and mutualized infrastructure, but scarifying data resolution).\u003c/p\u003e \u003c/p\u003e"},{"header":"5. Conclusions and on-going research","content":"\u003cp\u003eIn our increasingly connected world, this research aims to point out the capital role of sensor data for modeling the reference flow of IoT systems and, in this way, illuminate the way for LCA practitioners and IoT designers to conduct comprehensive assessments and efficient eco design. To do this, we proceed in three parts. Firstly, we presented the previous literature that reports significant variations on reference flows and impact from changes made on data flows. Secondly, we proposed a customized implementation of our previous framework to estimate the reference flow of a case study and, in this manner, to have a rough idea of its impact in the use phase, in a long-term, and in an unfavorable data flow context. Thirdly, we conduct a packet traffic analysis to estimate empirically the real reference flow of the case study.\u003c/p\u003e \u003cp\u003eFrom the first part, although the reviewed authors do not state explicitly the relevance of sensor data or data flow for modeling reference flows and estimating impacts, they provide solid evidence that helps to understand our posture and defend our simple yet powerful framework oriented to facilitate integral impact assessment and effective eco design. From the second part, it was showed that comprehensive and agile estimations can be conducted from available information (technical specifications) of key electronic components applied in a cross-type life cycle model. From the third part, the central role of data has been verified by demonstrating that its flow can modify the reference flow of a system and even redistribute the impact contribution of the local and mutualized infrastructure calculated theoretically. In this part, it was also observed the potential complexity of interactions between local and mutualized infrastructures and it was noted that, in the long-term, the absolute impact of the internet and cloud components of and IoT system should not be neglected.\u003c/p\u003e \u003cp\u003eTo reach to these conclusions and present a fruitful discussion that facilitate the production of generic guidelines for agile impact estimation and eco design, in the second and the third parts we made use of a customized implementation derived from our previous framework, which is based on the simple, yet powerful association of functions-capacities of electronic components.\u003c/p\u003e \u003cp\u003eThis framework, together with another one oriented to facilitate the integration of ecological aspects into the New Product Development (NPD) of local IoT prototypes [\u003cspan citationid=\"CR46\" class=\"CitationRef\"\u003e46\u003c/span\u003e] are being tested in parallel in the industrial and educational context.\u003c/p\u003e \u003cp\u003eBoth conform a methodology for sustainable IoT systems. LCA practitioners and designers should apply them simultaneously in the context of their own projects, as a sort of roadmap that recalls that each parts, such as data, information, devices, function, capacities, and electronic components (including its physical and technical characteristics and circularity potential) must be examined holistically and carefully.\u003c/p\u003e"},{"header":"Declarations","content":"\u003ch2\u003e\u003cstrong\u003eAcknowledgements\u003c/strong\u003e\u003c/h2\u003e\n\u003cp\u003eThis work was supported by the French National Research Agency in the framework of the \"Investissements d’avenir” program (ANR-15-IDEX-02). This work was also funded thanks to the French National program « programme d’invertissements d’avenir, IRT Nanoelec » ANR-10-AIRT-05.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAuthors’ contributions\u003c/strong\u003e Conceptualization, Methodology and Writing —original draft preparation: Ernesto Quisbert-Trujillo; Writing —review and editing: Panagiota Morfouli; All authors read and approved the final manuscript.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eData Availability Statement\u0026nbsp;\u003c/strong\u003eThe authors declare that the data supporting the findings of this study are available within the paper, its reference section and its supplementary information files. Full pcapng Wireshark files generated during the Packet Traffic Analysis and used for producing Figure 9 are available from the corresponding author on reasonable request.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFunding\u0026nbsp;\u003c/strong\u003eThis work was supported by the French National Research Agency in the framework of the \"Investissements d’avenir” program (ANR-15-IDEX-02). This work was also funded thanks to the French National program « programme d’invertissements d’avenir, IRT Nanoelec » ANR-10-AIRT-05.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCompeting interests\u003c/strong\u003e The authors declare no conflict of interest.\u003c/p\u003e"},{"header":"References","content":"\u003col\u003e\n \u003cli\u003e\u003cspan\u003eFigliola PM. The Internet of Things (IoT): An Overview. Congressional Research Service; 2020.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eCISCO., \u0026quot;CISCO Annual Internet Report (2018\u0026ndash;2023),\u0026quot; 2020.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eDas S, Mao E. The global energy footprint of information and communication technology electronics in connected Internet-of-Things devices. Sustainable Energy Grids and Networks. 2020;24:100408.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eMasanet E, Shehabi A, Lei N, Smith S, Koomey J. \u0026quot;Recalibrating global data center energy-use estimates,\u0026quot; \u003cem\u003eScience\u003c/em\u003e, vol.\u0026nbsp;367, no. 6481, pp.\u0026nbsp;984\u0026ndash;986, 2020.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eTrack E, Forbes N, Strawn G. The End of Moore\u0026apos;s Law. Comput Sci Eng. 2017;19(2):4\u0026ndash;6.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eTheis TN, Wong H-SP. The End of Moore\u0026apos;s Law: A New Beginning for Information Technology. Comput Sci Eng. 2017;19(2):41\u0026ndash;50.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eKoot M, Wijnhoven F. Usage impact on data center electricity needs: A system dynamic forecasting model. Appl Energy. 2021;291:116798.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBelkhir L, Elmeligi A. Assessing ICT global emissions footprint: Trends to 2040 \u0026amp; recommendations. J Clean Prod. 2018;177:448\u0026ndash;63.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eLelah A, Mathieux F, Brissaud D. Contributions to eco-design of machine-to-machine product service systems: the example of waste glass collection. J Clean Prod. 2011;19:9\u0026ndash;10.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eInternational Organization for Standardization, Technical Committee. : ISO/TC 207/SC 5, \u003cem\u003eISO 14040:2006 Environmental management - Life cycle assessment - Principles and framework\u003c/em\u003e, 2006.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eQuisbert-Trujillo E, Ernst T, Samuel KE, Cor E, Monnier E. \u0026quot;Lifecycle Model eco Des Internet Things \u0026quot; Procedia CIRP, 2020.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBonvoisin J, Lelah A, Mathieux F, Brissaud D. An integrated method for environmental assessment and ecodesign of ICT-based optimization services. J Clean Prod. 2014;68:144\u0026ndash;54.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eWagner E, Bohme C, Benecke S, Nissen NN, Lang K-D. \u0026quot;Advanced packaging for wireless sensor nodes in cyber-physical systems - impacts of multifunctionality and miniaturization on the environment,\u0026quot; in 2017 \u003cem\u003eIEEE International Conference on Prognostics and Health Management (ICPHM)\u003c/em\u003e, 2017.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eK\u0026ouml;hler AR, Lauterbach C, Steinhage A, Buiterv JC, Techmer A. \u0026quot;Life cycle assessment and eco-design of a textile-based large-area sensor system,\u0026quot; in Electron Goes Green 2012+, 2012.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBonvoisin J, Lelah A, Mathieux F, Brissaud D. An environmental assessment method for wireless sensor networks. J Clean Prod. 2012;33:145\u0026ndash;54.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eVan Dam S, Bakker C, Buiter J. Do home energy management systems make sense? Assessing their overall lifecycle impact. Energy Policy. 2013;63:398\u0026ndash;407.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eDubberley M, Agogino A, Horvath A. \u0026quot;Life-cycle assessment of an intelligent lighting system using a distributed wireless Mote network,\u0026quot; in \u003cem\u003eIEEE International Symposium on Electronics and the Environment\u003c/em\u003e, 2004. Conference Record. 2004, 2004.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003ePirson T, Bol D. Assessing the embodied carbon footprint of IoT edge devices with a bottom-up life-cycle approach. J Clean Prod. 2021;322:128966.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eGlogic E, Futsch R, Thenot V, Iglesias A, Joyard-Pitiot B, Depres G, Rougier A, Sonnemann G. Development of Eco-Efficient Smart Electronics for Anticounterfeiting and Shock Detection Based on Printable Inks. ACS Sustain Chem Eng. 2021;9(35):11691\u0026ndash;704.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eVan Der Velden NM, Kuusk K, K\u0026ouml;hler AR. Life cycle assessment and eco-design of smart textiles: The importance of material selection demonstrated through e-textile product redesign. Mater Design. 2015;84:313\u0026ndash;24.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eBrun GL, Raskin J-P. \u0026quot;Material and manufacturing process selection for electronics eco-design: Case study on paper-based water quality sensors,\u0026quot; in \u003cem\u003eProcedia CIRP\u003c/em\u003e, 2020.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eIngemarsdotter E, Diener D, Andersson S, Jonasson C, Mellquist A-C, Nystr\u0026ouml;m T, Jamsin E, Balkenende R. Quantifying the Net Environmental Impact of Using IoT to Support Circular Strategies\u0026mdash;The Case of Heavy-Duty Truck Tires in Sweden. Circular Econ Sustain. 2021;1(2):613\u0026ndash;50.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eDekoninck E, Barbaccia F. \u0026quot;Streamlined Assessment to Assist in the Design of Internet-of-Things (IOT) Enabled Products: A Case Study of the Smart Fridge,\u0026quot; in \u003cem\u003eProceedings of the Design Society: International Conference on Engineering Design\u003c/em\u003e, 2019.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eSarkar S, Chatterjee S, Misra S. Assessment of the Suitability of Fog Computing in the Context of Internet of Things. IEEE Trans Cloud Comput. 2018;6(1):46\u0026ndash;59.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eManz O, Meyer S, Baumgartner C. \u0026quot;Life cycle assessment of an Internet of Things product: Environmental impact of an intelligent smoke detector,\u0026quot; in \u003cem\u003eIoT \u0026apos;21: 11th International Conference on the Internet of Things\u003c/em\u003e, 2021.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eArshad R, Zahoor S, Shah MA, Wahid A, Yu H. Green IoT: An Investigation on Energy Saving Practices for 2020 and Beyond. IEEE Access. 2017;5:15667\u0026ndash;81.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eHuang J, Meng Y, Gong X, Liu Y, Duan Q. A Novel Deployment Scheme for Green Internet of Things. IEEE Internet of Things Journal. 2014;1(2):196\u0026ndash;205.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eGurova O, Merritt TR, Papachristos E, Vaajakari J. \u0026quot;Sustainable Solutions for Wearable Technologies: Mapping the Product Development Life Cycle,\u0026quot; \u003cem\u003eSustainability\u003c/em\u003e, vol.\u0026nbsp;12, no. 20, p.\u0026nbsp;8444, 2020.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eZhu C, Leung VCM, Shu L, Ngai EC-H. Green Internet of Things for Smart World. IEEE Access. 2015;3:2151\u0026ndash;62.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eMiddendorf A, Deyter S, Gausemeier J, Nissen NF, Reichl H. \u0026quot;Integration of reliability and environmental aspects in early design stages of mechatronics,\u0026quot; in \u003cem\u003e2009 IEEE International Symposium on Sustainable Systems and Technology (ISSST)\u003c/em\u003e, 2009.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eMorin E, Maman M, Guizzetti R, Duda A. Comparison of the Device Lifetime in Wireless Networks for the Internet of Things. IEEE Access. 2017;5:7097\u0026ndash;114.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eSolem \u0026quot;LR-. IP-FL Irrigation controller for large spaces and water flow monitoring,\u0026quot; [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://solem-irrigation.com/en/product/lr-ip-fl-longue-portee-800m/\u003c/span\u003e\u003c/span\u003e. [Accessed 31 07 2023].\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eMeters B. \u0026quot;Pulse Output IWM-PL3,\u0026quot; [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.bmeters.com/en/products/iwm-pl3/\u003c/span\u003e\u003c/span\u003e. [Accessed 31 07 2023].\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eSolem \u0026quot;LR-. MB-10 LoRa\u0026trade;/Wi-Fi connected gateway,\u0026quot; [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://solem-irrigation.com/en/product/lr-mb-10-pilotable-a-distance/\u003c/span\u003e\u003c/span\u003e. [Accessed 31 07 2023].\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eMicrochip. \u0026quot;Low-Power Long range LoRa Technology Transceiver Module,\u0026quot; [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttp://ww1.microchip.com/downloads/en/DeviceDoc/RN2483-Low-Power-Long-Range-LoRa-Technology-Transceiver-Module-Data-Sheet-DS50002346D.pdf\u003c/span\u003e\u003c/span\u003e. [Accessed 31 07 2023].\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eLaboratoire de, Moirans. \u0026quot;BLEMOD BLE Solem Module,\u0026quot; [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://fccid.io/YWW-BLEMOD/Internal-Photos/Internal-Photos-3795789\u003c/span\u003e\u003c/span\u003e. [Accessed 31 07 2023].\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eEspressif. \u0026quot;ESP-WROOM-S2 WiFi/WLAN module,\u0026quot; [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.espressif.com/en/producttype/esp-wroom-s2\u003c/span\u003e\u003c/span\u003e. [Accessed 31 07 2023].\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eHanes D, Salgueiro G, Grossetete P, Barton R, Henry J. IoT fundamentals: networking technologies, protocols, and use cases for the Internet of things. Cisco Press; 2017.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eMalmodin J, Lund\u0026eacute;n D, Moberg \u0026Atilde;, Andersson G, Nilsson M. Life Cycle Assessment of ICT: Carbon Footprint and Operational Electricity Use from the Operator, National, and Subscriber Perspective in Sweden. J Ind Ecol. 2014;18(6):829\u0026ndash;45.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eKrug L, Shackleton M, Saffre F. \u0026quot;Understanding the Environmental Costs of Fixed Line Networking,\u0026quot; in \u003cem\u003eProceedings of the 5th International Conference on Future Energy Systems\u003c/em\u003e, 2014.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eAndrae A, Edler T. \u0026quot;On Global Electricity Usage of Communication Technology: Trends to 2030,\u0026quot; \u003cem\u003eChallenges\u003c/em\u003e, vol.\u0026nbsp;6, no. 1, pp.\u0026nbsp;117\u0026ndash;157, 2015.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003ePerrucci GP, Fitzek FHP, Widmer J. \u0026quot;Survey on Energy Consumption Entities on the Smartphone Platform,\u0026quot; in \u003cem\u003e2011 IEEE Vehicular Technology Conference (VTC 2011-Spring)\u003c/em\u003e, 2011.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eRobyns P, Quax P, Lamotte W, Thenaers W. \u003cem\u003egr-lora: An efficient LoRa decoder for GNU Radio\u003c/em\u003e, Zenodo ed., vol.\u0026nbsp;10, 2017, p.\u0026nbsp;5281.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eSanders C. Practical packet analysis: Using Wireshark to solve real-world network problems. No Starch Press; 2017.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eCoroama VC, Schien D, Preist C, Hilty LM. \u0026quot;The Energy Intensity of the Internet: Home and Access Networks,\u0026quot; in \u003cem\u003eICT Innovations for Sustainability\u003c/em\u003e, 2015, pp.\u0026nbsp;137\u0026ndash;155.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eQuisbert-Trujillo E, Ernst T, Samuel KE, Monnier E, Gallardo M. \u0026quot;A methodology for supporting the sustainable future and eco design of the Internet of Things,\u0026quot; in \u003cem\u003eOral presentation at the International Conference on Sustainable Technology and Development\u003c/em\u003e, Shenzhen, China, 2021.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eAslan J, Mayers K, Koomey JG, France C. Electricity Intensity of Internet Data Transmission: Untangling the Estimates: Electricity Intensity of Data Transmission. J Ind Ecol. 2018;22(4):785\u0026ndash;98.\u003c/span\u003e\u003c/li\u003e\n \u003cli\u003e\u003cspan\u003eInternational Telecommunication Union., \u0026quot;Requirements of the network for the Internet of things,\u0026quot; [Online]. Available: \u003cspan class=\"ExternalRef\"\u003e\u003cspan class=\"RefSource\"\u003ehttps://www.itu.int/rec/T-REC-Y.4113/en\u003c/span\u003e\u003c/span\u003e. [Accessed 31 07 2023].\u003c/span\u003e\u003c/li\u003e\n\u003c/ol\u003e"},{"header":"Footnotes","content":"\u003col\u003e\u003cli\u003e\u003cspan\u003e According to Aslan, J. et al [47] and to the network architecture for IoT systems proposed by the ITU-T Y.4113 recommendation [48], the IAP device belongs to the cloud layer because it interconnects the local devices with Internet Service Providers (ISPs) and internet core networks.\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003e The detailed calculations to obtain the number of batteries, as is defined in equation one, as well as the respective environmental impact are available on the section 1 of the Supplementary Information.\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003e For more details about the data volume generated in the regular and consultation operational modes of the edge and cloud equipement, the respective reference flows and the associated impact, the reader can consult the section 2 of the supplementary material.\u003c/span\u003e\u003c/li\u003e\u003cli\u003e\u003cspan\u003e For more details about the estimated reference flow and the associated impact of the smartphone, the reader can consult the section 3 of the Supplementary Information.\u003c/span\u003e\u003c/li\u003e\u003c/ol\u003e"}],"fulltextSource":"","fullText":"","funders":[],"hasAdminPriorityOnWorkflow":false,"hasManuscriptDocX":true,"hasOptedInToPreprint":true,"hasPassedJournalQc":"","hasAnyPriority":false,"hideJournal":false,"highlight":"","institution":"","isAcceptedByJournal":true,"isAuthorSuppliedPdf":false,"isDeskRejected":"","isHiddenFromSearch":false,"isInQc":false,"isInWorkflow":false,"isPdf":false,"isPdfUpToDate":true,"isWithdrawnOrRetracted":false,"journal":{"display":true,"email":"[email protected]","identity":"discover-internet-of-things","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"diot","sideBox":"Learn more about [Discover Internet of Things](https://www.springer.com/journal/43926)","snPcode":"","submissionUrl":"","title":"Discover Internet of Things","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Discover Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true},"keywords":"Internet of Things, IoT, IoT Systems, Sensor systems, Life Cycle Assessment, LCA, Eco design, Reference flow, Packet traffic analysis, LoRa","lastPublishedDoi":"10.21203/rs.3.rs-3247380/v1","lastPublishedDoiUrl":"https://doi.org/10.21203/rs.3.rs-3247380/v1","license":{"name":"CC BY 4.0","url":"https://creativecommons.org/licenses/by/4.0/"},"manuscriptAbstract":"\u003cp\u003eAs we approach the limits of our technologies and the number of connected devices grows, scientists put more efforts to estimate and reduce the ecological damage of the Internet of Things. Unfortunately, environmental studies and eco design of IoT systems suffer from a major inconvenience so far: it does not put sensor data in the focus of attention. This paper aims to point out explicitly the essential role of this aspect for modeling reference flows and demonstrate its relevance for agile environmental assessment and sustainable design. Also, it aims to illustrate that such modeling process must happen in a comprehensive way. For this, our work relies on a case study addressing smart metering, and we proceed as follows. Based on available documentation and inspired by certain aspects of different technologies, we imagine the maximal capacities of key components, and we construct an unfavorable data flow scenario to get a rough idea of the reference flow and the long-term impact of our system during its use phase. Results from this procedure are later contrasted with results obtained from a packet traffic analysis, in which local and internet data flow are examined carefully. At the end, we verify the importance of data empirically, and we conclude that the reference flow and the impact contributors of a system could be affected not only by the local data transit but also by the complex interactions between edge devices and cloud resources. All our findings are discussed to produce generic guidelines for sustainable IoT systems.\u003c/p\u003e","manuscriptTitle":"An approach for comprehensive Life Cycle Assessment and effective eco design of IoT systems: data-driven modeling of reference flows","msid":"","msnumber":"","nonDraftVersions":[{"code":1,"date":"2023-08-29 14:07:28","doi":"10.21203/rs.3.rs-3247380/v1","editorialEvents":[{"type":"communityComments","content":0},{"type":"decision","content":"Major revision","date":"2023-10-16T01:22:09+00:00","index":"","fulltext":""},{"type":"editorInvitedReview","content":"","date":"2023-09-25T17:29:10+00:00","index":"hide","fulltext":""},{"type":"reviewerAgreed","content":"63bced47-f9ff-4c80-a06f-07acbd3294d6_SNPRID","date":"2023-09-18T08:39:34+00:00","index":"hide","fulltext":""},{"type":"reviewersInvited","content":"","date":"2023-09-14T08:36:17+00:00","index":"","fulltext":""},{"type":"editorAssigned","content":"","date":"2023-08-24T08:46:19+00:00","index":"","fulltext":""},{"type":"checksComplete","content":"","date":"2023-08-24T08:46:06+00:00","index":"","fulltext":""},{"type":"submitted","content":"Discover Internet of Things","date":"2023-08-09T04:39:14+00:00","index":"","fulltext":""}],"status":"published","journal":{"display":true,"email":"[email protected]","identity":"discover-internet-of-things","isNatureJournal":false,"hasQc":true,"allowDirectSubmit":false,"externalIdentity":"diot","sideBox":"Learn more about [Discover Internet of Things](https://www.springer.com/journal/43926)","snPcode":"","submissionUrl":"","title":"Discover Internet of Things","twitterHandle":"","acdcEnabled":true,"dfaEnabled":true,"editorialSystem":"stoa","reportingPortfolio":"Discover Series","inReviewEnabled":true,"inReviewRevisionsEnabled":true}}],"origin":"","ownerIdentity":"cbcb3cf8-d3bb-4bbd-bd60-4257a2cc9a00","owner":[],"postedDate":"August 29th, 2023","published":true,"recentEditorialEvents":[],"rejectedJournal":[],"revision":"","amendment":"","status":"published-in-journal","subjectAreas":[],"tags":[],"updatedAt":"2023-11-27T15:06:22+00:00","versionOfRecord":{"articleIdentity":"rs-3247380","link":"https://doi.org/10.1007/s43926-023-00051-4","journal":{"identity":"discover-internet-of-things","isVorOnly":false,"title":"Discover Internet of Things"},"publishedOn":"2023-11-20 15:01:25","publishedOnDateReadable":"November 20th, 2023"},"versionCreatedAt":"2023-08-29 14:07:28","video":"","vorDoi":"10.1007/s43926-023-00051-4","vorDoiUrl":"https://doi.org/10.1007/s43926-023-00051-4","workflowStages":[]},"version":"v1","identity":"rs-3247380","journalConfig":"researchsquare"},"__N_SSP":true},"page":"/article/[identity]/[[...version]]","query":{"redirect":"/article/rs-3247380","identity":"rs-3247380","version":["v1"]},"buildId":"_2-kVJe1T_tPrBINL-cwx","isFallback":false,"isExperimentalCompile":false,"dynamicIds":[84888],"gssp":true,"scriptLoader":[]}