An IoT LoRaWAN Network for environmental radiation monitoring

—A reliable and highly scalable Internet of Things 1 (IoT) end-to-end data infrastructure has been developed for 2 environmental radiation monitoring at CERN based on a Low-3 Power Wide-Area Network (LPWAN). The proposed system, 4 called W-MON (Waste radiation MONitoring), consists of an in-5 terconnected network of thousands of highly sensitive and ultra-6 low power gamma radiation sensors acting as LoRa transceivers. 7 The aim of the system is to improve and automatize the 8 radiological controls of conventional waste containers. The end-9 devices measure the radiation levels in the waste containers 10 on a continuous basis and send the data periodically to the 11 LoRaWAN network server. The network has been deployed in 12 an outdoor environment covering hundreds of hectares. A set 13 of web-based user applications for real-time monitoring, data 14 visualization and status control of the devices have been designed 15 based on open source tools. The data pipeline infrastructure has 16 been designed to allow an easy integration into REMUS, the 17 overall CERN Radiation and Environment Monitoring Uniﬁed 18 Supervision service. 19

wireless data transmission for real-time monitoring of the radiation levels in standard waste containers.The system has been specifically designed for the detection of very low radioactive levels above the natural background (around 100 nSv/h), providing identification and early warning of a possible radiation release event.
The IoT has allowed the connection of conventional measuring devices to the internet, providing smart solutions to dailybased problems [2].In fact, the deployment of IoT networks had an impact on numerous applications such as smart cities, transportation, healthcare, etc [3]- [6].IoT applications for environmental and ambient monitoring of large areas have been studied by many authors [7]- [9].In particular, the use of smart sensors with IoT connectivity has shown its potential for improved waste management and monitoring systems [10]- [12].IoT has also been proposed for monitoring applications based on radiation sensors, mainly for radiation surveillance in nuclear power plants [13], [14].The system proposed in this paper benefits from the potential of IoT networks to monitor large areas [15] for the radiological control of waste containers.To our knowledge, this paper presents for the first time a distributed network for real-time remote monitoring of radioactivity in metallic waste containers.It is also the first to evaluate the effects of a metallic waste container on the packet reception efficiency.
The proposed IoT infrastructure incorporates a Low-Power Wide-Area Network (LPWAN) that uses LoRa technology, enabling a large-area low-power IoT deployment [15], [16].The system follows the standards and protocols of an IoT Lo-RaWAN architecture.It has been designed to cover a wide area of hundreds of hectares with thousands of sensors working simultaneously for several years.The sensors provide stable long-term low-dose rate measurements under demanding operating conditions [1].The radiation levels are periodically transmitted to the LoRa server and stored in a database with detailed event log.A set of web-based user applications with graphic controls for real-time data visualization have been designed based on open-source tools.The IoT end-to-end data infrastructure has been tested for over a year showing stable and reliable operation.The next step will be the final integration into the overall CERN Radiation and Environment Monitoring Unified Supervision service (REMUS) [17].
The goal of this paper is to provide a detailed description of the W-MON IoT infrastructure and of the evaluation of the CERN LoRa network within the scope of the W-MON project.The paper is organized as follows: in section II the CERN LoRaWAN Network is described for the first time and the overall W-MON IoT system architecture is presented.
The end-devices are described in Section III.Sections IV and V include the implementation of the radiation sensor network and the results in terms of signal quality, signalto-noise ratio and packet reception ratio (i.e., the percentage of transmitted packets that are successfully received by the server) at different locations and experimental configurations.Based on these requirements, data transmission and communication from the sensors to the monitoring system is achieved via an LPWAN technology [18], [19] and in particular, via LoRa which provides long-range (around 2 km in dense urban areas and up to 15 km in rural areas) low-power wireless communication [16], [20], [21].Alternatives such as WiFi and Low-Energy Bluetooth were discarded due to either a high power consumption or a limited range.The characteristics of LoRa in terms of low-power and long-range makes it the best option for wireless data transmission where small amounts of data need to be sent regularly over a wide area.
Moreover, LoRa is designed to potentially serve millions of devices operating at low data rates [22], suiting the needs of W-MON where thousands of devices are expected to work simultaneously.Nevertheless, the scalability of the network can be seriously affected by the duty cycle restrictions imposed by frequency regulations and concurrent LoRa transmissions, which could lead to a potential signal loss or substantial delays [23]- [26].
In the early stages of the project, two alternative models were considered for data transmission.In the first, each individual sensor in the waste container acted as a LoRa transceiver sending data to the central server.The second alternative was based on a master-slave model; seven of the eight individual sensors per container, i.e. slaves, sent the data to the eighth unit that acted as a master collecting all the information for subsequent transfer to the server.The latter 144 was proposed to reduce the number of devices sending data 145 simultaneously and therefore, reduce the potential number of 146 collisions [27].Here, data transmission between slaves and 147 master does not need to be long range and hence, among 148 the different available wireless technologies, WiFi was chosen 149 for simplicity [28], [29].Several parameters were analyzed to 150 assess the most suited communication model.The results are 151 presented in Section IV.The end-devices consist of an autonomous battery-powered 157 gamma radiation sensor coupled with specifically designed 158 hardware for LoRa data transmission and communication.The 159 devices have been programmed to send small amounts of data 160 periodically to the LoRaWAN Network Server (LNS) (see 161 Section III).Gateways are intermediate devices that act as a 162 bridge between the end-devices and the network, receiving 163 the data from each end-device and forwarding them to the 164 network server.Typically, there is no exclusive association 165 between nodes and gateways, but the same uplink message 166 can be received by several gateways within range.The CERN LNS is based on ChirpStack [30] and uses 168 MQTT (Message Queuing Telemetry Transport) protocol for 169 communication [31].The connectivity between the network 170 server and the monitoring system ensures a secure data flow 171 and high QoS (Quality of Service).The CERN LoRaWAN 172 network communicates with Kafka [32] for real-time data 173 streaming.Kafka is a scalable, high-throughput and distributed 174 data streaming platform, which enables applications to be 175 connected to each other.InfluxDB [33] is used as data storage 176 for large amounts of time-stamped data, including DevOps 177 monitoring, log data, application metrics, IoT sensor data, and 178 real-time analytics.Finally, a set of customized user dash-179 boards for real-time monitoring, data visualization and status 180 control of the devices has been created using Grafana [34].181 Grafana is a visualisation platform with which interactive 182 dashboards can be designed to query, visualise and define 183 levels of alerts on metrics and logs.An example dashboard for 184 W-MON is shown in Fig. 2. It should be noted that decisions 185 about the network and gateways were made based on a CERN-186 wide multi-purpose network.The choice of technologies was 187 (Large Hadron Collider) points.One additional gateway was 221 installed indoors to serve other projects [42].Some of the 222 gateways relevant to these tests and their height are reported 223 in Table I.Currently, the gateway deployment includes 17

