Savio Sciancalepore

Mališa Vučinić

Giuseppe Piro

Gennaro Boggia

Thomas Watteyne

Link-layer Security in TSCH Networks: Effect on Slot Duration

The IEEE802.15.4e-2012 standard is widely used in multi-hop wireless Industrial Internet of Things (IIoT) applications. In the Time-Slotted Channel Hopping (TSCH) mode, nodes are synchronized, and time is cut into timeslots. A schedule orchestrates all communications, resulting in high reliability and low power operations. A timeslot must be long enough for a node to send a data frame to its neighbor, and for that neighbor to send back an acknowledgment. Shorter timeslots enable higher bandwidth and lower latency, yet the minimal timeslot duration is limited by how long link-layer security operations take. We evaluate the overhead of link-layer security in TSCH networks in terms of minimal timeslot length, memory footprint, and energy consumption. We implement full link-layer security on a range of hardware platforms, exploring different hardware/software implementation strategies. Through an extensive measurement campaign, we quantify the advantage of hardware accelerations for link-layer security, and show how the minimal duration of a timeslot varies between 9 ms and 88 ms for the most common configuration, depending on hardware support. Furthermore, we also highlighted the impact that the timeslot duration has on both high-level application design and energy consumption.

INTRODUCTION

The Internet of Things (IoT) is generally envisioned as a networked system of smart interacting objects (i.e., sensors, machines, vehicles, smart phones, tablets, etc.) [START_REF] Hersent | The Internet of Things: Key Applications and Protocols[END_REF]. According to recent forecasts of leading companies of the sector [START_REF] Evans | The Internet of Things, How the Evolution of the Internet Is Changing Everything[END_REF]- [START_REF] Emmerson | M2M: the Internet of 50 Billion Devices[END_REF], around 50 billions devices are expected by 2020 to be part of the IoT. Furthermore, the introduction of the IoT into the manufacturing environment is leading to the emerging Industrial Internet of Things (IIoT), leveraging a class of low-power wireless networks used in critical applications such as industrial process monitoring and automation. These networks are receiving significant attention from standardization bodies, and a new wave of IIoT products is hitting the market [START_REF] Xu | Internet of Things in Industries: A Survey[END_REF].

A cornerstone technology for the IIoT is the Time-Slotted Channel Hopping (TSCH). TSCH networks were introduced in 2006 in the Time Synchronized Mesh Protocol (TSMP) [START_REF] Pister | TSMP: Time Synchronized Mesh Protocol[END_REF]. The core of this proprietary solution was standardized in WirelessHART [START_REF]WirelessHART Specification 75: TDMA Data-Link Layer[END_REF] in 2007 and in the IEEE802. 15.4e TSCH amendment [8] in 2012. TSCH is becoming a key enabling technology for the IIoT. Tens of thousands of TSCH networks are operating today [START_REF] Watteyne | Technical Overview of SmartMesh IP[END_REF]. Furthermore, it is receiving lots of attention from the standardization community, for example through the IETF 6TiSCH working group [START_REF] Dujovne | 6TiSCH: Deterministic IP-enabled Industrial Internet (of Things)[END_REF], and widespread adoption in happening [START_REF] Emmerson | M2M: the Internet of 50 Billion Devices[END_REF].

In TSCH networks, all nodes are synchronized, and the time is cut into timeslots. During a timeslot, a node sends a frame to its neighbor, and that neighbor sends back a link-layer acknowledgment indicating the successful reception. Specifically, the whole communication is orchestrated by a schedule which indicates, to each node, what to do in each slot: transmit, listen or sleep. In general, it is preferable to have a time slot as small as possible: the shorter the timeslot, the lower the latency and the higher the throughput of a network. However, its value must be minimized by taking into account the computational capabilities actually offered by a real platform, which define the amount of time required to correctly execute all the operations triggered by the aforementioned communication schedule (more details are provided in Section 3).

In the IIoT context, security is paramount. As with all networking solutions, security happens at all layers of the protocol stack. At the link layer, all frames are secured: they can be authenticated and/or encrypted, using the mechanisms standardized in [8]. Securing and unsecuring a frame, as detailed in Section 3, are complex and potentially timeconsuming operations. Moreover, different platforms have different hardware capabilities: on some, linklayer security can be accomplished using hardware support; on others, these operations need to be done in software because of the lack of hardware accelerators. Anyway, when security procedures are integrated in the TSCH communication schedule, a further computational overhead is introduced and the (minimum) timeslot duration is expected to increase as well, due to the additional time needed to secure/unsecure frames.

Starting from these premises, the present contribution wants to answer the following question: How much shorter can a timeslot be?

At the time of this writing, several contributions already investigated the effects of security operations in IoT systems on system capabilities [START_REF] Daidone | On Experimentally Evaluating the Impact of Security on IEEE 802.15.4 networks[END_REF]- [15]. Nevertheless, for the best of authors knowledge, they only focus on the legacy IEEE802. 15.4-2011 [16] and no studies on IIoT networks based on TSCH are yet available (TSCH was not present in the legacy IEEE802.15.4-2011 standard, while it was introduced in the IEEE802.15.4e amendment, in 2012, and maintained in the latest version of the standard, that is IEEE802.15.4-2015 [START_REF]IEEE Standard for Low-Rate Wireless Personal Area Networks (WPANs)[END_REF]).

To bridge this gap, this work aims at experimentally measuring the overhead of link-layer security in TSCH networks, on the minimal duration of a timeslot and on the memory footprint of the implementation. It is important to remark that we do not propose a new link-layer security mechanism. On the contrary, we would deeply investigate the impact that the one already proposed by the IEEE802.15.4e amendment, and maintained in IEEE802.15.4-2015, has in real IIoT systems. The scientific contribution of this articles is four-folded:

-We discuss the security functionalities in TSCH networks, the communication schedule described in the IEEE802. -We conduct an exhaustive experimental study and measure that the minimal value of the timeslot duration is between 9 ms and 88 ms (for the most common security level, described in Section 3.2), across the different platforms and strategies. -We describe the impact that the minimum timeslot has on both high-level application design and energy consumption.

The remainder of this article is organized as follows. Section 2 lists the most closely related works. Section 3 introduces the link-layer security mechanisms available in IEEE802.15.4. Section 4 discusses our different hardware and software link-layer security implementations, on both older and state-of-the-art platforms. Section 5 presents the experimental results, alongside further considerations on high-level applications design and energy consumption. Finally, Section 6 concludes this article.

RELATED WORKS

Although this article is not the first to evaluate the overhead of security in IEEE802.15.4 networks, it is, to the best of our knowledge, the first work that focuses on security in the IEEE802.15.4e TSCH amendment. This section lists the most closely related works.

The Advanced Encryption Standard (AES)-CBC-MAC Mode (CCM) scheme can be used at different layers of the protocol stack. For instance, in [START_REF] Vucinic | OSCAR: Object Security Architecture for the Internet of Things[END_REF] it is used for application-layer security. [START_REF] Keoh | Securing the Internet of Things: A Standardization Perspective[END_REF], [START_REF]AES-CCM Cipher Suites for Transport Layer Security (TLS), Internet Engineering Task Force Std[END_REF] and [START_REF]AES-CCM Elliptic Curve Cryptography (ECC) Cipher Suites for TLS, Internet Engineering Task Force Std[END_REF] further discuss its suitability for the TLS/DTLS protocols at the transport layer. In [START_REF] Rantos | IPsec over IEEE 802.15.4 for Low Power and Lossy Networks[END_REF] and [START_REF]Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)[END_REF] it is used at the network layer of an IoT-compliant protocol stack. Finally, in [START_REF] Raza | Secure Communication for the Internet of Things -A Comparison of Link-Layer Security and IPsec for 6LoWPAN[END_REF][START_REF] Raza | Securing Communication in 6LoWPAN with Compressed IPsec[END_REF] it is used at the link layer.

In these last works, the authors show, by experimentation, that the hardware support provided by different platforms can be used to significantly speed up the execution of cryptographic primitives.

[13] studies the performance of the AES-CCM at the link layer, and compares it to other well-known cryptography schemes. The authors show that, even though AES is not the most efficient block cipher in terms of code-size and time performance, its wellknown security properties, as well as the possibility to perform it in hardware, makes it the most suitable solution. The work presented in [START_REF] Law | Survey and Benchmark of Block Ciphers for Wireless Sensor Networks[END_REF] evaluates the impact that cryptographic algorithms have on IoT resources (i.e. memory, processing, energy). It demonstrates that the Rijndael algorithm, which is the AES scheme, is one of efficient ciphers for IoT devices (as other block ciphers), offering a good compromise between code-size and cycle-count.

Several works discuss the advantages of hardware acceleration for security operations. The first contribution that highlighted the performance gain offered by hardware accelerators in CC2420-based platform (i.e. Crossbow MICAz and MoteIVs TmoteSKY) was [START_REF] Healy | Analysis of Hardware Encryption Versus Software Encryption on Wireless Sensor Network Motes[END_REF]. In [START_REF] Hamalainen | Efficient Hardware Implementation of Security Processing for[END_REF], the authors describe a compact and energy-efficient hardware implementation of IEEE802.15.4 security, and show its advantage in terms of execution speed and energy consumption. In [START_REF] Huai | An Energy-Efficient AES-CCM Implementation for IEEE802.15.4 Wireless Sensor Networks[END_REF], the authors design an energy-efficient hardware architecture for AES-CCM for IEEE802.15.4 networks. This work is completely integrable in the current article, as it provides an efficient way to perform AES-CCM. [START_REF] Otero | AES Hardware-Software Co-design in WSN[END_REF] evaluates hardware, software, and hybrid implementations of the AES encryption engine on IoT micro-controllers, along with a discussion about the tradeoffs between energy, throughput of the hardware module, memory footprint, and battery lifetime. Nevertheless, authors do not discuss the integration of AES cryptography algorithm with IEEE 802.15.4(e) security processing, as well as the impact derived by the adoption of such solutions on the overall network operation. All of these works are perfectly integrable with the current article, and can be effectively used to further improve global network performances.

