Hossein Shafagh
email: shafagh@inf.ethz.ch

Anwar Hithnawi
email: hithnawi@inf.ethz.ch

Simon Duquennoy
email: simon.duquennoy@inria.fr

Towards Blockchain-based Auditable Storage and Sharing of IoT Data

Today the cloud plays a central role in storing, processing, and distributing data. Despite contributing to the rapid development of various applications, including the IoT, the current centralized storage architecture has led into a myriad of isolated data silos and is preventing the full potential of holistic data-driven analytics for IoT data. In this abstract, we advocate a data-centric design for IoT with focus on resilience, sharing, and auditable protection of information. We introduce the initial design of our blockchain-based end-to-end encrypted data storage system. We enable a secure and persistent data management, by utilizing the blockchain as an auditable access control layer to a decentralized storage layer.

Motivation

Internet of Things. With the emergence of networked embedded devices dubbed as the IoT, we witness an ever increasing number of innovative applications in various domains, such as healthcare, fitness, and automation. The current ecosystem of IoT consists typically of lowpower devices equipped with the necessary sensors collecting high-resolution data of their environments. The data is then stored in a third-party cloud storage provider for further processing [START_REF] Shafagh | Encrypted Query Processing for the Internet of Things[END_REF]. In other words, each application service introduces its set of devices and processes the collected data to provide a promised service.

This current approach has resulted into monolithic and isolated data silos, where users have no control over their data. The users have no other option than to trust the cloud and rely on its promises of availability, resilience, and security. The collected data is also valuable beyond one specific application and should be made easily accessible to other services. E.g., one area which could gain from longitudinal health and fitness data is personalized health care. More importantly, in the current model the fate of our data is tied with the lifespan of the service.

Approach.

These limitations necessitate a rethinking of the way we currently handle IoT data in its entirety. Instead of storing data centrally in data centers, which are located at the edge of the Internet backbone, we need a data-centric approach which abstracts away the location of data [START_REF] Zhang | The Cloud is Not Enough: Saving IoT from the Cloud[END_REF]. We advocate a reliable storage and distribution of data streams while empowering the data owner with fine-granular access control. This would facilitate the emergence of a new class of datadriven applications and ensure data ownership. At the same time, our approach must accommodate for a scalable system capable of handling high access throughputs. We envision a separation of data and services, such that services can transparently tap any data source. Inspired by recent blockchain-based technologies [START_REF] Ali | Blockstack: A Global Naming and Storage System Secured by Blockchains[END_REF][START_REF] Zyskind | Decentralizing Privacy: Using Blockchain to Protect Personal Data[END_REF], we combine a blockchain and an off-chain distributed storage to construct a secure and auditable IoT data management system. An IoT data stream has an append-only nature, where only the data producer has write permissions. On the other hand, several readers (i.e., services) can have simultaneous read rights to the same data stream or one reader can retrieve data from several streams simultaneously. Readers can perform random access on streams.

2 Initial System Design

As illustrated in Figure 1, our system separates access control from the data plane. The former is realized with a public blockchain and the latter with a distributed data storage. The peers of our distributed cloud have financial incentives (similar to Storj [START_REF] Techical Report | Storj: A Peer-to-Peer Cloud Storage Network[END_REF] or FileCoin [START_REF] Techical Report | Filecoin: A Cryptocurrency Operated File Network[END_REF]) to provide persistent storage. Peers can be either individual users utilizing the excess of their available storage space or commercial cloud storage providers. Data is encrypted end-to-end at the client-side. Hence, the peers have no insights about the hosted data at their side. Blockchain. We employ a publicly verifiable ledger (blockchain) to create an accountable distributed system and bootstrap trust in an untrusted network, without a central point of trust. Blockchain-based technologies [START_REF] Bonneau | Research Perspectives and Challenges for Bitcoin and Cryptocurrencies[END_REF] incentivize a network of peers to make computations towards consensus in the network. The consensus agrees on the next valid block of the blockchain. Each block contains validated transactions which remain publicly auditable. In our system, transactions consist of per data stream ownership and access permissions. Data Plane. The IoT data is a stream where data records are generated continuously. This renders the current distributed storage approaches [START_REF] Techical Report | Filecoin: A Cryptocurrency Operated File Network[END_REF][START_REF] Techical Report | Storj: A Peer-to-Peer Cloud Storage Network[END_REF] which primarily target archiving of data not suitable for IoT data. Hence, instead of storing data records, we store data chunks which compose several consecutive data records. To this end, we abstract a data stream into data chunks. Although chunking of data prevents random access at the record level, it has a positive impact on the performance of data retrieval since in time-series most queries require data that is co-located in time (e.g., all records of one day) [START_REF] Gupta | Bolt: Data Management for Connected Homes[END_REF].

IoT data is highly compressible. The compressed data chunks reduce bandwidth and storage requirements. Before a chunk leaves the origin, it is encrypted with an efficient symmetric cipher. The key is shared with services which are granted read access rights.

We rely on a Distributed Hash Table (DHT) as our general-purpose private key-value data store interface. The DHT serves as a scalable, self-managing storage with high availability (i.e., robust against targeted communication outages or malicious attacks in case of central servers). The DHT enforces a randomized storage across a 256-bit address space. Additionally, data replication is used to ensure high availability. Access Control. We use the blockchain to store access permissions securely. A signed transaction in our case contains the data owner, data readers, the corresponding data stream, and some additional metadata. Access rights are granted per data stream and are limited in time, as expressed in the number of chunks. The data owner can extend or revoke the sharing of a data stream. Moreover, keys are renewed periodically.

For any request to retrieve data, the responsible DHT node first checks the blockchain for access rights. A malicious DHT node could hand out data without permission. However, the impact of this action is limited since (i) data is encrypted, (ii) each node holds a small random fraction of a data stream due to the nature of DHTs, and (iii) access right violation is detectable. Search. In our off-chain DHT, we store key-value pairs. In our case, the value is the current data chunk in a data stream, whereas the key (i.e., a 256-bit identifier) is the cryptographic hash of the tuple: <stream-ID, device-ID, user-ID, #counter>. The IDs are unique bit strings (i.e., hash digests). The key is used for a lookup in the DHT.

One challenge of such decentralized systems is an efficient search. To address this challenge, we consider building local indices [START_REF] Gupta | Bolt: Data Management for Connected Homes[END_REF] and share these with services. This abstraction allows an authorized party to be able to determine which chunks to retrieve locally.

Work Under Progress

Realizing such a system requires addressing research challenges at several fronts. We are currently in the process of finalizing our design and implementing a complete prototype of our system and building several IoT applications on top of it. We tackle (i) privacy and security by integrating integrity protection, authentication, and encryption in the design, (ii) scalability by the distributed nature of the underlying blockchain and peer-topeer storage network, (iii) fine-grained access control by separating data plane and access control, and (iv) durability by giving control over the fate of data to the users.

Figure 1 :

 1 Figure 1: Three layers of our blockchain-based, end-toend encrypted, and decentralized data storage.


Beshr Al Nahas

Simon Duquennoy
email: simon.duquennoy@ri.se

Poster: Network Bootstrapping and Leader Election Utilizing the Capture E ect in Low-power Wireless Networks

Many protocols in low-power wireless networks require a root node or a leader to bootstrap and maintain its operation. For example, Chaos and Glossy networks need an initiator to synchronize and initiate the communications rounds. Commonly, these protocols use a xed, compile-time de ned node as the leader. In this work, we tackle the challenge of dynamically bootstrapping the network and electing a leader in low-power wireless scenarios, and we focus on Chaos-style networks.

INTRODUCTION

Context and Challenge. Many protocols in low-power wireless networks require an entity to bootstrap and maintain the operation, which we denote a leader. For example, RPL networks need a network root to build the routing tree, TSCH networks need a timesource root to synchronize the network and Glossy/Chaos/LWB networks need an initiator to synchronize and initiate the communications rounds. In applications that build their operation on consensus; e.g., two-phase commit, the leader is responsible for proposing and committing transactions. In the recent work [START_REF] Ferrari | Low-Power Wireless Bus[END_REF][START_REF] Landsiedel | Chaos: Versatile and E cient All-to-All Data Sharing and In-Network Processing at Scale[END_REF], the common solution was to use a xed, compile-time de ned node to be the leader.