III. THE END-DEVICES
The end-devices consist of a highly sensitive and compact gamma radiation sensor allowing the detection of fluctuations above the natural background level and the measurement of gamma radiation dose rate over a wide energy range.Currently, three radiation sensors are under investigation: a customized version of the D-shuttle personal dosimeter developed in collaboration with the National Institute of Advanced Industrial Science and Technology (AIST) and Chiyoda Technol Corporation, the BG51 from Teviso Technologies and the NI-RM02 developed by Nuclear Instruments [1].The three sensors are sensitive and energy efficient Si-based devices.The sensors have been calibrated in the CERN Radiation Calibration Facility [43], [44].They have been programmed to detect count rate variations from background over a time scale of one hour.Background measurements will be used to verify the stability of the sensors over time.Nonetheless, a complete calibration will be carried out at the moment of the battery exchange.Full details are given in [1].
The sensors are coupled to an ultra-low power electronic board with custom-designed hardware and software, allowing for long-range low-power LoRa wireless data transmission (see Fig. 4).The board has been designed to host different sensor types depending on the intended user-case [42].An intermediate PCB (printed circuit board) is required to connect each sensor to the communication board.Fig. 5 shows one of the gamma radiation sensors soldered onto the intermediate board and connected to the communication board.The LoRa transceiver includes an ATSAML21G18B micro-controller (MCU), a RFM95W-868S2 LoRa module operating in Class A mode and an ANT-868-JJB-ST LoRa antenna.A conceptual diagram of the electronic board is depicted in Fig. 6.
The firmware is designed to minimize the power consumption.Confirmed uplink (ACK) and downlink messages are implemented and can be easily enabled if needed.In case of LoRaWAN downtime, data from the radiation sensors are stored in a flash on-board memory.The transmission time can be easily adjusted ensuring flexibility and adaptability to different scenarios.The payload size, on the other hand, is fixed at 41 bytes with 30 bytes of sensor data.It includes the hourly integrated counts for the past three hours (this redundancy is used in order to ensure the continuity of the service), device ID, and power supply level.The 3.3 V value is used