Similar to the current article, [START_REF] Daidone | On Experimentally Evaluating the Impact of Security on IEEE 802.15.4 networks[END_REF][START_REF] Chen | Performance Impact of and Protocol Interdependencies of IEEE 802.15.4 Security Mechanisms[END_REF][START_REF] Altolini | Low Power Link Layer Security for IoT: Implementation and Performance Analysis[END_REF][START_REF] Vucinic | Energy cost of security in an energy-harvested IEEE 802.15.4 Wireless Sensor Network[END_REF]15] analyze the impact of IEEE802.15.4 security processing on network performance. [START_REF] Daidone | On Experimentally Evaluating the Impact of Security on IEEE 802.15.4 networks[END_REF] analyzes the impact of the inclusion of link-layer encryption and authentication services on energy and memory consumption, on Tmote-Sky motes. However, only the hardware implementation is presented, timing issues are not considered, nor is the integration with TSCH. [START_REF] Chen | Performance Impact of and Protocol Interdependencies of IEEE 802.15.4 Security Mechanisms[END_REF] analyzes the impact of linklayer security processing on IEEE802.15.4 network performance (at the application layer) and on other protocol parameters. The authors focus on time and energy consumption. By simulations, they show that encryption and authentication affect the end-to-end application delay, but they do not include a discussion about the impact of linklayer security on the performance of the MAC protocol. [START_REF] Altolini | Low Power Link Layer Security for IoT: Implementation and Performance Analysis[END_REF] presents an implementation and performance evaluation of security functionalities at the link layer of IEEE802.15.4-compliant IoT devices. The authors present software and hardware implementations of security functionalities over the AVR XMEGA platform, evaluating memory and energy consumption produced by each one. Authors in [START_REF] Yan | Superframe Planning and Access Latency of Slotted MAC for Industrial WSN in IoT Environment[END_REF] propose a novel mathematical tool for analyzing the IEEE 802.15.4 network performance, considering a fixed slot duration. The included model is perfectly integrable in our work, and can be used to derive different MAC delays when security is enabled. Authors in [START_REF] Vucinic | Energy cost of security in an energy-harvested IEEE 802.15.4 Wireless Sensor Network[END_REF] energy harvesting devices and beacon-enabled mode. However, the impact of security processing over the TSCH mode of IEEE802.15.4e-2012 is not considered. An analytical evaluation of security overhead in the IEEE802.15.4 networks only is also presented in [15]. Several works focus on the new IEEE802.15.4e-2012 TSCH standard [START_REF] Watteyne | Technical Overview of SmartMesh IP[END_REF][START_REF] Stanislowski | Adaptive Synchronization in IEEE802.15.4e Networks[END_REF][START_REF] Palattella | On Optimal Scheduling in Duty-Cycled Industrial IoT Applications Using IEEE802.15.4e TSCH[END_REF]]. Yet, to the best of our knowledge, no work focuses on the performance of link-layer security.

LINK-LAYER

AES-128 and CCM*

The Advanced Encryption Standard (AES) is a block cipher which encrypts a sequence of plaintext bytes in blocks of 16 bytes, using a 128-bit key in its AES-128 variant. It uses a series of permutations and substitutions, and therefore executes fast when implemented in both hardware and software. CCM* is a "wrapper" cryptographic primitive around AES-128 that uses CTR mode for encryption and CBC-MAC for authentication. It encrypts and/or authenticates an arbitrarily long sequence of plaintext bytes (note that a theoretic upper bound on the message length for CCM scheme exists, but for practical purposes it can be considered arbitrarily long for IIoT technology) . When applied to a linklayer frame, this means that CCM* can encrypt the Medium Access Control (MAC) payload while keeping the MAC header intact. When used to authenticate a frame, CCM* calculates a Message Integrity Code (MIC) over the complete frame. This MIC is truncated to the desired length (4, 8 or 16 bytes), and appended at the end of the frame.

Each frame secured with a given key must use a different nonce. Encrypting two frames with the same nonce has severe consequences on security: plaintext of both frames may be easily recovered. By constructing the nonce with a monotonic counter, it is possible to ensure replay protection for two communicating nodes. We depict this in Fig. 1.

Link-layer Security in IEEE802.15.4-2011

Table I depicts the security levels of IEEE802.15.4. Levels differ in MIC length and whether encryption is applied on the payload or not. A higher security level induces a larger frame due to the longer MIC, but computational overhead stays the same. Each MAC frame can use a different security level. Local policies dictate if the security level of the received frame should be accepted or not. These conformance checks are a pre-requisite for the CCM* verification to be invoked.

Each secured frame carries an Auxiliary Security Header (ASH) with signaling information related to the key and nonce. In IEEE802.15.4-2011, the nonce is created from the address of the sender and the local frame counter that increments for each transmitted frame. The 4-byte frame counter must be signaled to the recipient, and is therefore included in the ASH. Because the recipient keeps track of the last frame counter it received from a given neighbor, frames are protected against replay attacks. Key signaling overhead varies with the key management scheme used, and can range from 0 bytes for implicit keying to 9 bytes. The total ASH overhead (not including the MIC) ranges from 5 to 14 bytes.

The upper layer sets the specific security level and the key to be used on beacon, command or data frames. However, Acknowledgment (ACK) frames in IEEE802.15.4-2011 do not support security and are always sent in clear. If successful, it removes the data frame from its transmission queue.

Changes introduced with

Eq. ( 1) indicates the timing constraints that the duration of those security operations put on the different TSCH timings. We denote dur(sec1) the duration of sec1.

               TsTxOffset ≥ dur(sec1)
TsTxAckDelay ≥ dur(sec2) + dur(sec3)

TsSlotDuration ≥ TsTxOffset + TsMaxTx+ TsTxAckDelay + TsMaxAck+ dur(sec4) (1
) Time synchronization in the network means that all nodes share the Absolute Slot Number (ASN): the number of slots which have passed since the network has started. The ASN is forever incrementing † . A common notion of time simplifies replay protection as a node does not need to maintain a frame counter for each of its neighbors. Instead, TSCH uses the ASN as a frame counter and omits its inclusion in the ASH, reducing the overhead by 4 bytes.

The use of ASN in the nonce implies that the sec1 operation can only be done once the ASN of the slot is known (see Fig. 2). In practice, this means that pre-calculating the sec1 operation is not possible. Operation sec1 includes the key lookup and First of all, the ENC security level is not supported anymore because it is not robust against trivial Man-In-The-Middle attacks. Secured and unsecured communications can coexist in the same network (for instance, in the case a device has not enough resources to manage security, it can use a Capability IE to inform its neighbors about this issue, thus asking them to switch to unsecured communications). Moreover, IEs and specific frames introduced by previous specifications (such as command frames defined in IEEE802.15.4e-2012) can be protected.

A different management of the frame counter is defined for the two possible network operation modes. In the legacy mode, it is an integer value associated to the device and to the key used to protect the communication. In the TSCH mode, instead, the frame counter is elided from the packet.

Few updates of both ongoing and incoming security functionalities have been added in order to take care of aforementioned amendments. Nevertheless, these changes do not modify the computational overhead introduced by security functionalities defined in IEEE802.15.4e-2012, which is instead mainly due to AES and CCM* operations.

LINK-LAYER SECURITY IMPLEMENTATIONS

This section describes the strategies we pursued to implement link-layer security and CCM* in IEEE802.

Platforms Used

Our goal is to quantify the overhead of linklayer security on a range of hardware platforms, and using different software strategies. Therefore, we choose to implement full link-layer security on platforms separated by a decade of hardware development: TelosB (in many ways obsolete but still very popular) and the OpenMote-CC2538 (a stateof-the-art platform).

TelosB. The TelosB mote [34] (designed in 2004) features an MSP430 microcontroller (16-bit architecture, 8 MHz maximum CPU speed, 48 kB flash, 10 kB RAM), and a CC2420 radio chip. The CC2420 radio [35] chip provides hardware acceleration for both AES and CCM*.

To execute an AES operation in hardware on the CC2420, one loads 16 bytes of cleartext into a buffer and a 16-byte key in a dedicated register, and issues a SAES command. This "atomic" AES operation takes 14µs, a number which does not account for the time to load the buffer and key from the micro-controller into the radio chip. Also, one has to execute this operation for each 16-byte block of a long frame.

To execute a CCM* operation in hardware on the CC2420, one sets the Security Control 0 and Security Control 1 registers to configure the security mode, the length of the authentication tag, the length of data to be authenticated but not encrypted, and the exact position where authenticated data starts. The nonce has to be loaded in the TXNONCE register and the frame into the transmission queue. Issuing a STXENC executes a CCM operation in the buffer; issuing STXON additionally transmits the frame. Considering a message of 119 bytes, a CCM operation takes 222µs.

The TelosB is a two chip-solution: the microcontroller and radio chips are connected by an SPI digital interface. Given the speed of this bus, it takes approximately 1 ms to transfer a full-sized frame between the chips. This adds a extra delay to the minimal timeslot duration.