The use of a statically de ned leader exhibit the following weaknesses; (a) it assumes a known network deployment; thus, it does not suit random deployments; e.g., throwing nodes from the air; (b) it assumes a static network; thus, mobility is limited, and, (c) initiator failure means a network failure and might require manual intervention to restart the network operation. While the problem of clustering and leader election is not new as it was tackled by Heinzelman et al. in LEACH [START_REF] Heinzelman | Energy-e cient communication protocol for wireless microsensor networks[END_REF] and subsequent work, there is a need for an approach that both suits and bene ts from the low latency of recent approaches to synchronous transmissions, such as Glossy and Chaos.

Approach. In this paper, we tackle the challenge of dynamically electing a leader in low-power wireless networks. We propose mechanisms that achieve (a) network bootstrapping; i.e., network synchronization, and clustering; (b) leader election and ensuring the convergence toward one leader and (c) leader failure recovery. We build on top of our work A 2 [START_REF] Beshr | Network-wide Consensus Utilizing the Capture E ect in Low-power Wireless Networks[END_REF] and its lower layer, Synchrotron, the synchronous transmission protocol that is inspired by Chaos.

Outline. We provide the required background on A 2 and synchronous transmission in §2. Then we explain the design in §3 and conclude with preliminary results in §4.

BACKGROUND: A AND SYNCHROTRON

A 2 builds on top a synchronous transmissions kernel, Synchrotron, and utilizes in-network processing to provide primitives for network-wide, all-to-all dissemination, collection, aggregation, voting, consensus (two-and three-phase commit) and membership services. A 2 operates in rounds where nodes send packets synchronously and receive data thanks to the capture e ect.

Synchrotron: Synchronous transmissions and capture e ect. Synchrotron roots in approaches to synchronous transmissions, such as Chaos, where multiple nodes synchronously transmit the data they want to share. Nodes overhearing the concurrent transmissions receive one of them with high probability, due to the capture e ect. For example, to achieve capture with IEEE 802.15.4 radios, nodes need to start transmitting within the duration of the preamble of 160µs [START_REF] Landsiedel | Chaos: Versatile and E cient All-to-All Data Sharing and In-Network Processing at Scale[END_REF].

Synchrotron operates as a time-slotted protocol. The minimum time unit is a slot, which ts one packet transmission/reception and processing. Slots are grouped in rounds, where a designated function, such as collect or disseminate is run network-wide. Within each slot, a node transmits, receives or sleeps according to the transmission policy of the application.

In-network aggregation. In A 2 , each packet contains so-called progress ags, where one bit is assigned to each node in the network. The coordinator node starts an A 2 round by sending a packet with only its own ag set. Upon successful reception, a node sets its ag and merges the received packet with its own. It transmits in the next time slot when it received new information, i.e., new ags, or when it sees that a neighboring node is transmitting messages with fewer ags set, i.e., a neighbor knows less than the node itself. The process continues until all nodes have set their ag.

Similar to Chaos, the rules for merging are application speci c. With the Max operation, for example, A 2 identi es the maximum value: Next to the ags, the only payload is the maximum value collected so far. Upon reception, nodes compute the max between their local value and the payload, write it to the packet payload, merge the ags, and set their ag before transmitting in the next time-slot.

SenSys '17, November 6-8, 2017, Del , Netherlands Beshr Al Nahas, Simon Duquennoy, and Olaf Landsiedel

DESIGN

To start a proper network operation in A 2 , there shall be an initiator node or a leader that (a) ensures network-wide synchronization; (b) joins the nodes that wish to participate in the network and assigns each of them a unique ID; and (c) initiate the communication rounds and ensures the application objectives are met.

To be able to communicate, we need to synchronize the nodes. We start by forming clusters that ensure neighborhood synchronization. Then, we merge the clusters gradually to form one networkwide cluster with a single leader.

Bootstrapping and Clustering

We start by having two assumptions (a) the nodes are homogeneous and any of them could be a leader. This assumption is by no means compulsory, but it simpli es the discussion; and (b) the maximum number of nodes is known before hand.

Every node start by listening to the radio and generates a random timeout. It keeps listening until it hears a valid A 2 message to synchronize on. If it times out without hearing, then it proposes itself a leader and starts sending join announcements such that other nodes hear them and join it to form a cluster. At this phase, multiple clusters could form as di erent nodes might not hear each other. The next step is to converge towards one leader in one cluster.

Leader Election

To ensure the convergence toward one leader, we put a quorum stability condition: A stable cluster is the one that has more than half of the nodes. Given that the nodes cannot join more than one cluster, we can ensure convergence.

Until a cluster is stable, it keeps running join rounds, and its members keep sampling the medium between the communication rounds looking for bigger clusters to join. When a node hears another cluster, it saves the synchronization information of the largest foreign cluster it heard. Each node shares this information in the next join round with its cluster, and use the Max primitive to nd the information about the largest cluster. At the end of the join round, nodes drop their cluster, their IDs and jump to join the new cluster if it is bigger than their current cluster. With time, only the largest cluster survives, and only one leader exists.

Failure Recovery

Upon leader failure, nodes no longer hear packets, and the random timeout mechanism kicks in. This restarts the whole process and elects a new leader as illustrated in §3.1 and §3.2.

PRELIMINARY RESULTS AND CONCLUSION

Implementation. We implement the algorithm explained in §3 in C for the Contiki OS targeting wireless nodes equipped with a low-power radio such as TelosB and Wsn430 platforms which feature a 16bit MSP430 CPU @ 4 MHz, 10 kB of RAM, 48 kB of rmware storage and CC2420 radio compatible with 802.15.4. Figure 1 illustrates an example run on a network of 5 nodes. Figure 2 summarizes the results of running on the testbeds FIT-IoTLAB Euratech and Flocklab. First, we vary the maximum timeout period and run on Euratech. We nd that the choice of the timeout has minimal e ect on the time to convergence to one cluster that inlcudes all the nodes. Second, we compare the performance when running on sparse and dense testbeds. The network converges to one leader and all the nodes join the leader within 41 seconds for 216 nodes (on Euratech) and 21 seconds for 29 nodes (on Flocklab).

Figure 1 :

 1 Figure 1: An example run with ve nodes. Nodes A and C propose themselves as leaders. Due to the network setup, two clusters form. E and C keep listening between rounds since their cluster has less than half of the nodes. E overhears A's cluster and noti es its cluster members. The network converges to select A as the only leader.

Figure 2 :

 2 Figure 2: The time it takes the leader election procedure to converge to one cluster and join all the nodes in the network.

SenSys '17, Delft, Netherlands © 2017 Copyright held by the owner/author(s). Publication rights licensed to ACM. This is the author's version of the work. It is posted here for your personal use. Not for redistribution. The de nitive Version of Record was published in Proceedings of SenSys '17, November 6-8, 2017, https://doi.org/10.1145/3131672.3137002.

ACKNOWLEDGMENTS

This work was supported by the Swedish Research Council (VR) through the project ChaosNet, the Swedish Foundation for Strategic Research (SSF) through the project LoWi, CPER Nord-Pas-de-Calais/FEDER DATA and Sweden's innovation agency (VINNOVA).


Simon Duquennoy

Atis Elsts

Beshr Al Nahas

George Oikonomou

TSCH and 6TiSCH for Contiki: Challenges, Design and Evaluation

Synchronized communication has recently emerged as a prime option for low-power critical applications. Solutions such as Glossy or Time Slotted Channel Hopping (TSCH) have demonstrated end-to-end reliability upwards of 99.99%. In this context, the IETF Working Group 6TiSCH is currently standardizing the mechanisms to use TSCH in low-power IPv6 scenarios. This paper identifies a number of challenges when it comes to implementing the 6TiSCH stack. It shows how these challenges can be addressed with practical solutions for locking, queuing, scheduling and other aspects.

With this implementation as an enabler, we present an experimental validation and comparison with state-of-the-art MAC protocols. We conduct fine-grained energy profiling, showing the impact of link-layer security on packet transmission. We evaluate distributed time synchronization in a 340-node testbed, and demonstrate that tight synchronization (hundreds of microseconds) can be achieved at very low cost (0.3% duty cycle, 0.008% channel utilization). We finally compare TSCH against traditional MAC layers: low-power listening (LPL) and CSMA, in terms of reliability, latency and energy. We show that with proper scheduling, TSCH achieves by far the highest reliability, and outperforms LPL in both energy and latency.