A. Power consumption analysis 289
The overall power consumption of the end-devices depends 290 on the radiation sensor, the LoRa settings and the location 291 of the devices and their proximity to a gateway.To test the power consumption performance, the devices were configured according to Conf. 4 in Table II.The 41-byte packets were sent every 6 minutes with an initial Spreading Factor (SF) of 8 (see Section IV for details about the LoRa physical layer).
The alarm threshold was checked every 2 min.The current consumption profile for a whole measurement cycle using the customized D-shuttle is depicted in Fig. 7.The firmware data flow is summarized in Fig. 8.In the first 2 s, the MCU wakes up and performs the system-initialization.The initialization phase occurs only once in the operating time of the device.
Afterwards, the devices try to join the LoRa network.In this example, the LoRa initialization phase takes around 14 s.The shock sensor is necessary to avoid spurious signals.Three sets of measurements are performed per transmission time window.For a 6 min window, measurements are carried out every 120 s.After each period of 120 s, the MCU wakes up, reads the counts from the radiation sensor and checks whether the alarm threshold has been reached (note the sharp 1 mA peaks in Fig. 7).If so, the cycle is interrupted and an alarm is sent to the supervision system.In Fig. 7        The dosimeters were coupled to a Microchip RN2903 LoRa transceiver connected to an ESP32 board and an ANT-868-JJB-ST LoRa antenna.We identified the ESP32 Bluetooth WiFi combo (Espressif Systems) as the best available option due to its high performances and ultra-low power consumption.The communication boards were powered by a 3.7 V Li-Ion rechargeable battery with a capacity of 3.4 Ah, while the radiation sensors were powered by a 3 V coin type battery.A conceptual diagram of the master is shown in Fig. 10.For the slaves, we used the multi-protocol wireless module of the ESP32 board that provides WiFi connectivity.Radiation measurements from the slaves were broadcasted synchronously to all the receivers in proximity, i.e. a slave does not synchronize its clock to the master but keeps sending the data until the data is received, or the maximum attempt time of 60 s is exceeded [45].In the same way, the WiFi receiver of the master is ready to receive the data over 60 s.

IV. MASTER-SLAVE VS ALL-MASTER MODEL
If after this time the communication is not established, the data packet is lost, and the slave needs to wait for the next scheduled transmission.This transmission method was chosen to avoid the desynchronization among devices over time.The configuration of the LoRa physical layer is summarized in Table II (Conf.1) [46].It is important to notice that the configuration of the LoRa physical layer has a direct impact on the communication range, sensitivity, energy efficiency as well as on the packet reception efficiency [22], [47]- [49].In this study we used a bandwidth (BW) of 125 kHz, which is the narrowest BW value that can be set by the RN2903 module.Within this set of experiments the chosen spreading factor (SF) is 7.The SF, that ranges from 7 to 12, is a key parameter in LoRaWAN and it is related to the data rate, i.e. number of chirps per second.The optimal value of the SF depends on the environmental conditions and affects the range of the transmission and the energy consumption.The aim of using a SF of 7 is to ensure the highest sensitivity and a low communication range.A higher spreading factor, for example a SF value of 12, will provide better coverage at the expense of an increased power consumption.The frequency channel was set to the 868.5 MHz band and the transmission power to 14 dBm, which are the default values.The coding rate of a forward error correction code is the proportion of the transmitted data-stream (bits) that is useful, and it is related to the time-on-air.The smaller the coding rate, the higher the time-on-air of the transmission.During our experiment, the coding rate was set to 4/5 and used by the LoRa modem to protect against interference.
In the container, each sensor was housed in a plastic water-  11 shows the packet reception ratio (prr) of the five masters.The all-masters set-up showed a high prr close to 1, except for one master that showed a lower transmission efficiency due to an unexpected battery voltage drop during the measurements.On the other hand, the masterslaves configuration experienced a packet loss of 13 %, having a significant impact on the efficiency of the system due to the fact that when the master fails, no information from the entire container is registered until the next scheduled transmission.
A faulty master in the all-masters configuration will have, on the other hand, a minimum impact on the monitoring system.Fig. 11: Packet reception ratio (prr) for the five masters, where master-5 is the device from the master-slaves configuration.
In addition to the data transfer efficiency, we also measured the power consumption of the different end-devices.
Results show that data transfer from the slaves to the master broadcasting a WiFi signal is fast, leading to a low power consumption, 93 % less consuming than LoRa.Values were calculated over a full cycle, i.e. from deep-sleep to deep-sleep assuming one transmission per hour.However, since there is no synchronization between master and slaves, the slaves usually perform several attempts before the data is received by the master, entailing an increase in the final power consumption on both slaves and master.Fig. 12 shows the total energy consumption per cycle for the two types of masters.As can be seen, the energy consumption per cycle of an independent master is 0.5 mAh, instead of 1.05 mAh measured for the 454 master in the master-slaves configuration.This is because the 455 master in the master-slaves model needs more time to receive 456 the data from all the slaves, read its own data and transfer the 457 different data packets consecutively to the LoRa server.This 458 time difference is clearly visible in Fig. 12.Assuming a battery 459 of nominal capacity of 2.5 Ah and one data transmission per 460 hour, we would expect an increase of the master's battery 461 lifetime of more than 100 days with respect to the master-462 slaves model (estimated battery lifetime of 204 days and 98 463 days, respectively).The results reported in this section showed 464 that an all-masters configuration is a better solution.Moreover, 465 with the new communication board (see Section III), the 466 overall power consumption has been reduced to hundreds of 467 µAh, allowing for a battery lifetime for the three types of 468 sensors of around 3 years.469 Fig. 12: Comparison between the measured energy consumption per cycle for a master device from the master-slaves model and an independent master (all-masters configuration).