OpenMote-CC2538. The OpenMote-CC2538 mote [START_REF] Vilajosana | OpenMote: Open-Source Prototyping Platform for the Industrial IoT[END_REF] (designed in 2014) is a state-of-the-art platform at the time to writing, which features a single-chip CC2538 solution. This chip contains both an ARM Cortex-M3 micro-controller (32-bit architecture, 32 MHz maximum CPU speed, 512 kB flash, 32 kB RAM) and a IEEE802.15.4-compliant radio. One immediate advantage of such a singlechip solution is that the micro-controller and radio chip share the same RAM memory; no time needs to be spent transferring a packet to/from the radio chip.

The CC2538 uses a single AES Control register to configure/trigger AES and CCM* operations in hardware. The AES module cuts the input bytes into 16-byte blocks and triggers the AES operation autonomously. When the operation finishes, the master controller generates a data done interrupt so the software can retrieve the encrypted data. The software sets the nonce, key and other CCM* configurations in the AES Control register.

A Direct Memory Access (DMA) modules takes care of feeding the AES and CCM* modules, without intervention from the software. This significantly speeds up the operation when compared to the CC2420. Encrypted/authenticated data is available directly in RAM memory, no (time consuming) SPI transfers are needed. Finally, the external 32 MHz crystal oscillator is used to clock the AES and CCM* hardware modules. This is possible because the AES cryptoprocessor can be clocked independently from the processor.

The AES algorithm executes at 18 Mbps ‡ . CCM executes at 12 Mbps, including the final operation of create the MIC. Thus, considering a single block of 128 bits, security operations are executed in 7µs for ‡ http://www.ti.com.cn/cn/lit/ug/swru319c/swru319c.pdf (Sec. 4.4) hardware software "hardware" (Sec. 4.3) hardware hardware the AES algorithm and 85µs for the CCM scheme. The CC2538 completes AES and CCM tasks faster than the CC2420.

OpenWSN. We use the OpenWSN implementation on both platforms. OpenWSN is an opensource implementation of a standards-based protocol stack for the IoT. Its protocol stack includes IEEE802.15.4e-2012 TSCH, 6LoWPAN, RPL and CoAP [START_REF] Watteyne | OpenWSN: a Standards-Based Low-Power Wireless Development Environment[END_REF].

We augment OpenWSN with link-layer security, implemented using three strategies: in software (Section 4.2), in hardware (Section 4.3), and a hybrid solution (Section 4.4). As shown in Table II, these strategies differ in whether they exploit hardware acceleration for AES and/or CCM*. The three strategies are detailed in the next sections.

Software Implementation

The "software" implementation strategy consists in implementing both AES and CCM* in software. We use a software AES implementation from Texas Instruments § , unmodified. This implementation is optimized for embedded devices, and features an execution time approximately 10 times shorter than a baseline AES implementation such as the one presented in [START_REF] Sciancalepore | Application of IEEE 802.15.4 Security Procedures in OpenWSN Protocol Stack[END_REF]. We implement CCM* from scratch. As indicated above, all software is available opensource.

In the software implementation, we purposely do not use the hardware acceleration for AES/CCM* offered by both platforms in order to be able to (1) quantify how much shorter the timeslot can be when using hardware acceleration, and (2) have an idea of the performance of a platform which does not have hardware acceleration.

Hardware Implementation

The "hardware" implementation strategy consists in exploiting hardware acceleration for both AES and CCM*. Both platforms offer AES and CCM* hardware support, and we use the techniques described in Section 4.1 in the implementation.

Even though the hardware executes the core of the security operation, software instructions are necessary to store security-related parameters in the § http://www.ti.com/tool/AES-128 correct location, disable or enable hardware interrupts, give the "go" signal for encryption/decryption operations, and fetch the output of the operation.

Hybrid Implementation

Many hardware platforms offer AES hardware acceleration, but not CCM*. To measure the overhead of link-layer security on those platforms, we adopt a "hybrid" implementation strategy in which we rely on the hardware for AES, but implement CCM* is software.

The hybrid implementation hence uses hardwareaccelerated AES block cipher. The rest of the CCM* algorithm, which includes CTR and CBC-MAC modes of operation, creation of plaintext and ciphertext is handled through software instructions.

EXPERIMENTAL RESULTS

This section presents the experimental results obtained on the implementations presented in Section 4. Section 5.1 details the experimental setup we use and the methodology we adopt to tune the different durations in the timeslot. Section 5.2 indicates the memory footprint of the implementations, for both flash and RAM memory. Section 5.3 presents the different durations measured on both platforms, across the three implementation strategies, and for all eight security levels. We also discuss the implication for IEEE802.15.4e TSCH networks. Section 5.4 discusses the energy consumption related to the three implementation strategies, and for all eight security levels. Finally, Section 5.5 provides further comments on the impact of timeslot duration on high-level application design.

Goals and Methodology

The goal of this experimental evaluation is to implement the three implementation strategies on both platforms, tune the timeslot duration to the minimal value obtainable given the duration of the link-layer security operations, and measure the different timings. Specifically, we want to answer the following question: How much shorter can a timeslot be if hardware acceleration is used? We also measure and report the memory footprint (the amount of RAM and flash memory required) and the energy consumption of the different implementation strategies.

The experimental setup consists of two nodes forming one network. One of the nodes is the root of the network, the other is a leaf node that attaches to the root. In each case, after loading the appropriate software on the nodes, we boot the root node and wait for the leaf node to synchronize to it. The root node is attached to a computer; from that computer we use the ping program to verify connectivity to the leaf node. ping allows us to choose the size of the payload sent in the ICMPv6 echo request/response packets; we choose it so that the resulting link-layer frame is always 127 bytes long (the maximum length for IEEE802.15.4-compliant nodes).

In OpenWSN, IEEE802.15.4e TSCH is implemented as a finite state machine. Different timings, illustrated in Fig. 2, cause the state machine to advance. TsTxOffset is an example timing: when it expires, the state machine kicks off the transmission of the frame. This means, at that point in the timeslot, all the operations for preparing the packet (including sec1) need to be complete. The OpenWSN implementation uses a 32-kHz counter to measure the duration of different phases of the IEEE 802.15.4e finite state machine. This allows us to measure the duration of the sec1, sec2, sec3 and sec4 operations, and verify the TsTxOffset, TsTxAckDelay and TsSlotDuration durations.

For each evaluated case, we "tune" the different durations in order to obtain the shortest possible timeslot. We start by setting TsTxOffset, TsTxAckDelay and TsSlotDuration to very high values, then reduce them. In all cases, these values must satisfy the constraints in Eq. ( 1). The different steps of the tuning procedure are illustrated in Table III. We first measure the duration of sec1, and reduce the value of TsTxOffset accordingly. According to the standard [8], TsMaxTx and TsMaxAck are set to 4.256 and 2.400 ms respectively. We then measure the durations of sec2 and sec3, and set the value of TsTxAckDelay accordingly. Similarly, we measure the duration of sec4 and tune TsSlotDuration.

We repeat this tuning operation for both platforms, using the three implementation approaches, and for each of the 8 security levels. There are hence 48 cases, discussed in the following sections.

Note that sec1, sec2, sec3, and sec4 have been measured by using the 32KHz counter available in the OpenWSN protocol stack. Now, considering that the variability of the amount of time needed to execute security operations is very lower than the resolution of this counter, obtained results (reported in the following subsections) appear as deterministic.

Finally, results related to the energy consumption are generated by considering the amount of energy consumed by TelosB and OpenMote-CC2538 platforms when they perform different operations in a timeslot (reference values are taken from their datasheets).

Memory Footprint

The memory footprint is the amount of flash ¶ and RAM memory that needs to be reserved for link-layer security. Fig. 3 and4 summarize the results. The security level does not impact the memory footprint, and is hence not presented.

Since the TelosB and OpenMote-CC2538 have both different processor architectures and compilers, and since different toolchains are used to build their software, comparing the absolute value of the memory footprint is not appropriate. Focusing on a single platform, instead, the analysis of both ROM and RAM footprints is useful to compare different link-layer security implementations. On the TelosB mote, link-layer security occupies between 7% and 15% of the available flash memory, and 30-40% of RAM memory. On the OpenMote-CC2538, it occupies 1.5-2.5% of flash and 8% of RAM. As can be expected, the footprint of the software (resp. hardware) implementation is the largest (resp. lowest).

In general, it is possible to observe that using hardware acceleration for link-layer security does not result in a drastically lower memory footprint. This is because (i) a software implementation of AES and CCM is relatively simple and (ii) even when hardware acceleration is used, software is still needed to drive the hardware.

On the TelosB mote, the number of instructions needed to control AES and CCM algorithms in hardware is the same. Therefore, the hardware implementation registers a reduction of the ROM footprint with respect to the hybrid implementation because part of the software related to CCM operations (e.g., instructions for CCM* vectors handling) is deleted.

On the OpenMote-CC2538, instead, the driver needed to control CCM operations in hardware has a ROM footprint that is quite similar to the amount of software used in the hybrid implementation. ¶ We use flash and ROM (Read-Only Memory) interchangeably.

Therefore, this platform seems to report the same ROM footprint when both hybrid and hardware implementations are used.

Minimal Slot Length

Figs. 5 and6 present the resulting TsTxOffset, TsTxAckDelay and TsSlotDuration durations after tuning procedure, for the TelosB and OpenMote-CC2538 platforms, respectively.

When the "software" implementation is used, TelosB and OpenMote-CC2538 executes security operations at different speeds of the CPU. For instance, TelosB runs at 8 MHz; OpenMote-CC2538 can run at a maximum speed of 32MHz. As a result, the software-based implementation of linklayer security in OpenMote-CC2538 will result in a timeslot duration reduced by a factor of 2 -3×.

The hardware implementation strategy results in a shorter slotframe than the software implementation. Depending on the security level, a hardwarebased implementation of link-layer security will result in a timeslot duration reduced by 3 -4×.