I. INTRODUCTION

As research in low-power networking matures, synchronized communication is emerging as a prime option for critical applications. Synchronized network flooding with e.g., Glossy [START_REF] Ferrari | Efficient Network Flooding and Time Synchronization with Glossy[END_REF], or mesh networks based on IEEE 802.15.4-2015 [START_REF][END_REF] Time Slotted Channel Hopping (TSCH) [START_REF] Watteyne | Industrial Wireless IP-based Cyber Physical Systems[END_REF], have demonstrated end-to-end reliability upwards of 99.99 %, in real deployments.

At the same time, the industry has been pushing for standardized solutions with the IETF's low-power IPv6 stack: 6LoWPAN, RPL, CoAP, etc. This promises (1) interoperability; (2) integration with existing management tools and networks; and (3) industrial-grade security levels. In this context, the IETF Working Group 6TiSCH [START_REF]An Architecture for IPv6 over the TSCH mode of IEEE[END_REF] is currently standardizing the mechanisms to run IPv6 on top of TSCH.

TSCH is essentially a MAC layer that offers a globallysynchronized network of sleepy nodes. Each node's activity is dictated by a time-slotted schedule. In this schedule, communication uses channel hopping. 6TiSCH defines the sublayer for the management of TSCH nodes and schedules.

This paper first identifies five distinct challenges we must address for a flexible and efficient 6TiSCH implementation. We show how to address all five challenges in a real setting, through our implementation for Contiki [START_REF] Dunkels | Contiki -A Lightweight and Flexible Operating System for Tiny Networked Sensors[END_REF], a leading operating system for the IoT. In particular, we A timeslot is typically 10 ms long. Blank time before/between/after frames are for processing: queuing and cryptography. Slotframes can be of any finite length; they repeat over time.

discuss software architecture, locking, queuing and many other aspects. In total, our implementation is already ported to 9 different hardware platforms, and was successfully tested for interoperability.

We then run testbed experiments (up to 340 nodes) to answer the following questions:

• How accurate can synchronization get in large networks, and what is the energy baseline? • How does TSCH compare to the traditional MAC layers CSMA and Low-power listening? • How is energy spent, at both sending and receiving sides, both with and without security?

Next, §II provides necessary background, and §III introduces the five challenges we focus on. §IV presents our solutions and implementation, followed by an evaluation in §V. We discuss related work in §VI and conclude in §VII.

II. BACKGROUND

A. IEEE 802.15.4-2015 TSCH Time Slotted Channel Hopping (TSCH) is a MAC layer specified in IEEE 802.15.4-2015 [START_REF][END_REF], with a design inherited from WirelessHART and ISA100.11a.

TSCH builds a globally synchronized mesh network. Nodes may join the network after hearing a beacon from another node. Time synchronization trickles from the PAN coordinator down to leaf nodes along a Directed Acyclic Graph (DAG) structure. Nodes update their synchronization relative to their time source parent every time they receive a data or ACK frame from it.

Time is cut into timeslots; timeslots are grouped into one or more slotframes, which repeat over time (as illustrated in Fig. 1). A timeslot, typically 10 ms long, is long enough to accommodate the transmission of a frame and its acknowledgement, including encryption/decryption times. A schedule dictates whether to transmit, receive or sleep within each timeslot. A timeslot in a slotframe is identified by its time offset (when in the slotframe it occurs) and its channel offset (denoting the frequency to communicate on). Slots can be dedicated or shared, i.e., contention-free or contentionbased with CSMA back-off.

TSCH networks use channel hopping: the same slot in the schedule translates into a different frequency at each iteration of the slotframe. The result is that successive packets exchanged between neighbor nodes are communicated at different frequencies. In case a transmission fails because of external interference or multi-path fading, its retransmission happens on a different frequency, often with a better probability of succeeding than using the same frequency again [START_REF] Watteyne | Mitigating Multipath Fading through Channel Hopping in Wireless Sensor Networks[END_REF].

How the communication schedule in the TSCH network is built and maintained is out of the scope of the established standards. 6TiSCH, detailed next, proposes the options to schedule either (1) centrally like WirelessHART and ISA100.11a which computes routes and schedules from link statistics and traffic information gathered in the network or (2) in a distributed fashion.

B. IETF 6TiSCH

The IETF Working Group 6TiSCH [START_REF]An Architecture for IPv6 over the TSCH mode of IEEE[END_REF] was chartered in 2013 to enable IPv6 on top of TSCH. It covers architecture, interface, scheduling and security aspects. The Working Group is still active at the time of writing, with one RFC and a number of active Internet-Drafts. 6TiSCH enables node and schedule management via a CoAP interface, building on COMI (CoAP Management Interface). It also defines 6top, a sub-layer that enables neighbor-to-neighbor slot installation/removal. 6top can run one or several scheduling functions, which defines rules about when and how to add and remove slots at each node. The architecture documents also define a secure join process.

6TiSCH also defines a so-called minimal configuration, which must be supported by all implementations in order to achieve basic interoperability. This configuration includes a simple static schedule and security architecture, based on two keys K1 and K2. K1 is used for authentication-only of beacons, while K2 is used to encrypt and authenticate data and ACK traffic. In addition, the minimal configuration defines how TSCH interacts with upper layers and the RPL routing protocol. In particular, it ensures a consistent mapping between the RPL routing topology and the TSCH time-source graph.

III. CHALLENGES

For an implementation of TSCH and 6TiSCH to be standards-compliant, versatile and efficient, we need to ad-dress a number of key challenges (some of which were discussed in [START_REF] Watteyne | Industrial Wireless IP-based Cyber Physical Systems[END_REF]). We identify the following five challenges: standards-compliance, timing precision, portability, efficiency and interface with upper layers.

C1: Standards-compliance

The first challenge in our stack is to ensure compliance with the standards: TSCH and 6TiSCH. We support only a subset of the standards, but we do so in a fully compliant way. Standards-compliance includes timeslot and slotframe operation as well as security. C2: Timing Precision The second challenge is to achieve precise timings. Operations within a TSCH timeslot are defined at a micro-second precision. Nodes are required to stick to the timeslot as closely as possible, and to maintain synchronization with their time source(s) as tightly as possible. C3: Portability The third challenge is to ensure portability across the many platforms supported by the Contiki OS, including both 16 and 32-bit MCUs, and a variety of radio chips. Portability is a pragmatic but important constraint, as it precludes relying on features that only few platforms offer. In our design, we carefully select relevant radio interfaces offered by Contiki, and propose extensions where needed. C4: Efficiency The next challenge is efficiency, in MCU time and energy. Our aim is to be as energy-efficient as possible, to the extent that does not compromise portability or timing precision.

C5: Interface with Upper Layers

Finally, we need means for upper layers to interact with the timing-sensitive TSCH MAC layer. This is non-trivial because the timesensitivity of TSCH requires it to be interrupt-driven. Our design includes solutions for race-condition free operation of Contiki's IPv6 stack on top of TSCH.

IV. DESIGN

This section discusses how we address the five technical challenges (C1 to C5), so as to enable a flexible and efficient 6TiSCH stack for constrained micro-controllers.

A. Slot Operation

In order to support standard-compliant slots (C1) and address the timing precision challenge (C2), our design is fully driven by timer interrupts. Nodes wakeup at the beginning of every slot that is active (listen and/or transmit) in their schedule. For transmit slots, they prepare and encrypt the packet to be sent, and go back to sleep until the planned transmission time. They then transmit, go back to sleep until the expected arrival time for the ACK. After receiving the ACK, they look up their schedule for the next active slot, set a timer for the next wakeup and go back to sleep. Receive slots operate conversely, and nodes also sleep between the different events within timeslots.