471
We carried out a series of range tests to evaluate the 472 LoRaWAN network coverage at CERN.The goal of the tests 473 was to verify that the main areas where the waste contain-474 ers are placed have a good coverage with low interference, 475 good building penetration and low path loss, enabling high 476 transmission efficiency with good signal quality and signal-to-477 noise ratio.The packet reception efficiency inside and outside 478 the metallic waste container was also evaluated.The results 479 reported in this paper have also been useful to assess the range 480 and coverage of the CERN LoRaWAN network.

481
For this experiment, we used five NI-R02 radiation sensors.482 It should be noted that the performance of the LoRa signal 483 are independent of the sensor and therefore similar results 484 are expected with both the D-shuttle and the BG51 radiation 485 sensors.For the measurements, we used the physical layer 486 parameters as indicated in Table II, with the settings reported 487 in Conf. 2. Devices were programmed to transmit a 41-byte 488 data packet every minute (30-bytes of sensor data) with a 489 transmitting power of 14 dBm.Since the sensors are stationary 490 with respect to the waste containers, which are in a relatively 491 fixed position (variations of 50 m radius), the ADR (Adaptive 492 Data Rate) was enabled [50].Moreover, the uplink messages 493 were scattered over time in order to avoid the over-saturation 494 of the network.The LoRaWAN configuration used during this experiment does not comply with the current frequency regulations of the CERN LoRaWAN network, which impose a maximum of 6 uplink messages per hour.However, at the time of the test, only a few dozen devices were using the CERN LoRa network and our system did not increase the number of collisions.The final W-MON configuration is summarized in Table II Conf Fig. 13 summarizes the results of the data transfer obtained at the seven test points for the five end-devices.As can be seen, the packet reception ratio is overall very good with a success rate of 100 % for almost all devices at the different test points.A slightly lower prr of 0.92 was measured for device 3 at the test point 6 for no particular reason.A larger spread of the prr between devices was observed at point 7, at 700 m from the closest gateway, but the results remain acceptable with a prr above 0.97.It is worth mentioning that the occasional inefficiency in the data packet transmission is expected within the LoRaWAN standard.For W-MON, we use an adaptive data rate (ADR) so that the end-devices are able to automatically increase the spreading factor if the transmission with a lower spreading factor fails.Nonetheless, the frequency of the transmissions set to one minute for this particular experiment is not optimal and can increase the number of collisions between devices dropping the number of receiving packages.This is of critical importance as the number of end-devices significantly increases.During normal operation of the W-MON system, the devices are configured according to Conf. 3 in Table II, with a frequency of transmission of one hour.This, together with the LoRa orthogonality [16], the 541 ADR and the scattered of transmission over time make the 542 collisions highly unlikely, even for a high number of devices.543 Fig. 13: Packet reception ratio (prr) per device at the different test points.
Fig. 14 shows the average packet reception ratio per gateway 544 at the different test points.As expected, a higher success rate 545 was obtained when the distance to the gateway was reduced.546 For example, gateways located at less than 700 m from the 547 devices presented a prr close to 1 (100 % success rate).A 548 prr below 0.6 was obtained for gateways located at more than 549 1 km.At distances between 700 m and 1 km, the success 550 rate was of 85 %.This applies for both outdoor gateways A 551 and B (see Table IV).The effect of outer and inner walls on 552 the prr is illustrated in the results of gateway C. Gateway C, 553 located inside the heavily-shielded CHARM facility [51], had 554 a prr close to 1 when the devices were close to the facility and 555 with an open line of sight (no obstacles between the devices 556 and the gateway).At points 1, 2 and 5 the prr was slightly 557 lower due to the increased presence of building.At distances 558 over 1 km, the loss probability significantly increases, being 559 even of 100 % for some cases.At point 7, located outside 560 the CERN premises, the prr is close to 1 thanks to gateway 561 A, placed at the highest point at CERN.Moreover, a few 562 packets were surprisingly received by gateway E located at 563 7 km from the test point.Finally, the lower prr observed by 564 the outdoor gateways at point 4 is due to the more dense urban 565 environment that surrounded the end-devices with a larger 566 number of obstacles and buildings.It should be noted that in 567 Fig. 14 some data packets were received by several gateways 568 at the same time.