The difference in timeslot duration between "software" and "hybrid" implementation strategies reflects the advantage of having AES execute in hardware. Similarly, the comparison between "hybrid" and "hardware" implementations reflects the advantage of a hardware-based CCM*.

On slower platforms such as the TelosB (Fig. 5), the biggest gains are made by running AES in hardware.

The most common security level in TSCH networks (including WirelessHART and 6TiSCH) is ENC-MIC-32, i.e. frames are encrypted and a 4byte MIC is used for authentication. We highlight that security level in Figs. 5 and6. A full software implementation on an older platform such as the TelosB results in a minimal timeslot duration of 88 ms. Using hardware acceleration reduces the time duration by a factor of 4, down to 25 ms. Switching to a state-of-the-art platforms, which features both faster hardware implementation of AES and CCM*, and a single-chip architecture, allows the timeslot duration to be further reduce by a factor of more than 2, down to 9 ms. By using hardware accelerations in OpenMote-CC2538, it is possible to satisfy the target value of the timeslot duration reported by the standard, i.e., 10 ms [8]. In the other cases, this goal is not reached. Anyway, it is important to note that conducted tests considered the worst case, where the maximum size of the ASH is used (e.g. equal to 14 bytes). Now, considering that the higher the size of the ASH, the higher the computational overhead introduced by additional (security) lookup procedures,, all the results reported in Section 5 refer to the most complex network configuration requiring higher timeslot durations. Other configurations, instead, may require lower timeslot durations.

Energy consumption

Figs. 7 and 8 reports the amount of energy consumed by TelosB and OpenMote-CC2538, respectively, for the three implementation strategies, and for all eight security levels. These results have been estimated (not experimentally measured) by taking into account the energy consumption related to each phase of the timeslot (TX, RX and CPU idle), as reported by reference datasheets. Link-layer security brings to an increment of the per-slot energy consumption because: (i) additional operations are executed for protecting the transmitted packet and decrypting the corresponding ACK and (ii) the radio chip is in charge of transmitting more data due to the ASH and the MIC.

On the TelosB mote, hardware accelerators reduce energy consumption up to 27% (for the hybrid implementation) and 47% (for the hardware implementation). On the OpenMote-CC2538, instead, hardware accelerators leads to a gain of up to 58 % (for the hybrid implementation) and 66% (for the hardware implementation).

Moreover, OpenMote-CC2538 always emerges as the more energy-consuming platform.

Final considerations on high-level application design

To conclude, based on the results described in the previous Section, additional comments on high-level application design and energy consumption can be formulated.

As we have already anticipated in the Introduction, the shorter the timeslot, the higher the network throughput. Therefore, the provisioning of link-layer security inevitably brings to a throughput reduction. In addition, the message overhead produced by

where Ni, Aj, and Nts are the number of timeslots assigned to the i-th device for transmitting data, the maximum size of an application message due to the j-th security level , and the total number of timeslots available in a TSCH slot frame (i.e., a predefined number of timeslots that repeats over the time). For simplicity, Eq. ( 2 supported because they produce an uncontrolled increment of packet queue, thus bringing to a growth of packet losses (e.g., packets are lost at the transmitter side because is not enough space the queue).

CONCLUSION

This works evaluates the overhead of using linklayer security in IEEE802.15.4e Time Synchronized Channel Hopping (TSCH) networks. The challenge is that four link-layer security operations need to happen in a single timeslot: securing/unsecuring the data frame, and securing/unsecuring the acknowledgment. The duration of the link-layer securing/unsecuring operations hence directly impacts on the minimum duration of the timeslot. To increase the overall throughput of the network, and decrease the end-to-end latency, this duration should be as low as

We conduct a thorough experimental study, and measure the overhead of link-layer security across different generations of hardware, different hardware/ software implementation strategies, and different security levels in the IEEE 802.15.4 protocol. We use two popular off-the-shelf platforms, separated by a decade of hardware development: the older but still popular TelosB and the state-ofthe-art OpenMote-CC2538. All implementations are done on the OpenWSN protocol stack, and available open-source under a BSD license.

We show the benefits of hardware acceleration for two "atomic" link-layer security mechanisms: AES -a block cipher -and CCM* -a "wrapper" cryptographic primitive around AES. Overall, using hardware acceleration offers a 3 -4× reduction in timeslot duration. Using the latest generation hardware and full hardware acceleration allows a timeslot duration reduction of roughly 10×, from 88 ms on older hardware using a fully software implementation, down to 9 ms.

Figure 1 .

 1 Figure 1. CCM* allows every frame to be encrypted and/or authenticated.

  SECURITY MECHANISMS IN IEEE802.15.4 Link-layer security has been part of IEEE802.15.4 since its first revision in 2003. This section provides the necessary background by describing the underlying mechanisms AES and CCM* (Section 3.1), and how these are used in IEEE802.15.4-2011 (Section 3.2), IEEE802.15.4e-2012 (Section 3.3), and IEEE802.15.4-2015 (Section 3.4).

Figure 3 .

 3 Figure 3. ROM and RAM Footprint of the implementations for TelosB mote.

Figure 4 .

 4 Figure 4. ROM and RAM Footprint of the implementations for OpenMote-CC2538 mote.

Figure 5 .

 5 Figure 5. Minimum timeslot duration for the TelosB mote.

Figure 7 .Figure 8 .

 78 Figure 7. Energy consumed in a single timeslot for the TelosB mote.

Table I .

 I The security levels in IEEE802.15.4.

				mode	encrypted payload? MIC length
			MIC-32		NO	4 bytes
			MIC-64		NO	8 bytes
			MIC-128		NO	16 bytes
			ENC		YES	no MIC
			ENC-MIC-32		YES	4 bytes
			ENC-MIC-64		YES	8 bytes
			ENC-MIC-128		YES	16 bytes
	CCM* encryption on a potentially maximum length
	frame (127 bytes). Before the receiving node can
	transmit an ACK, it must verify the conformance
	of the frame against local security policies and
	decrypt/authenticate it (sec2). Finally, the node
	prepares and secures the ACK frame (sec3), which
	includes the time correction indication. Before the
	time correction can be applied on the transmission
	side (node A in Fig. 2), the ACK frame must
	pass the CCM* check and conformance verifications
	(sec4). The duration of the sec1, sec2, sec3 and sec4
	operations on different hardware platforms directly
	influences the minimum slot duration, which we
	evaluate experimentally in Section 5.
	3.4. Further amendments introduced with
		IEEE802.15.4-2015
	The	security	sub-layer	standardized	in
	IEEE802.15.4-2015	[17]	generally	integrates
	security services defined in both IEEE802.15.4-
	2011 and IEEE802.15.4e-2012. However, some few
	amendments have been introduced.

Table II .

 II Implementation Strategies.

	strategy	AES	CCM*
	"software"	(Sec. 4.2) software	software
	"hybrid"

Table III .

 III The different steps in the tuning procedure.

	dur(sec1)	measure
	TsTxOffset	tune to dur(sec1)
	TsMaxTx	set to 4.256 ms
	dur(sec2)	measure
	dur(sec3)	measure
	TsTxAckDelay	tune to dur(sec2)+dur(sec3)
	TsMaxAck	set to 2.400 ms
	dur(sec4)	measure
	TsSlotDuration tune to TsTxOffset + TsMaxTx + TsTxAckDelay +
		TsMaxAck + dur(sec4)

  Figure 6. Minimum timeslot duration for the OpenMote-CC2538 mote.each security level (i.e., Auxiliary Security Header plus MIC, if present) differently impacts on the effective amount of bytes that can be inserted, in each packet, by the application layer. Practically, the data generation rate, R, that a high-level application running on the i-th device could use should satisfy the following equation:

			Software implementation
			Hybrid implementation
			Hardware implementation
	Security	Software Implementation	Hybrid Implementation	Hardware Implementation
	Level
			TsTx	TsTx	minimal	TsTx	TsTx	minimal	TsTx	TsTx	minimal
			Offset	AckDelay	TsSlot	Offset	AckDelay	TsSlot	Offset	AckDelay	TsSlot
			[ms]	[ms]	Duration	[ms]	[ms]	Duration	[ms]	[ms]	Duration
					[ms]			[ms]		[ms]
	no security	1.15	0.67	6.71 1.15	0.67	6.71 1.15	0.67	6.71
	MIC-32	2.48	10.07	23.50 1.98	2.24	10.47 1.28	1.12	8.45
	MIC-64	2.51	10.19	23.65 2.14	2.36	10.77 1.31	1.19	8.72
	MIC-128	2.54	10.31	24.57 2.29	2.45	11.08 1.34	1.25	9.34
	ENC	2.31	3.20	16.51 1.77	1.51	9.86 1.28	0.98	8.24
	ENC-MIC-32	6.44	14.80	32.35 2.38	2.82	11.44 1.28	1.12	8.45
	ENC-MIC-64	6.57	14.86	32.50 2.41	2.94	11.78 1.31	1.19	8.72
	ENC-MIC-128	6.60	15.26	33.66 2.44	3.24	12.27 1.34	1.25	9.34
	R ≤	Ni Aj Nts TsSlotDuration	,

† The ASN is encoded on 5 bytes. With a 10 ms timeslot duration, the ASN value rolls over every 350 years.

ACKNOWLEDGMENTS

This work is supported by the PON project RES NOVAE funded by the Italian MIUR and by the European Union (European Social Fund), by the project BONVOYAGE, which receives funding from the European Union's Horizon 2020 research and innovation programme under grant agreement 635867, and by the project symbIoTe, which receives funding from the European Union's Horizon 2020 research and innovation programme under grant agreement 688156. The authors would like to acknowledge Luigi Alfredo Grieco, Kris Pister, Bernard Tourancheau, and all the people actively working in the IETF 6TiSCH working group for their guidance and input.

DATA DATA ACK sec 1


Thomas Watteyne
email: thomas.watteyne@inria.fr.

Ana Laura Diedrichs

Keoma Brun-Laguna

Javier Emilio Chaar

Diego Dujovne

Juan Carlos Taffernaberry

Gustavo Mercado

Ana Laura Diedrichs

Juan Carlos

PEACH: Predicting Frost Events in Peach Orchards Using IoT Technology

Keywords: Smart Agriculture, Precision Agriculture, Deployment, SmartMesh IP

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

In 2013, 85% of the peach production in the Mendoza region (Argentina) was lost because of frost. Because less fruit was produced in the region, 600,000 less work days were needed to process the harvest between November 2013 and March 2014, a reduction in work force of 10,600 people. Across the Mendoza region, frost caused a loss of revenue of 950 million Argentine pesos, roughly 100 million USD (at that time) in the peach business alone.

A frost event happens when the temperature is so low that the crops cannot recover their tissue or internal structure from the effects of water freezing inside or outside the plant. For the peach production, a critical period is when the trees are in bloom and fruit sets (August/September in Mendoza), during which the temperature needs to be kept above -3 C. Even a few hours below that temperature causes flowers to fall, preventing fruit to grow.

Because of the huge economic impact, countermeasures exist, but are expensive. Today, virtually all industrial peach orchards are equipped with a meteorological station that monitors temperature and humidity. Farmers need to deal with false positives (the countermeasure is applied, but there is no frost event) and false negatives (the meteorological station does not pick up a frost event happening in some part of the orchard).

What is needed is a dense real-time monitoring solution deployed in the orchard, feeding a frost prediction model. Having a meteorological station does not provide the measurement density needed. Frost events are micro-climatic: cold and hot air have a different density, wind blows irregularly between the trees, so different parts of the orchard are affected very differently by frost. What we build is a system with a large number of sensing points (air temperature, air relative humidity, soil moisture, soil temperature), at different elevations/depths, throughout the orchard.

Low-power wireless mesh networking technology has evolved significantly over recent years. With this technology, a node is the size of a deck of cards, is self-contained and battery-powered. When switched on, nodes form a multi-hop low-power wireless network, automatically. Off-the-shelf commercial solutions are available today that offer >99.999% end-to-end data reliability and over a decade of battery lifetime.

The goal of the PEACH project is to increase the predictability of frost events in peach orchards by using dense monitoring provided by low-power wireless mesh networking technology.

The main contributions of this article are:

• We provide a thorough, complete and "brutally honest" description of the design and deployment of a precision agriculture IoT system.

• We provide a methodology for deploying these networks.

• We contribute with open-source software to perform pre-deployment range tests, manage the network, and store/display sensor measurements and network statistics.

• We describe a complete turn-key solution for precision agriculture applications, built entirely from commercial off-the-shelf proven technology.

The remainder of this article is organized as follows. Section 2 provides the necessary background on how peach growth is affected by frost events, and the major impact frost has on the economy. Section 3 surveys low-power wireless technology used in environmental sensing applications, with a particular focus on SmartMesh IP. Section 4 introduces the hardware deployed in the PEACH project, and the initial range testing procedure used. Section 5 discusses the deployment methodology. Section 6 describes the backend system. Section 7 shows how the deployed network yields 100% reliability, 3+ years of battery lifetime, and <2 s end-to-end latency. Finally, Section 8 concludes this paper by listing the lessons learnt and discussing the roadmap of the PEACH project.

Peach Production and Frost

Peach (Prunus persica (L.) Batsch.) is a deciduous fruit tree, growing mainly in temperate regions. It has a rest period between vegetative cycles, saving growing organs from extreme winter frost. To leave winter dormancy, buds need to accumulate chill followed by heat, resulting in Spring flowering [START_REF] Chaar | Use of a correlation model for the determination of peach tree [prunus persica (l.) batsch.] heat and chilling requirement[END_REF]. Peach flower buds contains floral primordia, consisting of sepals, petals, androecium and gynoecium (see Fig. 1).

Spring frost events are one of the main limiting factors for the production of temperate fruit trees [START_REF] Chaar | Characterization of Peach [Prunus persica (L.) Batsch.] Cultivars for Frost Resistance[END_REF]. To develop into a fruit, a flower bud needs to bloom without frost damage, to later be successfully pollinated and fertilized, eventually causing fruit set. When the temperature drops below zero in Spring, the migration of water to intercellular spaces causes tension and breaks the cell membranes. This causes internal solutes to be lost and cells to die.

Fruit production mainly depends on the number of healthy flowers that resist subzero temperatures. Different peach cultivars have different levels of flower bud resistance to Spring frost, depending on the date of full flowering, the lethal temperature, and the flower density [START_REF] Chaar | Characterization of Peach [Prunus persica (L.) Batsch.] Cultivars for Frost Resistance[END_REF], see Fig. 2.

In Mendoza, Argentina, there are 14216 ha of peaches, including 5759 ha for fresh consumption [START_REF]Censo Frutícola Provincial 2010 Mendoza -Argentina[END_REF] and 8457 ha for the canning industry [START_REF]Censo Provincial de Productores de Durazno para Industria[END_REF]. During Spring 2013, a series of frost events (see Fig. 3) caused major damages in the peach production. 56% of the fruit production area was affected by frost. It is estimated that 85% of the peach production in the Mendoza region was lost. Because less fruit was produced, 600,000 less work days were needed to process the harvest between November 2013 and March 2014, resulting in a reduction in work force of 10,600 people. Across the Mendoza region, frost caused a loss of revenue of 950 million Argentine pesos, roughly 100 million USD (at that time) in the peach business alone [START_REF]Censo Frutícola Provincial 2010 Mendoza -Argentina[END_REF]5]). Active frost control is possible [START_REF] Food | of the United Nations[END_REF]. One option is to position heaters across the orchard, but the fuel used is a pollutant and is expensive. Over-plant sprinklers can also be used (latent heat is produced when the water from the sprinklers freezes), but installation cost is high and a lot of water is needed. Another option is to mix the warmer air above the orchard with the cooler air at ground level, causing an increase in temperature around the flowers. This can be done by vertical wind towers, or even flying a helicopter above the orchard. Regardless of the method used, it is expensive. It is therefore essential to be able to predict the frost event.