All operations within a timeslot take place in interrupt handlers, to ensure tight timing. We implement the transmit and receive procedures as protothreads [START_REF] Dunkels | Protothreads: Simplifying event-driven programming of memory-constrained embedded systems[END_REF]. This result is more readable (sequential) code that does not sacrifice the timing requirements (runs on an event kernel). Note that in our current implementation, nodes stay busy waiting within an interrupt context whenever expecting an incoming frame. Alternatively, they could turn the radio on, go back to sleep and wait for a radio interrupt to process the frame and schedule the next wakeup (e.g., for ACK transmission). The latter approach, albeit more efficient, is made difficult due to limitations of Contiki's current radio driver interface and the different triggers radio chips employ to signal interrupts; i.e., start or end of frame. Enabling such a busy wait-free operation in a way that does not compromise portability (C3) is on our roadmap.

B. Locking and Queuing

An important challenge in TSCH is to safely interface the synchronous interrupt-driven engine with the asynchronous system's upper layers (C5). To this end, we rely on two tools: ring buffers for outgoing, sent, and incoming packet queues, and a global lock for core TSCH operations.

We use a fixed-size lock-free ring buffer implementation that is safe and lightweight to realize the packet queues between TSCH and the upper layers. We have a distinct transmit queue for each neighbor, filled by upper layers and consumed by TSCH, within interrupts. In addition, there is a queue for packets that need post-transmission processing; i.e., upper layer callbacks. This queue is filled by TSCH inside an interrupt, and consumed by upper layers within a process context. Finally, TSCH has an input queue, where it puts all valid incoming data frames, processed later by an upper layer process. Fig. 2 illustrates which modules read and write to the different queues, in a lock-free manner.

Some other operations, however, need to write to sensitive TSCH state and require a global lock. Examples of such are schedule and neighbor table maintenance where new neighbor queues are created. In our design, all such operations must be performed outside interrupt contexts. Whenever attempting such maintenance while an active TSCH slot is going on, the process will busy wait until the end of the slot, take the lock, proceed, and release the lock. Slots starting with a busy lock will be skipped; the node goes back to sleep until the next scheduled active slot.

C. 5-byte Modular Arithmetic

TSCH relies on the Absolute Slot Number (ASN), which counts slots from the beginning of the network's life. In order to never virtually loop, the ASN is a 5-byte unsigned integer. With 10 ms slots, it would take over 348 years for the ASN wrap. The ASN is used (1) to compute the current channel, given a slot's channel offset; (2) to find the current time offset in any given slotframe; (3) as cryptographic nonce for link-layer security. During slot operation (within an interrupt context), nodes need to compute the modulo of the ASN to some integer value v (e.g., slotframe length, hopping sequence length), in order to obtain the current time offset or current physical channel respectively.

For fast and memory-efficient 5-byte modulo arithmetic (C4), our design proposes a data structure dedicated to ASN arithmetic. Integers that will be used as divisor of modulo operations are stored in this structure. In addition to the integer actual value v, the structure stores the result of 2 32 mod v, denoted r. Whenever ASN mod v is needed, it is then simply computed as (ASN lsb mod v+r×ASN msb ) mod v, where ASN lsb are the four least significant bytes of ASN, and ASN msb is the ASN's most significant byte. Doing so, TSCH can operate free of any 64-bit arithmetic, rendering it efficient both on 16-bit and 32-bit platforms.

D. Distributed Time Synchronization

Crystal oscillators are never perfectly accurate, and exhibit a clock drift typically in the range of 10 ppm (parts-permillion). As TSCH requires global network synchronization, it is essential that nodes correct the drift to their time source regularly. At 10 ppm each, two nodes have a relative drift up to 20 ppm, which leads to a desynchronization of 20 µs every second. Assuming guard times of ±1100 µs (the default), independent clocks run out of synchronization after 55 s.

In TSCH, nodes re-synchronize their clock with their time source(s) on two distinct occasions (1) upon receiving a frame from a time source or (2) upon receiving an ACK from a time source. In the former case, the node simply compares the reception time against the expected time, and adjusts its clock internally. In the latter case, the time source does the time delta computation upon receiving a unicast, and then includes the delta as part of the ACK (as an Information Element). When receiving the ACK, the node adjusts its internal clock. Note that the clock may be adjusted backwards with no adverse effect on slot operation as the time deltas are bounded by one TSCH guard time.

We build on adaptive time synchronization [START_REF] Stanislowski | Adaptive synchronization in IEEE802.15.4e networks[END_REF], whereby each node learns the relative drift to its time source for tighter synchronization. The drift is basically learnt from past synchronization. Whenever scheduling a wakeup, the node will internally compensate for the anticipated drift and set its timer accordingly. The mechanism enables resynchronization intervals in the order of a few minutes [START_REF] Chang | Adaptive synchronization in multi-hop tsch networks[END_REF].

In addition, we offer dynamic synchronization traffic, both beacons and keep-alives. For TSCH beacons, we map the transmission period to RPL's beaconing interval (Trickle [START_REF] Levis | Trickle: A self-regulating algorithm for code propagation and maintenance in wireless sensor networks[END_REF]). For keep-alive messages (send on-demand by nodes that need a clock update), nodes use a short period, e.g., 30 s, upon attaching to a new time source. As they learn the relative drift to their time source, they start using a longer period, such as 120 s. These two mechanisms result in reduced synchronization overhead as the topology stabilizes, fulfilling both C2 (timing) and C4 (efficiency).

E. Timers and Timestamping

For enabling time synchronization, nodes must be able to produce accurate packet timestamps (C2). We offer two solutions, where the timestamping is either done (1) by the radio chip or (2) by the MCU. The former case is the common case, where we rely on the radio to provide accurate reception timestamps. The latter case is useful on platforms such as the jn516x where the MCU offers a higher-frequency oscillator than the radio.

As for the internal clock, our design can support both lowand high-frequency crystal oscillators, each with their own tradeoff between energy and precision. Our port to the Texas Instruments CC2650 System-on-Chip even supports the joint use of two crystals, for low-power and fine-grained synchronization (sub-microsecond accurate assuming frequent re-synchronization [START_REF] Elsts | Microsecond-Accuracy Time Synchronization Using the IEEE 802.15.4 TSCH Protocol[END_REF]).

F. Security

Our implementation performs TSCH and 6TiSCH security as per the standard documents, with distinct security keys for beacons and data traffic (C1). For portability, we rely on Contiki's generic AES-CCM interface, which can perform frame encryption and decryption by using the cryptographic hardware acceleration capability available on a number of chips supported by Contiki (C3). For timing accuracy, we encrypt the full frame as early as possible during a timeslot, go back to sleep and wakeup a few microseconds prior to actual transmission (C2). At the receive end, however, the incoming frame must be decrypted and the outgoing ACK encrypted, right in the critical path. The standard provisions 1000 µs for this operation, and this duration proved sufficient for most hardware platforms we experimented with. Platforms without a cryptographic coprocessor have to run in networks where looser timeslot timings are accepted.

G. Interaction with RPL

We offer a configurable interface for the interaction between TSCH and upper layers, RPL in particular (C5). The interface is basically a set of callbacks that notify RPL that TSCH has joined or left a network, and that RPL uses to notify TSCH of a parent switch or new beaconing interval. This enables to implement the 6TiSCH architecture, which, for instance, defines how to map the RPL rank (distance to the root) and preferred parent to the TSCH join priority and time source. It also makes it possible to flush the RPL state whenever leaving a TSCH network, for a clean-slate re-join.

H. Scheduling

Scheduling is out of the scope of the TSCH standard, and is not yet fully covered by 6TiSCH either. Our implementation provides a software API for scheduling, supporting slotframe and timeslot addition, removal and update. By default, we run the so-called 6TiSCH minimal configuration (C1), where all communication takes place on a single timeslot, within a single slotframe, based on contention. This results in a behavior equivalent to slotted ALOHA [START_REF] Roberts | Aloha packet system with and without slots and capture[END_REF]. Alternatively, we provide Orchestra [START_REF] Duquennoy | Robust Mesh Networks Through Autonomously Scheduled TSCH[END_REF], which is an autonomous scheduler, where nodes compute their schedule locally, based on their routing state. With Orchestra, timeslot coordinates are simply based on a hash of the node's and neighbor's MAC addresses. The standardization of this mechanism in 6TiSCH is currently under discussion.

I. Logging