569
Besides the packet reception ratio, the RSSI and the Signal-570 to-Noise ratio SNR were also analysed [52].Both RSSI and 571 SNR are important parameters to determine the strength and 572 quality of the LoRa signal and their evaluation can be very 573 useful in the final deployment.Fig. 15a shows the average 574 RSSI of all received packets per device at the seven test points 575 for the closest outdoor gateway (gateway A for points 6 and 7, 576 gateway B for points 1 to 5) (gateways C, D and E were ex-577 cluded from this analysis due to the very low prr at some of the 578 test points).The average RSSI per device received by gateway 579 B is depicted in Fig. 15b.Theoretically, the RSSI decreases 580 as the distance between gateways and end-devices increases.581 However, other parameters such as the location and height 582

VI. CONCLUSION
This paper presents the implementation of an interconnected network of gamma radiation sensors for an IoT-based environmental radiation monitoring system.The first implementation of an IoT LoRaWAN distributed network for real-time remote monitoring of radioactivity in metallic waste containers is presented in this document.The effects of a metallic container on the LoRa packet reception efficiency are also evaluated for the first time.The end-device consists of a highly sensitive and compact gamma radiation sensor coupled to an ultralow power electronic board with custom-designed hardware and software for long-range low-power LoRa wireless data transmission.The end-devices are installed in metallic containers for ordinary waste in sets of eight devices per container, offering continuous monitoring of the radiation levels inside the containers, providing identification and early warning of a possible radiation release event and thus, overcoming the limitations posed by the manual radiological controls.The radiation measurements are periodically sent to the CERN LoRaWAN network server that includes ten outdoor and one indoor gateways.The network coverage, signal quality, signalto-noise ratio as well as the packet reception efficiency have been evaluated within the scope of the W-MON project.For these tests, we used five end-devices placed at seven different locations around the CERN Meyrin site.The devices were in a car during the tests.Results showed that all areas where the waste containers are placed, have a high coverage range with low interference and packet lost.A loss in the packet reception ratio of 10 % and 12 % is foreseen when installing the enddevice inside and under the containers.Real-time monitoring, data visualization, data storage, data processing, status control of the devices and alarm notification is possible thanks to a robust and reliable end-to-end data infrastructure that has been developed before the final integration into REMUS, the overall CERN Radiation and Environment Monitoring Unified Supervision service.
The current W-MON pilot network includes three waste containers with a total of 24 nodes (eight sensors per container) sending data every hour to the network.Three different types of radiation sensor are currently under investigation and hence, each container has been equipped with a specific type of device.The three containers will be operational for several months and subjected to real operational conditions.The scope of the tests is to evaluate the performance of the three dosimeters over a long time period in terms of sensitivity, power consumption, data transmission efficiency, robustness, stability, and reliability, to evaluate the capability as an environmental radiation monitoring system, to establish the detection limit for the radiological classification of potentially radioactive items and to implement the detection criteria into REMUS.