To predict a frost event, one needs to know the dew point. The problem is that the dew point depends on the relative humidity: at lower relative humidity, air temperature drops faster and to lower values. To predict the minimum temperatures -hence a frost event -one needs to observe the temperature at several locations across an orchard, at different elevations, since winds and foliage cause micro-climatic differences in the orchard. Using a single meteorological station in the orchard is not enough; the temperature and humidity it measures are not representative of the entire orchard.

To accurately characterize and predict frost events, what is needed are air temperature and relative humidity measurements at different locations across the orchard, at different elevations, as well as soil temperature and soil moisture at different depths. This data can then feed to a machine-learning algorithm to determine which features are important to predict frost events, and eventually build an early warning system.

Low-power Wireless Technology

The goal of the PEACH project is to retrieve data from different types of sensors deployed densely across a peach orchard. Because heavy machinery is used throughout the field, using wires to interconnect the sensors is not an option. We instead use low-power wireless mesh networks. Our requirement is that the security and reliability of those wireless networks must be equivalent to that of a wired network. Our target battery lifetime for the devices is "at least a year", the natural grow cycle of peaches.

This project is not a low-power wireless project, i.e. we need a technical solution that "just works". While very interesting research can be done with academic projects [START_REF] Mesas-Carrascosa | Open source hardware to monitor environmental parameters in precision agriculture[END_REF][START_REF] Budi | Optimisation in the design of environmental sensor networks with robustness consideration[END_REF] (there are many in the research field of low-power wireless), we need a product that is thoroughly tested, proven and commercially available off-the-shelf. We have selected SmartMesh IP, which satisfies our requirements. Section 3.1 introduces SmartMesh IP technology, Section 3.2 reviews related projects that use low-power wireless networks for environmental applications, Section 3.3 lists the goals of the PEACH project.

SmartMesh IP

SmartMesh IP, a product line from the Dust Networks group at Linear Technology1 fits the requirements listed above. Dust Networks is initially a spin-off company from the University of California at Berkeley, now the world leader in supplying low power wireless mesh networks for demanding applications. Over 50,000 SmartMesh networks are deployed today in applications including industrial process monitoring, city-wide parking management, building automation and remote environmental sensing.

The protocol stack implemented in SmartMesh IP devices is entirely standards-based, and includes standards such as IEEE802.15.4 "Time Synchronized Channel Hopping" (TSCH) and IETF 6LoWPAN [START_REF] Watteyne | Technical Overview of SmartMesh IP[END_REF]. A SmartMesh IP network is composed of exactly one manager and up to 100 motes. The manager serves as the gateway of the SmartMesh IP network, and is typically connected to a computer, itself connected to the Internet. A mote is a standalone device, typically battery powered, itself connected to sensors and actuators. The SmartMesh IP network offers bidirectional connectivity: the motes can send sensor measurements to the gateway (and from there to some server on the Internet), the server can send actions/configurations to the motes.

Security is built into the SmartMesh IP protocol stack around an AES-128 cipher, and cannot be switched off. A set of keys ensures confidentiality, integrity and authentication of the data. The SmartMesh IP network is operated in such a way that it offers wire-like reliability, with over 99.999% end-to-end reliability.