Logging through UART communication is made difficult by the timing constraints of TSCH (C2). Our implementation provides a logging module that enables delayed logging from timing-critical interrupts. The logs are simply written to a queue, and converted to human-readable format and dumped over UART later, from a process outside of interrupt context.

J. Portability

One of our main design goals is portability (C3). Our implementation is done as a MAC-layer module of Contiki, i.e., it follows well-defined interfaces to the upper layers (6LoWPAN) and lower layers (radio drivers). In addition to the existing Contiki requirements, a hardware platform must provide the following features in order to run TSCH: • Radio poll mode: Disables radio interrupts -instead, the MAC layer will poll the radio for new frames; • Timestamping: Radios must provide access to packet timestamps (required at join time, used my most platforms for subsequent synchronization); • Raw Tx/Rx modes: To run TSCH, the radio must support disabling automatic channel check assessment (CCA), automatic transmission of ACK frames and address filtering; • Radio delays: Drivers must provide numbers on the H/W delay involved when turning the radio on or transmitting. Because of our portability goals, we chose not to exploit hardware-specific features of certain platforms. For instance, the jn516x SoC offers advanced radio management features such as delayed transmissions (the MCU sleeps during the delay), or time-bounded listening (listen until a packet is received or some deadline is reached). Both these features would make for a more energy-efficient implementation on that specific platform, but would increase complexity in the TSCH codebase and make it less portable. Another optimization we choose not to implement is to overlap packet loading with transmission and packet reading with reception. It is possible as well to inline packet encryption/decryption with Tx/Rx on many platforms by utilizing special features on their cryptographic coprocessor, instead of encrypting first and transmitting later. The effect of these is shorter slot times, but it would make the code less portable.

K. Interoperability Tests and Supported Platforms

Contiki versions of TSCH were demonstrated to be interoperable (C1) in the ETSI plug-tests in Prague (2015) and in Paris (2016). In these events, it was tested against a number of independent implementations, including the de facto reference OpenWSN [START_REF] Watteyne | OpenWSN: a standards-based low-power wireless development environment[END_REF].

A year after its release, our implementation has already been ported to 9 hardware platforms (C3), involving 6 different radio chips. Tab. I provides a summary of the currently supported platforms and their peculiarities. The current platforms include 16-and 32-bit architectures, with low-and high-frequency crystal oscillators, and over both 2.4 GHz and 868 MHz. In the 2.4 GHz case, the slot length varies between 15 ms (legacy platforms, with slower interfaces) and 10 ms (the default in IEEE 802.15.4-2015 and IETF 6TiSCH). In the 868 MHz case, where the cc1200 radio hardware runs in 802.15.4g mode at 50 kbps, the slot is made as large as 32 ms assuming a maximum frame length of 127byte frames (note that the standard allows up to 2047 bytes).

V. PERFORMANCE EVALUATION

This section analyzes the performance of TSCH and compares it to state-of-the-art MAC layers.

A. Synchronization

We evaluate our system's ability to keep global synchronization in a large-scale network. We use the FIT IoT-LAB testbed in Grenoble [START_REF] Adjih | FIT IoT-LAB: A large scale open experimental IoT testbed[END_REF] with 340 M3 nodes at the time of the experiments. The nodes run raw TSCH, without 6TiSCH. Nodes basically listen for a beacon and attach to the first node they hear (average hop count: 5.2). Please note that on a few occasions (we recorded eight in the course of this experiment), nodes attach to a time source they have a very weak link to, to only later lose synchronization and rejoin. In real networks, with 6TiSCH running on top, TSCH would use the links selected by RPL at the routing layer, with guaranteed connectivity.

The setup is as follows: nodes transmit a beacon every 20 s. If a node does not hear from its parent for 30 s, it initiates a keep-alive. After learning the relative drift to its parent, the keep-alive timeout extends to 120 s. Doing so, we base synchronization primarily on beacons, with keep-alive as a fallback. Such a setup is particularly suited to dense networks, where a single beacon is enough to re-synchronize many nodes.

We use Orchestra [START_REF] Duquennoy | Robust Mesh Networks Through Autonomously Scheduled TSCH[END_REF] for scheduling, with two slotframes. The first slotframe is for beacons, with length 397 and an Orchestra sender-based slot. The second slotframe is for keepalives, with length 101, and an Orchestra receiver-based slot. Fig. 3 shows the results from a 60 min experiment.

It takes less than 90 s for all nodes to join, as shown in Fig. 3a. Fig. 3b shows the nodes' relative drift to their time source, as computed by our internal drift compensation mechanism. The largest recorded drift was 9 ppm. Fig. 3c shows the time corrections applied by the nodes during the run. Here, nodes use the TSCH standard guard time, of ±1100 µs. After a few minutes, nodes adjust to their time source's drift, and get more tightly synchronized. Quite interestingly, over 97 % of the packets recorded were received with an error below 160 µs. This level of synchronization is sufficient to enable capture effect; a phenomenon that TSCH benefits from in contention-based slots.

Note that after convergence (the few first minutes), all nodes reach a duty cycle of about 0.3 %. TSCH results in particularly low channel utilization, here only 0.008 % at each node, spread over 16 channels. Most of the energy is spent listening, and more fine-tuning of guard times could further reduce the baseline cost.

B. Comparison against other MAC Protocols

We compare the performance of TSCH with traditional IoT MAC layers -low-power listening (LPL) and alwayson CSMA -in terms of reliability, latency and energy. To this end, we set up a small controllable testbed with five CC2650 SoC nodes [START_REF] Fafoutis | Demo: SPES-2-A Sensing Platform for Maintenance-Free Residential Monitoring[END_REF]. The nodes are connected in a star network. As the LPL protocol we use ContikiMAC [START_REF] Dunkels | The ContikiMAC Radio Duty Cycling Protocol[END_REF]. For always-on CSMA, we enable the nullrdc layer of Contiki. and CSMA. For TSCH, the 6TiSCH minimal schedule and a collision-free schedule are compared. Note the log y-scale used for latency. Note that the duty radio cycle for CSMA is 100 %, not fully shown in the graph.

We compare two schedules of TSCH: the 6TiSCH minimal one, with one single shared Tx/Rx slot, and a custom dedicated one, with one Tx slot assigned to each leaf node. The slotframes have a length of 9 slots. The backoff exponent for shared slots is set to 4, the TSCH guard time to 800 µsec. For LPL, the channel sampling frequency is set to 8 Hz; phase lock is enabled, with the max Tx time towards known neighbors set to 30.5 ms. The number of MAC-layer retries is 8 for all protocols. Each of the leaf nodes generates one IPv6 UDP packet at a random point during a period ranging from 0.25 s to 16 s to emulate high and low rate traffic. LPL and CSMA run on channel 25, while TSCH runs on 25 and 26.

Fig. 4 summarizes the results, discussed next. Link-layer Packet Reception Rate (PRR) The PRR is the link success rate, before MAC retries. In this topology the vast majority of lost packets are due to contention. For TSCH, this leads to an important difference between the minimal (contention-based) and dedicated schedules, especially with high-rate packet generation. For the 0.25 second packet generation interval, TSCH minimal shows 33.66 % PRR while TSCH dedicated shows 99.46 % PRR. LPL (37.2 % PRR in the 0.25 s experiment) outperforms TSCH minimal as in LPL, transmissions are more randomly distributed, while TSCH minimal offers only one slot for all nodes to contend. CSMA (93.15 % PRR in the 0.25 s experiment) outperforms LPL, as packet transmissions without LPL are shorter and less likely to collide.

End-to-end Packet Delivery Rate

The PDR is the endto-end success rate, after MAC retries. The results show that PDR in the 0.25 s experiment for TSCH minimal and LPL are below 50 %. Both the number for active slots per second and the maximal number of retransmissions are too small to accommodate for the extensive link-layer packet loss. For all other experiments, all protocols show >99 % PDR. However, only TSCH dedicated achieves consistent 100 % packet delivery rate in all scenarios.

Latency For the high-rate experiments, TSCH dedicated shows one to two orders of magnitude lower latency than TSCH minimal and LPL. Here, the main factor affecting the latency is the collision rate and the resulting MAC-layer back-off. For the low-rate experiments, the latency is similar between the three protocols. It is mostly determined by the slotframe size (for TSCH) and the channel check interval (for LPL). CSMA shows by far the best latency of all -it sends packets immediately as they are generated, leading to nearly no collision nor back-off.