Finally, the conclusions
and future steps are summarized in Section VI.II.W-MON WIRELESS COMMUNICATION TECHNOLOGY.WHY LORA?Currently, the radiological controls need to be performed over more than two hundred containers for ordinary waste, located outside buildings where there is a risk of an accidental disposal of radioactive material (e.g.close to accelerator access points).This implies that the containers are distributed over a wide area covering hundreds of hectares.The containers are placed outdoors, surrounded by buildings and, occasionally, by heavily shielded facilities.Extensive tests and simulations showed that the best sensor arrangement implies eight sensors per container in order to provide a full coverage of the inner volume with the required sensitivity, while ensuring cost-effectiveness (see [1] for details).Consequently, due to the large number of devices and the scale and diversity of deployments, the wireless technology used for the W-MON IoT infrastructure needs to be cost-effective and provide wide coverage.The signals should be able to penetrate buildings and co-exist with many other devices.Moreover, the sensors must be battery powered and operate for several years with minimal maintenance.

152A.
System architecture and design 153 The W-MON IoT infrastructure, depicted in Fig. 1, relies 154 on two types of devices: the end-devices or nodes, arranged 155 in arrays of eight devices per container, and the gateways.156 167
224additional indoor gateways to cover the LHC tunnel.It should 225 be emphasized that the number of gateways can be easily 226 increased to meet a greater capacity as may be required in the 227 future.Particularly, due to the increasing number of devices using LoRa, some extra outdoor gateways will be installed at critical locations on the Meyrin and Prévessin sites.

Fig. 3 :
Fig. 3: Maps of the CERN (a) Meyrin and (b) Prévessin sites.Part of the accelerator complex is shown in (c).The blue circles indicate the location of the LoRa gateways.The letters A, B, D and E illustrate the position of the outdoor gateways, while the letter C shows the indoor LoRa gateway placed inside CHARM (CERN High energy AcceleRator Mixed field/facility).The black circles in (a) show the seven test points.

Fig. 5 :
Fig. 5: Customized D-shuttle radiation sensor soldered onto the intermediate board and connected to the communication board.The device is hosted in a IP67 plastic box.
This time can vary between 1 s to 60 s depending on the quality of the connection.If the connection does not succeed within 180 s, the device enters in sleep mode for one hour.This cycle is repeated n-configurable times.After the third attempt, the devices will try to connect every 60 s instead of every 180 s.If the device does not succeed to connect after these n attempts, it enters in sleep mode for two hours before retrying.Identical steps are followed if the network is not available before a transmission.The initialization and LoRa activation phases are represented by the label BOOT in Fig. 7. Once the connection is established, the end-devices enter in sleep mode and start measuring the radiation levels.The time period the device is in sleep mode is indicated as tsleep in Fig. 8.The sleep current is around 142 µA.For the other two sensors, the sleep current while measuring is 192 µA and 207 µA for the NI-R02 and BG51, respectively.The power consumption of the end-nodes in sleep mode is 16 µA, 38 µA and 71 µA for the BG51, D-shuttle and NI-R02, respectively.The higher overall energy consumption of the BG51 is due to the addition of an external shock sensor (3-axis digital accelerometer LIS331DLH from STMicroelectronics).
, no threshold has been triggered.At the end of the cycle, packets are sent via LoRa and the MCU goes back to sleep until the next measurement period.The final cycle phase, which includes sensor data reading, alarm threshold check, LoRa data transmission and data writing in the flash memory, takes around 4 s with an energy consumption of 9.42 µAh.After the LoRa transmission phase (LoRa TX in Fig. 7), the end-devices enter again in sleep mode and start a new measurement cycle.The measured energy consumption per cycle for a 6 min data transmission is 32 µAh (see Fig. 9).Results for different measurement periods are summarized in Table III.We can see that the wireless LoRa transmission (LoRa TX) current consumption is negligible, whereas the sensor reading while in sleep mode contributes the most to the current consumption, being in any case low power consuming.The estimated power consumption for the three types of end-devices per cycle and for one hour measurement 357