The motes in a SmartMesh IP network automatically and periodically generate "Health Reports", a series of counters and statistics to assess the overall health of the network. Three types of statistics are generated: internal counters of the mote (e.g. packet counters), the list of neighbors the mote is communicating with, and the list of neighbors the mote can hear but is not communicating with. A mote generates a complete set of health reports every 15 min. They are the base for assessing the performance of the network, as done in Section 7.

A SmartMesh IP network is fully synchronized, and time is split up into timeslots. A schedule orchestrates all communication in a SmartMesh IP network and indicates what to do in each timeslot: transmit, listen or sleep. How the schedule is built and maintained allows a clear trade-off between the amount of data generated by the sensors, the communication latency, and the power consumption of the motes.

The "Dust Networks SmartMesh Power and Performance Estimator" is a tool provided by Dust Networks2 that allows one to estimate the power consumption and latency of a SmartMesh IP network, given the topology and amount of data generated. A typical SmartMesh IP network offers over 99.999% reliability and over a decade of battery lifetime when motes are powered by a pair of AA batteries [START_REF] Watteyne | Industrial IEEE802.15.4e Networks: Performance and Tradeoffs[END_REF].

Related Projects

In recent years, low-power wireless is being used more and more by the scientific community for remote environmental sensing.

One community at the forefront of adopting lowpower wireless technology is the hydrology community. Bogena et al. highlight the potential of low-power wireless for measuring soil water content variability [START_REF] Bogena | Potential of Wireless Sensor Networks for Measuring Soil Water Content Variability[END_REF], Pohl et al. do a similar analysis for understanding the snow cover [START_REF] Pohl | Potential of a Low-cost Sensor Network to Understand the Spatial and Temporal Dynamics of a Mountain Snow Cover[END_REF]. Rice and Bales show how embedded sensors can be used to evaluate the water content of snow [START_REF] Rice | Embedded-Sensor Network Design for Snow Cover Measurements around Snow Pillow and Snow Course Sites in the Sierra Nevada of California[END_REF] and Qian et al. propose a system using short range nodes and cellular phones to capture orchard data [START_REF] J.-P. Qian | Farm and environment information bidirectional acquisition system with individual tree identification using smartphones for orchard precision management[END_REF]. Simoni et al. use wireless sensor networks to model the hydrologic response of an alpine watershed [START_REF] Simoni | Hydrologic Response of an Alpine Watershed: Application of a Meteorological Wireless Sensor Network to Understand Streamflow Generation[END_REF]. Li et al. summarize lessons learnt from deploying a wireless sensor network for soil monitoring [START_REF] Li | Practical Deployment of an In-Field Soil Property Wireless Sensor Network[END_REF]. Gutierrez et al. use low-power wireless to monitor water and automate irrigation [START_REF] Gutierrez | Automated Irrigation System Using a Wireless Sensor Network and GPRS Module[END_REF]. Moreover, Ojha et al. [START_REF] Ojha | Wireless sensor networks for agriculture: The state-of-the-art in practice and future challenges[END_REF] survey the state of the art of wireless sensors for agriculture.

One of the leading groups in using low-power wireless for environmental monitoring is UC Berkeley Prof. Steven Glaser's team. They have designed a complete remote environmental monitoring solution around SmartMesh IP [START_REF] Kerkez | Design and Performance of a Wireless Sensor Network for Catchment-Scale Snow and Soil Moisture Measurements[END_REF].

This system is now used in the UC Berkeley Botanical Garden. This garden has over 13,000 types of plants from around the world, cultivated by region in naturalistic landscapes over its 34 acres. Irrigation in such a diverse botanical environment is complex since different plants have different needs. The Glaser team has deployed a network of 5 motes and 8 repeaters3 to assist the team of botanists with continuous insitu measurements. Sensor stations are equipped with air temperature, relative humidity, soil moisture, soil temperature and soil electrical conductivity sensors at two depths. The gateway is connected to a server hosted at UC Berkeley through a cellular connection 4 .

The largest deployment of the Glaser team is the American River Hydrological Observatory (ARHO) 5 . ARHO is a set of 15 networks deployed across the Sierra Nevada mountain range in California, USA, to monitor the melting process of the snowpack. A total of 945 sensors are wirelessly connected through SmartMesh IP technology, each reporting their measurements every 15 min to a central server on the UC Berkeley campus.

Goals of the PEACH Project

The PEACH project uses technology similar to the ARHO deployments, and applies that to monitoring peach orchards. The goal of the project is to predict frost events by applying machine-learning to the data gathered. The project is organized in 3 phases:

• Phase 1: Deploy the low-power wireless mesh network, with only air temperature sensors.

• Phase 2: Augment the network with relative humidity, soil temperature and soil moisture sensors.

• Phase 3: Apply machine learning to the data and predict frost events.

The project is currently in Phase 1. This article focuses exclusively on the low-power wireless network:

PEACH: Predicting Frost Events in Peach Orchards
what hardware is used (Section 4), how the deployment is done (Section 5), how the back-end system is built (Section 6), and how the system performs (Section 7).

Hardware

The PEACH network consists of 21 low-power wireless motes connected through a SmartMesh IP network to a manager, the gateway of the network. Section 4.1 and 4.2 introduce the motes and manager used, respectively. Section 4.3 shows how the devices are packaged. Section 4.4 describes the range testing done before the deployment.

Low-power Wireless Motes

Fig. 4 shows the three types of motes that are used. All boards are manufactured by Linear Technology. 16 DC9003 (Fig. 4(d)), 2 DC9018 (Fig. 4(c)) and 3 longrange prototype boards (Fig. 4(b)) are deployed.

The DC9003 (Fig. 4(d)) is the development board for SmartMesh IP networks. This is the board used to experiment with and prototype SmartMesh IP technology. All the pins of the micro-controller are exposed, allowing a developer to interface sensors and actuators over digital and analog interfaces. The DC9003 features the LTC5800 chip (a SoC with an ARM Cortex-M3 and an IEEE802.15.4 radio) connected to a chip antenna. The DC9003 is an off-the-shelf commercially available board.

The DC9018 (Fig. 4(c)) is functionally equivalent to the DC9003, but with a 2 dBi external antenna, rather than a chip antenna. It is expected that the DC9018 has a better range than the DC9003. The DC9018 is an offthe-shelf commercially available board.

The long-range board depicted in Fig. 4(b) is a prototype of a new product Linear Technology allows us to test. It is a fully SmartMesh IP-compliant product (i.e. it interoperates with DC9003 and DC9018 boards in the same network), with a line-of-sight range of 1500 m. This board features a 2 dBi external antenna.

The boards deployment in Phase 1 of the PEACH project are developer/prototyping boards. We expect to transition to the NeoMote in Phase 2, a ruggedized version of the motes, manufactured by Metronome Systems 6 .

All the boards deployed during Phase 1 run the default SmartMesh IP firmware. Each board automatically joins the network and sends a temperature reading every 30 s to the manager, using its built-in temperature sensor. In Phase 2, we will reprogram the motes with custom firmware, using the "DustCloud" development environment provided by Linear Technology 7 . 6 http://metronomesystems.com/ 7 http://www.dustcloud.org/

Low-power Wireless Manager

Fig. 4(a) shows the SmartMesh IP manager used in the PEACH project. It is composed of an LTP5902-IPR SmartMesh IP manager chip, a 2 dBi external antenna and USB connectivity, in the form-factor of a USB pen drive. USB connectivity is used to connect the DC2274 to a computer. The computer can run a program to configure the DC2274, send commands and configurations to the motes, and retrieve sensor measurements. The DC2274 is a standalone device, i.e. the computer does not play any active role in operating/managing the network, it just serves as an interface between the SmartMesh IP network and the Internet. The DC2274 is an off-the-shelf commercially available board.

Hardware Integration

The PEACH network is deployed in an orchard for 2 years, and will be exposed to direct sunlight, freezing temperatures, dust and rain. All motes and manager are therefore protected by an enclosure with Internal Protection 65 (IP65) rating 8 .

Fig. 5(a) shows the manager enclosure with the lid open. It contains the DC2274 board, a Raspberry Pi single-board computer running the solmanager software (see Section 6.2), and the power adapter for that board. The DC2274 is powered through USB. A watertight pass-through opening in the manager enclosure is used to pass power and Ethernet cables.

Fig. 5(b) shows a mote in its enclosure. The mote is powered by a pair of Energizer L-91 AA batteries with a charge of 2821 mAh 9 . The mote, antenna and battery are glued in place using silicone. No opening is present in the mote enclosures.

Initial Range Testing

To plan the deployment, it is important to get some intuition about the communication range of the different types of motes. One question is whether the long-range motes can connect the orchard to the manager 380 m away. Another question is whether the DC9003 motes have a communication range large enough to create a mesh network inside the orchard. The DC9003 is meant to be used by a developer on an office desk to prototype connectivity with external sensors, and features a chip antenna with a gain not exceeding 1 dBi. Any SmartMesh IP device has a built-in "radiotest" mode, typically used to verify that the antenna is well matched to the radio chip. We use that mode to perform range testing, and combine it with a RangeTest application we developed 10 . Fig. 6 illustrates the setup used. One transmitter mote (marked "TX") is configured in radiotest mode to transmit 40-byte packets every 10 ms, round-robin on 4 frequencies evenly spaced in the 2.4 GHz frequency band 11 . We use multiple frequencies since SmartMesh IP uses channel hopping. A receiver mote (marked "RX") is connected to a laptop computer running the RangeTest application. This application, through the serial API of the mote, has the mote listen for 4 s on each of the 4 frequencies, and counts the number of received packets. During that 4 s listening window, the 10 As an online addition to this article, the source code of the RangeTest application is available under an open-source BSD license at https://github.com/realms-team/rangetest. 11 We use frequencies 2.405 GHz, 2.425 GHz, 2.445 GHz and 2.465 GHz RangeTest application expects to receive 100 packets; receiving fewer packets indicates a less-than-perfect wireless link. Transmitter and receiver motes are placed in their enclosures on top of 4 m poles, which are moved around, and mimic the poles the motes will be deployed on (see Section 5). We record the average Packet Delivery Ratio (PDR) across all 4 channels, i.e. the portion of received packets, between different locations.