Duty Cycle

The radio duty cycle of the sink node is excluded from this statistic, as sink nodes usually are mains powered. LPL is less efficient than TSCH minimal with these specific configuration settings when the datarate is high (0.25 s period). This is explained by the fact that most of the energy in low-rate TSCH networks is wasted in idle listening [START_REF] Mavromatis | Impact of Guard Time Length on IEEE 802.15.4e TSCH Energy Consumption[END_REF]. In contrast, the dedicated schedule has no idle listening and is by far the most energy-efficient (down to 0.073 % duty cycle in the 16 s experiment).

C. Energy consumption

We compare in Fig. 5 the energy consumption profile for transmission and reception of a single packet in TSCH and in LPL (ContikiMAC) and with security on/off.

In these experiments we use the maximal packet size that was supported with all four configuration settings, 98 bytes, excluding MAC header. For experiments with security enabled, the IEEE 802.15.4 packet security level is set to 0x5: data encrypted and authenticated with 32-bit MIC block [START_REF][END_REF]. Encryption and authentication is done using hardware-accelerated AES-128 algorithm.

While TSCH and LPL have roughly similar packet Rx profiles, Tx is much more efficient for TSCH because of its time-synchronized nature (notice the different x-axis scales -the result is a factor 3 in cumulative energy). LPL repeats the packet transmissions several times to wake the receiver up, while TSCH transmits it only once. Another major difference is that TSCH does not perform CCA (unless configured to do so), while LPL shows multiple CCA peaks before the transmissions start (needed by to resolve contention in a unslotted context).

All recordings start with approximately 1 ms long period of approximately 5 mA current level. This is the time required for the CC2650 radio to become fully operational. LPL Tx activity proceeds by doing the CCA checks. Subsequently, for Tx activities, the packet is loaded in the FIFO (<1 ms), and then transmitted (approximately 4 ms). In Rx mode, after receiving the packet, it is decrypted if required and an ACK is created and transmitted.

Enabling security increases packet size just by a few bytes (depending on the protocol), hence has no large impact on Tx/Rx duration. However, for TSCH Rx the packet must be decrypted before an ACK is generated. This is visible in the graphs as increased energy consumption between packet and ACK transmission. The additional time required to encrypt or decrypt the packet on CC2650 is 340 µs (±30 µs) according to our measurements. Also note that with LPL, reception starts earlier with security than without: this is only incidental, caused by the randomness in the time between the node's wakeup and the start of actual packet reception.

Note that on CC2650 the radio is not turned off between the packet and the ACK; this behavior is different on other Contiki platforms, for example, CC2240 and CC2538.

VI. RELATED WORK

This section reviews work related to TSCH and 6TiSCH. Synchronization A key to achieving tight and low-power time synchronization in TSCH is for nodes to learn the relative drift to their time source(s). Stanislowski [START_REF] Stanislowski | Adaptive synchronization in IEEE802.15.4e networks[END_REF] showed it was possible to consume one order of magnitude less energy by adopting adaptive drift compensation. The concept was later applied to multi-hop [START_REF] Chang | Adaptive synchronization in multi-hop tsch networks[END_REF], with an additional mechanism to cascade time synchronization from coordinator down to leaves. As a result, nodes increase their synchronization period, reaching as high as a 3 minutes.

Our implementation builds on the same principles. When running at a high synchronization frequency (period of 4 s), we have demonstrated accuracy below 1µs [START_REF] Elsts | Microsecond-Accuracy Time Synchronization Using the IEEE 802.15.4 TSCH Protocol[END_REF]. Further, we also evaluated in details the impact of guard times on energy consumption [START_REF] Mavromatis | Impact of Guard Time Length on IEEE 802.15.4e TSCH Energy Consumption[END_REF]. Channel Hopping Watteyne et al. [START_REF] Watteyne | Mitigating Multipath Fading through Channel Hopping in Wireless Sensor Networks[END_REF] proposed an indepth evaluation of channel hopping in the TSCH context. Trace-driven simulation results show how channel hopping mitigates multi-path fading and interference. By default, TSCH uses all available 16 channels of the IEEE 802.15.4 PHY layer. Hopping blindly over all channels enables reliable operation even when a subset of the channels has poor quality. Adaptive channel blacklisting was nonetheless proposed [START_REF] Elsts | Adaptive Channel Selection in[END_REF] that pushes reliability and throughput further.

By standard, a coordinator can advertise its own hopping sequence, that joining nodes will learn when receiving beacons. Our implementation supports this feature, enabling an administrator to perform (re-)deployment-time blacklisting.

Scheduling

Scheduling in TSCH and 6TiSCH has received significant attention from both a theoretical and practical standpoints. Early solutions where focusing on static networks with pre-defined traffic patterns [START_REF] Doherty | Channel-Specific Wireless Sensor Network Path Data[END_REF], [START_REF] Palattella | Traffic aware scheduling algorithm for reliable low-power multi-hop ieee 802.15.4e networks[END_REF]. With a centralized scheduler, these solutions demonstrated reliability over 99.999%. Distributed solutions were later proposed, e.g., by Tinka et al. [START_REF] Tinka | A Decentralized Scheduling Algorithm for Time Synchronized Channel Hopping[END_REF], where a rendez-vous slot is used for discovery and slot installation. Another interesting approach is to perform multi-hop reservation and label switching [START_REF] Morell | Label switching over IEEE[END_REF]. On-the-fly resource reservation in a 6TiSCH context was demonstrated by Palattella et al. [START_REF] Palattella | On-the-fly bandwidth reservation for 6tisch wireless industrial networks[END_REF], demonstrating reliable operation in a 50 node network (simulation).

Our scheduler Orchestra [START_REF] Duquennoy | Robust Mesh Networks Through Autonomously Scheduled TSCH[END_REF] is complementary, as it provides a basic schedule that nodes can maintain autonomously, simply based on the local knowledge of their neighborhood. Orchestra can potentially be used jointly with other schedulers.

Other MAC-layer Aspects

We presented fine-grained energy measurements of the energy overhead of link-layer security in TSCH. On a very related topic, Sciancalepore et al. [START_REF] Sciancalepore | Link-layer security in tsch networks: effect on slot duration[END_REF] dissected the impact of various security levels on timeslot length on a wide range of platforms. Their measurements show that the minimal timeslot length varies greatly among platforms, ranging from 9 to 88 ms.

Finally, Deguglielmo et al. [START_REF] Guglielmo | Analysis and experimental evaluation of IEEE 802.15.4e TSCH CSMA-CA Algorithm[END_REF] proposed an analytical model of the back-off mechanism in TSCH, taking into account the occurrence of capture effect in shared slots.

VII. CONCLUSION

We discussed and addressed the main challenges that lie in providing a flexible and efficient TSCH and 6TiSCH implementation. Through our Contiki implementation and a series of testbed experiments, we find that: (1) Synchronization in large (340 nodes) networks is possible at high accuracy (97% of the time under 160 µs) for a low cost (duty cycle of 0.3%);

(2) TSCH, when running dedicated slots, outperforms LPL in all key metrics: reliability, latency, duty cycle; (3) At a micro-level, a TSCH and LPL spend about the same amount of energy for receptions, but TSCH has an edge (factor 3) on transmissions. Link-layer security comes at a low overhead. We believe our implementation to be an enabler for more further research, in particular as it brings the 6TiSCH stack to the Contiki ecosystem, where a variety of upper-layer protocols and applications already exist.

Figure 1 .

 1 Figure 1. Diagram of a standard TSCH timeslot and example slotframe.A timeslot is typically 10 ms long. Blank time before/between/after frames are for processing: queuing and cryptography. Slotframes can be of any finite length; they repeat over time.

Figure 3 .Figure 4 .

 34 Figure 3. Time synchronization experiment, 340 nodes. (a) Shows the number of joined nodes at any given time after bootstrap. (b) Shows the distribution of the nodes' drift to their time source. (c) Shows how synchronization errors evolve with time. The duty cycle converges to 0.3 %.

Figure 5 .

 5 Figure 5. Energy usage profiles for Tx and Rx of a single packet. 98 byte packet size, excluding MAC headers. Note the x-axis scale for "LPL, Tx".