Fig. 7 :
Fig. 7: Measured current consumption of a customized Dshuttle LoRa node over a 360 s cycle.The inside plot is a zoom on the LoRa transmission phase.The 1 mA spikes correspond to the periodic alarm checks.The low amplitude spikes correspond to the wake up times of the external watchdog.

Fig. 8 :
Fig. 8: Firmware data flow chart.The device enters in sleep mode while measuring for a certain time period designated as tsleep.This time interval depends on the configuration.For the power consumption measurements, tsleep was 120 s.

Fig. 9 :
Fig. 9: Measured energy consumption of a customized Dshuttle LoRa node per 6 min duty cycle.

358A
first experiment was carried out in order to test the two 359 communication models simultaneously: master-slave and all-360 master (see Section II).A pilot waste container was equipped 361 with a fully operational monitoring system.The container 362 integrated eight devices: three slaves and five masters (one for 363 the master-slaves configuration).At the time of the test, the electronic board described in Section III was not yet developed and the CERN LoRaWAN network was under deployment (see Section II-B).Therefore, the end-devices consisted of a customized D-shuttle personal dosimeter properly modified to include both WiFi and LoRa communication capabilities.
proof box and protected by a light metal shield.The experiment lasted one week during which the container was emptied according to the standard garbage collection procedure.Data from the three slaves were broadcasted every hour via WiFi to the master, which collected all the data and forwarded them to the database (IEEE 802.11 b/g/n protocol, frequency 2.4 GHz, up to 150 Mbps).The master also embedded a radiation sensor.Similarly, data from the other four LoRa transceivers acting as individual masters were sent every hour to the database.For the gateway, we used a MultiConnect Conduit model MTCDT-210A.At all times, the gateway was located indoors at a maximum distance of 50 m from the container.All devices were configured to send a 22-byte data packet every hour.Fig.
. 3, which implies a payload of 41 bytes sent every hour with ADR enabled.The data were directly collected from MQTT giving access to the packet payload, the Received Signal Strength Indicator (RSSI) and the Signal-to-Noise ratio (SNR), as well as to the gateway information such as the SF, coding rate, etc.The end-devices were located at seven points around the CERN Meyrin site (see Fig. 3 (a)).The number and the position of the test points were decided based on various criteria such as the actual position of the waste containers, the network coverage, and the relevance of the results.A similar test was carried out on the CERN Prévessin site but the results are not reported in this paper because of their similarity.Table IV summarizes the distance between the test points and the gateways.Gateway D is not included because it did not receive any uplink message during this specific study.The end-devices were in a car during the tests.At each point a minimum of 30 transmission attempts were carried out.

Fig. 14 :
Fig. 14: Average packet reception ratio (prr) of the different gateways at the seven test points. 3 615and TableIV).As expected, a packet reception efficiency of 616 100 % was measured with the devices placed outside and on 617 top of the container.A reduction of around 10 % and 12 % was 618 obtained with the radiation sensors placed inside and under the 619 container, respectively.It can be concluded from these tests 620 that the Meyrin site at CERN has a good LoRa coverage up 621 to 1.7 km with a good signal quality and a packet reception 622 efficiency of approximately 90 % being suitable for the W-MON application.

Fig. 15 :
Fig. 15: (a) Average RSSI of all received packets per device at the seven measurement points for the closest gateway (excluding gateway C) and for gateway B (b).

Fig. 16 :
Fig. 16: (a) Average SNR of all received packets per device at the different test points for the closest gateway (excluding gateway C) and for gateway B (b).

TABLE I :
Location and height of the LoRa gateways.

TABLE II :
Settings of the LoRa parameters for different configurations.Adaptive data rate period is: 159.80 µAh, 207.29 µAh and 221.08 µAh for the 350 D-shuttle, NI-R02 and BG51, respectively.For two batteries 351 of nominal capacity of 2.6 Ah and the standard W-MON 352 data configuration (Conf.3 in TableII), which includes one 353 41 byte data transmission packet per hour, and assuming a 354 simple linear battery model, we expect a battery lifetime of 355 around 3.7 years for the D-shuttle, 2.9 years for the NI-R02 356 and 2.7 years for the BG51 radiation sensors.

TABLE III :
Measured current and energy consumption of a customized Dshuttle LoRa node for the different phases of the duty cycle assuming one LoRa transmission per hour.

TABLE IV :
Distance in meters between the test points and the LoRa gateways.