The first question is: Can the long-range motes connect the orchard to the manager, some 380 m away? We use long-range boards as both transmitter and receiver, and position them at positions A-B (a 260 m link), then B-C (a 110 m link). Positions and results are depicted in Fig. 7: the long-range links have an excellent PDR (>95%).

We continue range testing in and around the orchard. As depicted in Fig. 8, we position the transmitter and receiver poles in different locations across the orchard. We classify links as good (80-100% PDR), medium (50-80% PDR) and bad (0-50% PDR). We use a DC9018 board as receiver, a DC9003 board as transmitter.

The second question is: Can a network deployed inside the orchard reliably connect to a mote in position C? We position the receiver at position C and move the transmitter across positions D-H. As depicted in Fig. 8, motes in positions D and E have a good connection with a mote in position C. The third question is: How good do motes connect within the orchard? Results are depicted in Fig. 8: connection is good until 5 trees away in the same row, and until 2 rows away.

These initial measurements give us some intuition about the range of the different motes, and the feasibility of the deployment. It does not, however, provide any (long-term) guarantees, as the quality of the links changes over time. In particular, it does not preclude us from building a system that observes longterm connectivity statistics and provides the user with feedback about the "health" of the network. Such a system is part of the back-end developed for the PEACH network, and presented in Section 6.

The PEACH Deployment

The initial range testing (Section 4.4) suggests a full deployment is feasible. Together with the INTA agronomy team, we determine the best locations to position the sensor stations in the orchard, as shown in Fig. 9. The manager and the long-range motes are placed as depicted in Fig. 7.

We start by switching on the manager, and verify it is operational and connected to the Internet. We use a laptop computer in the orchard, connected to the Internet through a cellular link. We connect the laptop to the manager over SSH, and continuously list the motes that have joined the network. We then deploy the motes from the manager outwards: starting by the longrange motes in positions A, B and C in Fig. 7, then the motes in the orchard.

We install all motes 4 m above the ground on wooden poles. Long-range motes are attached to existing poles (Fig. 10(a)). Dedicated poles are placed in the orchard (Fig. 10(b)).

Deployment itself is straightforward and fast. We switch on the mote to be deployed, close the lid, screw it on its pole, and verify that it has joined the network and that we can "ping" it over the SmartMesh IP network. The entire PEACH deployment took less than 4 hours; most of the time spent moving from location to location and securing the mote enclosures to the poles.

SOL: Back-end System

We call "back-end" the system that connects to the SmartMesh IP manager, retrieves all the sensor measurements and network statistics (the "health reports" generated by the motes), and ensures those appear in a remote database. We implemented a complete back-end system 12 . As illustrated in Fig. 11, the system consists of the solmanager application that runs on the Raspberry Pi single-board computer, and the solserver application running on a server in the Inria-Paris research center.

SOL data representation

The SmartMesh IP continuously publishes information: the data produced by the motes, the health reports produced by the motes, and network events (e.g. a mote joined the network) produced by the manager. The data produced by the motes contains the bytes generated by the application running on the mote; this data is formatted differently depending on the application.

We created the "Sensors Object Library" (SOL) to wrap that information as generic SOL objects. A SOL object is always composed of the same fields: the identifier of the device generating the information, the timestamp of when this information was generated, the type of information, the value of the information. A A SOL Registry contains the list of SOL types currently used, and their associated format. This includes data generated by the motes, health reports or network events. Each SOL object can be represented either in a compact binary form, or in a more easily parseable JSON format. The SOL registry is publicly maintained and can be easily augmented with new types of sensor data 13 .

solmanager

The solmanager application runs on the Raspberry Pi and connects to the serial port of the SmartMesh IP manager. It subscribes to receive all the notifications from the SmartMesh IP manager: data, health reports, network events. It then parses that information and formats it as a series of SOL objects, which it forwards to the solserver application.

In the PEACH deployment, the Raspberry Pi is connected to an Ethernet-to-WiFi bridge equipped with a long-range directional antenna pointing to a building with Internet access 200 m away. In practice, this means the Raspberry Pi is directly connected to the Internet. Through that connection, the Raspberry Pi forwards all the generated SOL objects, in binary format, to the solserver application over HTTPS. Public/private SSL keys and an HTTP token provide confidentiality, integrity, authentication and authorization of the solmanager ↔ solserver communication.

solserver

The solserver application runs on a server in the Inria-Paris research center. The application listens for incoming SOL objects. When those objects are received from a properly authorized solmanager application, the solserver converts them from their binary representation to their JSON representation, and writes them into a database 14 .

A dashboard allows a user to visualize key information 15 . Fig. 12 shows an example dashboard with 7 days worth of data, including the temperature (the day/night temperature swing is clearly visible, the last day being cold), the number of discovered neighbors, and the charge consumed by the devices.

Performance Results

All motes in the network produce a complete health report every 15 min. On top of this, the SmartMesh IP manager provides a complete CLI (Command Line Interface) on one of its serial ports for an operator to type commands and retrieve information about the network. We base the analysis in this section on the data retrieved from the health reports and the CLI of the SmartMesh IP manager.

We divide the performance results in the performance of the overall network (Section 7.1) and the performance of the motes (Section 7.2).

Performance of the Network