Table I .

 I OVERVIEW OF THE PLATFORMS CURRENTLY SUPPORTED BY OUR TSCH/6TISCH IMPLEMENTATION.

	Platform	MCU	Timer(s)	Radio	Timeslot (ms) Largest experiment to date
	Tmote Sky	msp430 (16 bits)	32.768 kHz	cc2420 (2.4 GHz)	15 98 nodes (Indriya [3])
	Zolertia Z1	msp430 (16 bits)	32.768 kHz	cc2420 (2.4 GHz)	15 A few nodes
	NXP jn516x	OpenRISC (32 bits)	32.768 kHz or 16 MHz	jn516x (2.4 GHz)	10 25 nodes (private testbed)
	cc2538dk	Cortex-M3 (32 bits) 32.768 kHz	cc2538 (2.4 GHz)	10 A few nodes
	OpenMote-cc2538	Cortex-M3 (32 bits) 32.768 kHz	cc2538 (2.4 GHz)	10 A few nodes
	Zolertia Zoul	Cortex-M3 (32 bits) 32.768 kHz	cc2538 (2.4 GHz)	10 25 nodes (private testbed)
				cc1200 (868 MHz)	32
	cc2650dk	Cortex-M3 (32 bits) 65.536 kHz and 4 MHz cc2650 (2.4 GHz)	10 A few nodes
	SPES-2 [11]	Cortex-M3 (32 bits) 65.536 kHz and 4 MHz cc2650 (2.4 GHz)	10 14 nodes (private testbed)
	IoT-LAB M3 node Cortex-M3 (32 bits) 32.768 kHz	AVR rf2xx (2.4 GHz)	10 348 nodes (IoT-LAB Grenoble [1])


Y L Xiong

C H Bruneau

H Kellay

Drag enhancement and drag reduction in viscoelastic fluid flow around a cylinder

Keywords: 47, 20, Gv -Viscous and viscoelastic instabilities 47, 27, ek -Direct numerical simulations 47, 27, nd -Channel flow

We here use direct numerical simulations to describe the flow of a viscoelastic fluid, modeled using the so-called Oldroyd B model, around a cylinder in two dimensions. A wide range of flow parameters is covered in these simulations allowing to draw definitive conclusions as to the effect of viscoelasticity on such a flow situation. Both drag enhancement and drag reduction are observed and a phase diagram is proposed in the parameter space Reynolds number vs. Weissenberg number. While only drag enhancement is observed below a Reynolds number of 40, both drag enhancement and drag reduction are observed for higher Reynolds numbers indicating that drag reduction is a feature associated with the shedding of vortices behind the cylinder. An interesting observation accompanies the onset of drag enhancement in the vortex-shedding regime: the shedding is suppressed.

One of the most important problems in non-Newtonian fluid mechanics is drag reduction. This peculiar flow feature common to a variety of complex fluids is perhaps the most useful ingredient for transporting fluids over large distances at a reduced cost and for minimizing losses for flows in the presence of obstacles [START_REF] Gyr | Drag Reduction of Turbulent Flows by Additives[END_REF]. Several applications have ensued following the discovery of the drag-reducing ability of several fluids, especially polymer solutions and surfactant solutions. Many attempts at understanding this phenomenon have brought the subject to a relatively mature state with different proposed mechanisms such as the ability of polymers to modify the boundary layer flow or their ability to stretch in a variety of flows [START_REF] Tabor | [END_REF][3][4]. Still the issue is far from being completely understood and experiments as well as numerical simulations are used routinely to shed light on the problem.

A now standard situation to understand flows of complex fluids, and notably those giving rise to drag reduction, is flow past a cylinder [5]. Let us recall that such a situation is widely studied, experimentally, for low Reynolds numbers where important drag enhancement has been observed and documented for different fluids [6][7][8]. Simulations have addressed the issue and observations of such enhancement have been reported [9][10][11][12]. A complication with some of the experiments is the presence of shear-thinning effects which may influence the drag. Experiments with Boger fluids [8,13] minimize such effects. For high Reynolds numbers, few experiments have been carried out in two-dimensional systems but the modification of the vortex street behind a cylinder [14] and turbulent drag reduction have been reported both experimentally for an array of cylinders and numerically [15,16]. An important question is how does the drag on a cylinder vary in the parameter space described by the two dimensionless numbers namely the Weissenberg number and the Reynolds number.

We here study the simple case of flow around a cylinder of a viscoelastic fluid in two dimensions using direct numerical simulations to cover a wide range in both the Reynolds number Re and the Weissenberg number W i which measures the ability of the fluid to change properties with respect to external stresses. To our knowledge this is the most comprehensive study to date. We measure the drag on the cylinder and show that this simple flow situation presents a non-trivial transition from drag enhancement to drag reduction. A full phase diagram in the parameter space Re-W i extending for 5 decades in Reynolds number is presented showing the extent of the different regimes. Attention is then brought to the stresses, pressure, elongation, and shear distributions in the flow domain.

The dynamics of an incompressible two-dimensional viscoelastic Oldroyd-B constitutive fluid is described by the following non-dimensional equations which are penalized to represent the solid body on a Cartesian mesh of the domain whose length is 4 times its width:

∇ • u = 0, ∂ t u + (u • ∇)u + u K = -∇p + 1 Re [(1 -)∆u + W i ∇ • σ], ∂ t σ + (u • ∇)σ + σ K + σ -I W i = (∇u) • σ +σ • (∇u) T + κ∆σ,
where u is the two-dimensional velocity vector, p is the pressure, σ is the conformation tensor of polymer molecules, their elongation is measured by its trace; K is the non-dimensional permeability coefficient used in the penalization term. It is set to 10 16 in the fluid zone to recover the genuine equations and to 10 -7 in the solid cylinder to enforce u and σ to vanish [17]. The quantity (1 -) denotes the ratio of the solvent viscosity to the viscosity of polymer solution, it is 0.99 in our simulations. The term κ∆σ is an artificial diffusive term to prevent numerical instabilities [18]. The Reynolds number Re and the Weissenberg number W i are non-dimensionalized by the same referenced velocity and length. In our results, the Drag coefficient Cd is defined by F/ρU 2 R, Re and W i are defined by Re = 2UR/η and W i = τ U/R, respectively, where U is the mean velocity of the inlet Poiseuille flow, R = 0.05 is the radius of the cylinder located at (1, 0.5) (i.e. in the middle of the channel at one width from the entrance), F is the drag force on the cylinder, η and τ are, respectively, the viscosity and the relaxation time of the polymer solutions. The numerical simulations are carried out by a multigrid method with a 2048 × 512 fine grid and a finite-differences approximation [19]. This numerical scheme has been shown to give excellent agreement with experimental measurements of two-dimensional flows in the turbulent state [20]. It should be noted that the choice of the Oldroyd-B model is dictated by its simplicity despite the fact that it has limitations [21]. This model has also been shown to display several features observed in experiments such as drag reduction and elastic turbulence [16].

Our main result is illustrated in fig. 1 which shows a phase diagram of the different regimes observed in the parameter space Re-W i. This graph shows that three regions can be identified for the behavior of the drag on the cylinder: A Newtonian regime for low W i, a drag enhancement regime for high W i, and a drag-reducing regime for intermediate W i. This drag reduction regime exists only for Re greater than 40. Indeed, for Re 40, only two regimes are observed: either the fluid is acting as its Newtonian counterpart for small values of W i below a threshold W i 2 or the fluid shows enhanced drag on the cylinder for W i > W i 2 . For Re > 40, three different regions are observed. Below a first threshold value which we call W i 1 , the fluid behaves as a Newtonian fluid. For intermediate values between W i 1 and W i 2 , drag reduction is obtained. Above W i 2 , only drag enhancement is observed. This diagram, which spans roughly 5 decades in Reynolds number, summarizes our findings and shows that both drag enhancement and drag reduction can be obtained but only for specific parts of the parameter space. To our knowledge, no such insight into both drag reduction and drag enhancement has been brought forth before and our results show that both phenomena can be related in a full-parameter space representation. Both drag reduction and drag enhancement are present in our simulations but in different regions of the phase diagram. The phase diagram of this behavior is an important result which, though it has been shown before for particular values of the Reynolds number, has not been put forth in such a systematic manner. In addition to these considerations, the maximum drag reduction turns out to be near 50% and is practically independent of the Reynolds number in the asymptotic large Re limit. It should be noted here that the transition from drag enhancement to both drag reduction and drag enhancement occurs at a value of the Reynolds number close to Re = 40, which coincides with the transition to the vortex-shedding regime for the wake behind the cylinder pointing to a strong dependence on the structure of the flow and to the presence of vortices. Other interesting features emerge such as the suppression of the vortex shedding in the drag enhancement regime.