Table 1 summarizes the network performance after 5 days and 6 hours of operation. After approx. 24 hours of operation, a SmartMesh IP network reaches "steady state", so we expect the numbers presented in this 14 We use an influxdb (https://influxdata.com/) database. 15 The dashboard is publicly available on the PEACH project website (http://www.savethepeaches.com/). reliability 100% (Arrived/Lost: 243089/0) stability 93% (Transmit/Fails: 1462435/96923) latency 800 ms Table 1. Key network performance indicators.

section to be representative of the lifetime of the network.

The network reliability indicates the portion of the packets generated by the motes that reach their final destination, in our case the SmartMesh IP manager. A packet is said "lost" when it never reaches its destination. The motes in the PEACH deployment have generated 243,089 packets, all were successfully received by the SmartMesh IP manager, possibly after multiple hops, yielding 100% reliability.

The wireless medium is unreliable in nature, and it is common that a link-layer frame sent by mote A is not received by mote B, forcing A to re-transmit. The network stability represents the average PDR over the link. The motes in the PEACH deployment have sent 1,462,435 data-link frames, 96,923 unsuccessfully (i.e. no link-layer acknowledgment was received), yielding a network stability of 93%. This number is very high, indicating that the nodes are deployed close enough in an environment with little external interference and multi-path fading.

A SmartMesh IP network is fully synchronized. A mote generating a data packet adds a timestamp to its data so that what is written in the database is the time the sensor is sampled (not the time it reaches the database). As a side effect, it is possible, at the SmartMesh IP manager, to calculate how long the packet was traveling in the multi-hop wireless mesh network. This is called average network latency. In the PEACH deployment, it takes on average 800 ms for a sensor measurement to travel from the mote that generated it to the SmartMesh IP manager, over the multi-hop low-power wireless mesh network. This latency is very small compared to the variation speed of the signal we are observing (temperature).

Performance of the Motes

The health reports generated by each mote contain a wealth of information. Table 2 contains a summary of the most important information for assessing the performance of the network.

Each line in Table 2 is indexed by the unique identifier of the mote, its "MAC address". This is a unique 8-byte number -called EUI64 -written into the mote at manufacturing time. The EUI64 of all motes starts with 00-17-0d-00-00; in the interest of space, this 5-byte prefix does not appear in Table 2. The Uptime is the time the mote has been operational, and is of format day-hour:min:sec. The 3 first motes were deployed 2 days before the others; it is hence normal to have a 2-day gap in their uptime.

MAC

Each node reports the number of neighbors it currently sees. This is shown in column "Neig." in Table 2. The number of neighbors indicates the density of the deployment. Dust Networks recommends for each mote to ideally have 3 or more neighbors. This is not the case for 10 of the motes in the PEACH deployment. We expect that, when swapping the DC9003 boards (chip antenna) for NeoMote boards (external antenna), the density will increase.

All communication in a SmartMesh IP network is orchestrated by a communication schedule. The column Cells in Table 2 indicates the number of cells in the schedule the mote is active in (transmitting or receiving). That number is directly proportional to the energy it consumes. We analyze the energy consumption more finely below.

Each packet sent through the low-power SmartMesh IP mesh network contains a hop count field 16 . This allows the SmartMesh IP manager to know 16 Equivalent to the "hop limit" field in the IPv6 header. how many hops this packet took to go from its source to the manager. The value printed in the Hops field is an average calculated over the packets received so far. As can be seen from Table 2, the closest (resp. furthest) mote is 1.0 (resp. 4.4) hops away from the manager. Dust Network recommends to keep that number below 8 for efficiency; a condition we satisfy.

The Latency column shows the average latency for a packet to go from that node to the manager. The average value of all motes is the network latency shown in Table 1. As can be seen, the latency increases with the number of hops.

The overall network reliability is shown in Table 1.

Table 2 shows the same information, but broken up per mote. Column "Recv'd" shows the number of packets generated by that mote that have reached the manager. Column "Lost" shows the number of packets lost en route. No packets are lost, the Reliability for each node is 100%.

In their health reports, motes indicate the amount of Charge drawn so far from their battery, in mC. Knowing their uptime and the theoretical charge of their battery 17 , we calculate the expected Lifetime of each mote. The expected lifetime varies between 3.43 years and 8.66 years, depending on the type of motes (a long-range mote consumes more than a DC9003) and its activity (a mote with more cells consumes more). These numbers are well above the targeted 1 year of lifetime.

Lessons Learnt, Ongoing Work and Roadmap

We conclude this article by listing the lessons learnt from this deployment (Section 8.1) and detail ongoing work and roadmap (Section 8.2).

Lessons Learnt

Although frost events may appear harmless, they yield enormous losses in fruit production, for example peaches. The most important lesson learnt is that IoT is the right technology for this precision agriculture application, and that using it makes a huge monetary difference. Moreover, as seen throughout this project, IoT technology is ready for this type of application. We strongly believe that the combination of technologies demonstrated through the PEACH project is the right one for a large number of "Smart Agriculture" applications. We hope that the present article can guide end users put together the right technical solution.

The main outcome of this project is a perfectly working end-to-end low-power wireless distributed sensor system, built exclusively from commercial offthe-shelf components. Deploying such a network took a couple of hours, putting the whole hardware and software together a couple of days. The resulting network is 100% reliable, offers latency below 2 s, and 3+ years of battery lifetime.

In 2006, Langendoen et al. wrote a foundational (and "brutally honest") paper listing everything that went wrong in a precision agriculture deployment similar to the PEACH project [START_REF] Langendoen | Murphy Loves Potatoes -Experiences from a Pilot Sensor Network Deployment in Precision Agriculture[END_REF]. This included board failure, batteries running out, sub-optimal software tracking, etc. So what went right this time, about a decade later? The teams in both cases are of the same caliber, so the wrong conclusion would be to blame/praise the people involved. What has really happened is that the field of low-power wireless has evolved substantially, and has radically changed in that decade.

In 2006, researchers bought boards and programmed them from scratch with academic open-source projects. In 2016, end users buy complete working systems, including all the hardware and software.

In 2006, the protocol stack implemented was a combination of the most promising research papers from recent years. In 2016, the protocol stack implemented is entirely standards-based, with standards matured over years in a commercial/industrial mind-set.

In 2006, every new deployment was pushing the frontier. In 2016, tens of thousands of these network have been running for years in the most critical applications.

To put it plainly, Wireless Sensor Network/Internet of Things technology has successfully transitioned from the academic to the commercial world.

The result is a necessary redefinition of the work of the academic community. The era of building everything from scratch is over. This is in particular true for software implementations; a small research group is simply no match for the heavy lifting full-time development teams do. In our opinion, the energy of small and agile research teams should be spent on [START_REF] Chaar | Use of a correlation model for the determination of peach tree [prunus persica (l.) batsch.] heat and chilling requirement[END_REF] ensuring that clever ideas transition to the commercial world through standardization and (2) be very well connected to the commercial world, for example by continuously surveying existing products/technologies. As for point (2) above, we encourage journal editors and conference program chairs to include "lessons learnt from practical deployments" onto the topics of interest.

Ongoing Work and Roadmap

Today, we are only 5 months into the 2-year PEACH project. While the choices for the base networking technology are validated by the work presented in this article, a lot still needs to be done.

The first step is to add additional sensors to the motes, including relative air humidity, soil moisture, soil temperature and soil conductivity. This might include adding NeoMotes to the deployment.

One aspect of the PEACH project that is missing so far is the data analysis. We plan to apply machine learning techniques, in particular ensemble regression-tree, on the large-scale sensor measurement dataset. This will require us to augment the sensor measurements with features that could help predict frost events. We plan to connect an anemometer to the deployment, and to conduct partial flooding of the orchard to quantify the impact of flooding on the intensity of frost events.

On the software side, one immediate next step is to augment the visualization on the back-end system. While the dashboard shown in Fig. 12 is a convenient tool for navigating the raw data, it does not interpret that data. We are working on "network control tower" software which, based on the health reports and events it receives, is able to alert an operator that the network functions sub-optimally, and make recommendations.

Finally, and most importantly, the combination of technologies is perfectly suited for micro-climatic modeling in precision agriculture, but we believe it is also perfectly suited for other fields. We are actively looking to extend this solution to Industry 4.0, building automation and infrastructure monitoring applications.

Figure 1 .

 1 Figure 1. Peach flower buds at different stages of winter rest. The flower bud has a lower resistance to frost in (b).

Figure 2 .

 2 Figure 2. Gynoecium healthy and damaged by frosts. Damage is visualized by brown tissues (extracted from [2]).

  (a) DC2274: Low-power wireless manager (1 deployed) (b) Long-range prototype board (3 deployed) (c) DC9018: External antenna mote (2 deployed) (d) DC9003: chip antenna mote (16 deployed)

Figure 4 .

 4 Figure 4. The boards deployed.

Figure 5 .

 5 Figure 5. The devices encased in 20 cm × 15 cm IP65 enclosures.

Figure 6 .

 6 Figure 6. Setup for range testing.

Figure 7 .

 7 Figure 7. Range testing using long-range prototype boards.

Figure 8 .

 8 Figure 8. Locations for range testing in the orchard.

Figure 9 .

 9 Figure 9. Final locations of the deployed motes in the orchard.

  (a) Long-range mote at position B in Fig. 7. (b) Mote in orchard.

Figure 10 .

 10 Figure 10. Members of the team deploying motes.

Figure 11 .

 11 Figure 11. The SOL back-end system.

  13https://github.com/realms-team/sol/blob/master/ registry.md

Figure 12 .

 12 Figure 12. Example dashboard showing the last 7 days of data.

Table 2 .

 2 Key mote performance indicators.

		Uptime	Neig. Cells Hops Latency Recv'd Lost Relia.	Charge	Lifetime
	60-3C-D9	5-06:57:07	2	40	N.A.	N.A.	N.A. N.A.	N.A.	N.A.	N.A.
	B0-00-AA	5-06:56:06	3	20	1.0	170 ms	16450	0 100% 33263 mC 4.42 years
	B0-00-CC	5-06:54:55	5	18	2.7	280 ms	16657	0 100% 28396 mC 5.18 years
	58-32-36	3-09:29:11	10	21	3.0	420 ms	10788	0 100% 27546 mC 3.43 years
	B0-00-BE	3-10:17:42	6	15	2.8	670 ms	10560	0 100% 15147 mC 6.30 years
	60-06-0F	3-09:01:05	4	11	3.5 1020 ms	10386	0 100% 15759 mC 5.96 years
	B0-00-87	3-10:06:30	6	37	1.2	120 ms	10628	0 100% 20038 mC 4.75 years
	3F-F8-20	3-09:21:15	2	9	3.6 1180 ms	10428	0 100% 11907 mC 7.92 years
	30-60-EF	3-09:16:26	9	24	2.7	340 ms	10551	0 100% 22471 mC 4.19 years
	60-03-82	3-09:11:22	4	11	3.5	740 ms	10409	0 100% 15977 mC 5.89 years
	60-08-D5	3-09:04:03	2	9	3.5	810 ms	10389	0 100% 11173 mC 8.41 years
	3F-FE-88	3-08:56:18	3	10	3.5 1210 ms	10384	0 100% 12924 mC 7.26 years
	3F-FE-87	3-08:51:28	2	9	4.2 1440 ms	10372	0 100% 11900 mC 7.88 years
	60-05-5F	3-08:45:53	2	9	4.4 1860 ms	10346	0 100% 10867 mC 8.61 years
	60-06-27	3-08:45:09	4	12	3.6	770 ms	10368	0 100% 14629 mC 6.40 years
	60-05-69	3-08:40:17	2	9	3.6 1100 ms	10334	0 100% 10915 mC 8.57 years
	60-01-F8	3-08:37:02	3	10	3.6	640 ms	10322	0 100% 11292 mC 8.28 years
	60-02-4B	3-08:31:59	2	9	4.3 1520 ms	10326	0 100% 13186 mC 7.08 years
	60-02-1B	3-08:28:39	6	14	3.5	650 ms	10301	0 100% 14700 mC 6.35 years
	60-05-AB	3-08:22:30	3	10	4.0	920 ms	10298	0 100% 12808 mC 7.27 years
	60-06-EC	3-08:21:17	2	9	4.4 1740 ms	10289	0 100% 10964 mC 8.50 years
	38-0F-66	3-08:03:38	2	9	4.4 1430 ms	10254	0 100% 10781 mC 8.61 years
	60-05-78	3-08:00:26	2	9	3.6	950 ms	10247	0 100% 10710 mC 8.66 years
	the manager

http://www.linear.com/dust

http://www.linear.com/docs/42452

"Student-installed Sensors Help Monitor Botanical Garden", http: //news.berkeley.edu/, 20 October 2015.

A simplified interface is accessible at http://glaser.berkeley. edu/wsn/botgn/hist.html.

http://arho.org/

Totally dust tight and protection against low pressure water jets in all directions.

The charge mentioned in the datasheet of the Energizer L-91 is 3135 mAh, but we assume a

10% derated charge to account for shelflife.

EAI Endorsed Transactions Preprint

As an online addition to this article, the source code of the backend system (including the solmanager and solserver applications) is available under an open-source BSD license at https://github. com/realms-team/.

We assume 2821 mAh, per Section 4.3 of charge, or 101,556,000 mC.

Acknowledgments

The authors thank the Dust Networks product group at Linear Technology and Metronome Systems for their technical support. The authors thank Nicolás Altamiranda, Guillermo Grünwaldt and Matías Pecchia for their assistance during the deployment. This publication was made possible by the support of the STIC-AmSud program, under grant 16STIC08-PEACH.