Figure 2 displays the main flow features observed in this study: The vorticity contour plots are shown for Another interesting feature is the increase in the length of the wake in the drag reduction regime: vortex formation occurs at locations that are farther and farther away from the cylinder as W i increases. These two aspects of the flow structure can be further appreciated through the power spectrum of transverse-velocity variations downstream of the cylinder. Indeed, and as fig. 2d shows, the power spectrum shows a well-defined peak at the shedding frequency for the Newtonian fluid. The height of this peak decreases as the Weissenberg number increases up to its disappearance for W i > W i 2 . We also noted that for the drag reduction regime, the amplitude of the higher harmonics seems to increase with respect to the Newtonian case indicating a large deformation of the wake. Experiments using soap films, for which the flow field is quasi-two-dimensional due to the small thickness of the film, have discussed such an effect as the shedding length increases upon addition of polymer [14]. Here, the shedding length becomes large enough that no shedding is observed in the flow domain used. When this occurs, the drag starts to increase considerably.

Figures 3a andb display a quantitative measurement of the effect of the viscoelasticity. We plot the drag on the cylinder (normalized by the Newtonian drag) for different Reynolds numbers and varying Weissenberg numbers. Two different behaviors are observed as shown in fig. 3a. For Re < 40, the drag is similar to that of the Newtonian fluid for small W i. However, above W i 2 , the drag increases vs. W i. This regime shows the wellknown drag enhancement observed in three-dimensional experiments using spheres or cylinders in low Reynolds number flows [6][7][8], an effect which is well captured by the simulations presented here for the model we have used. The drag is enhanced by a factor which can be as large as 250%. When the Reynolds number is above 40, a different behavior emerges: drag reduction (which can reach 50%) is observed above a first threshold value of W i denoted W i 1 before the appearance of drag enhancement for W i > W i 2 (as for the low Re). This behavior is now shown in fig. 3b for all the Reynolds numbers we have examined in this study (except for Re = 50000) vs. the reduced Weissenberg number (W i/W i 2 ). This figure clearly shows the difference between the low Reynolds numbers for which only drag enhancement is observed for W i/W i 2 > 1 and the high Reynolds numbers for which drag reduction is observed in an interval of W i/W i 2 below 1. The values of the increase in drag do not collapse perfectly for values of the reduced W i/W i 2 above 1. For the low Re, the increase is slow at first before a rapid rise while for higher Re, the increase is fast for W i/W i 2 > 1. The reduction in drag increases as the Reynolds number increases and seems to reach a saturation value for Re near 2000. The drag reduction window (values of W i for which drag reduction occurs) varies with Re as fig. 1 shows; its extent increases as Re increases before saturating for higher Re. Figure 4 shows the maximum drag reduction vs. the Reynolds number and as remarked above, this drag reduction sets in only above Re = 40 and increases for values of Re between 40 and 1000 from nearly 0 to 50 percent. This reduction then goes through a mild maximum at Re = 2000 before stabilizing on a plateau at about 48%. The location of the maximum drag reduction is reported in fig. 1 as a solid line. This location starts out close to the drag enhancement regime but deviates from it as Re increases and stabilizes at about 1 2 W i 2 . To further examine the behavior of viscoelastic flow around the cylinder, we plot in fig. 5 the elongation rate du/dx, the longitudinal elastic stress σ xx , as well as the pressure variation along the center line of the channel. These quantities change qualitatively as either transition is crossed. We illustrate this behavior using Re = 10 and Re = 100. For Re = 10 and for W i < W i 2 , the elongation rate is close to the Newtonian case. As W i increases, the location of maximum elongation (which is at 3 radii downstream) migrates towards the cylinder. As W i increases above W i 2 , the maximum elongation increases and its location migrates towards the cylinder wall. By contrast, for W i below W i 2 , the elongation rate near the cylinder wall is negative so as the transition from Newtonian drag to enhanced drag is crossed, the elongation near the cylinder wall changes sign. For Re = 100, for which three regimes are observed, as W i 1 is crossed (to the drag reduction zone), the maximum elongation actually decreases and its location migrates away from the cylinder wall. It is only after crossing W i 2 towards the drag enhancement regime that the maximum elongation starts to increase and its location moves towards the cylinder wall. The signature of either transition is therefore visible in the elongation rate and its variation along the center line.

On the other hand, the maximum of the stress, which occurs near the cylinder wall in the downstream region, increases as W i increases for Re = 10. At the crossing of the transition to drag enhancement, the maximum stress location migrates towards the cylinder wall. That the maximum stress location is at the cylinder wall is true also for Re = 100 in the drag enhancement regime. Both the elongation rate and the normal stress are maximal near the cylinder wall for the drag enhancement regime. Experiments in microchannels for small Reynolds numbers in the drag enhancement regime have observed large elongations of the polymers in the vicinity of the cylinder wall on the downstream side [8]. Our simulations seem to capture this essential feature of the experiments despite the fact that our simulations are two dimensional while the experiments are in three dimensions. In the drag reduction regime however, the location of maximum stress and maximum elongation is rather farther away from the cylinder (2.5 cylinder diameters). Another feature associated with the transition from drag enhancement to drag reduction vs. W i can also be appreciated through the variation of the pressure along a cut in the flow direction and in the center line of the channel. The most prominent feature here is the pressure on the downstream side of the cylinder. Note that the pressure first increases with respect to the Newtonian case as the Weissenberg number increases (this is the drag reduction regime) before decreasing to much lower values (with a sharp peak) for W i greater than W i 2 indicating a strong increase in the drag on the cylinder. The decrease in pressure is localized near the cylinder wall and its importance increases as W i increases.

The onset of drag enhancement is therefore accompanied by four distinct features: suppression of vortex shedding for Re > 40, a strong positive peak in elongation rate, strong elastic stresses, and a strong dip in pressure near the downstream side of the cylinder. The drag reduction regime is on the other hand accompanied by a rise in pressure, a reduction in elongation rate, but an increase in elastic stresses at a position slightly downstream. These In conclusion, our numerical simulations of the Oldroyd-B model in two dimensions show that drag on a cylinder can be enhanced for low Reynolds numbers but that it can be reduced for higher ones. This behavior is captured in a phase diagram in Reynolds number-Weissenberg number space showing a transition from two to three regimes. The drag enhancement regime at large Reynolds numbers is accompanied by a total suppression of the vortex-shedding instability as well as large elongation rates and a large dip in pressure at the cylinder wall on the downstream side of the cylinder. Despite the limitations of the model used, several essential features of viscoelastic flow past a cylinder are well captured by the calculations presented here.

Fig. 1 :

 1 Fig. 1: (Colour on-line) Phase Diagram in Re-W i space indicating the drag enhancement and drag reduction regimes. The solid line connecting the small circles indicates the locatin of maximum drag reduction.

Fig. 2 :

 2 Fig. 2: (Colour on-line) Flow structure around a cylinder for Re = 1000 and different W i (a: W i = 0, b: W i = 2, c: W i = 6). d: spectrum of the transverse component of the velocity for different W i.

Fig. 3 :

 3 Fig. 3: (Colour on-line) a) Drag on the cylinder, normalized by the Newtonian drag, vs. W i for two different Re. Note the drag enhancement at low Re and both drag enhancement and drag reduction for the higher Re. b) normalized drag vs. reduced W i for different Re.

Fig. 4 :

 4 Fig. 4: The percentage of maximum drag reduction vs. Reynolds number.

Fig. 5 :

 5 Fig. 5: (Colour on-line) Elongation, longitudinal elastic stress, and pressure variation along the center line of the channel for two different Reynolds numbers and different W i.