dataesr/scientific-paragraphs-categorization huggingface dataset:
In this paper, we investigate and present how to generate application traces of IoT (Internet of Things) Applications in an automated, repeatable and reproducible manner. By using the FIT IoT-Lab large scale testbed and relying on state-of-the-art software engineering techniques, we are able to produce, collect and share artifacts and datasets in an automated way. This makes it easy to track the impact of software updates or changes in the radio environment both on a small scale, e. g. during a single day, and on a large scale, e. g. during several weeks. By providing both the source code for the trace generation as well as the resulting datasets, we hope to reduce the learning curve to develop such applications and encourage reusability as well as pave the way for the replication of our results.
Network data sets are also useful to detect anomalous activity or signature behavior of already known attacks by training machine learning  [18, 32]  or deep learning  [12]  models. Finally, network IoT data alleviates forecasting networks congestion  [30]  or the traffic load  [23]  to tackle allocation and management decisions. Because various types of bias may be present in data  [24] , and such bias may in turn lead to algorithmic unfairness or other unwanted behaviours, it is important to take great care when designing and creating datasets. Although replicability 1  appears as the best way to increase confidence of results building on such experimental artifacts, intermediate steps such as repeatability and reproducibility may also promote the integrity of such results. Repeatability for the creation of datasets is especially important for the IoT and wireless networking domains, as the radio spectrum, the communication technologies or the operating systems powering such networks undergo constant changes, rendering datasets obsolete, or worse, damaging.
In this work, we use the FIT IoT-LAB testbed. FIT IoT-LAB is an open large-scale testbed with wireless sensor nodes and mobile robots  [1]. Each node is openly programmable and it comes with convenient tools to gather the experiments' results, making it ideal to generate datasets. We show how we generated different types of network traffic data with the FIT IoT-LAB testbed thanks to our Sisyphe tool. In addition, we provide our results, methods and tools to be entirely reusable and reproducible and share them. Our contributions are threefold : • We present the architecture of Sisyphe and illustrate its use by generating two datasets using the FIT IoT-Lab testbed. • For each dataset, we discuss the experiment setup and present the results obtained. These results are available to be directly usable.
• We make available all the source code and tools used for each dataset on a public repository. The remainder of this paper is organized as follows. Section 2 presents the architecture of Sisyphe. Section 3 introduces the two different considered scenarios and their peculiarities. The scenarios are then covered in details in 3. 1 and 3. 2. Section 4 provides some usage examples of these datasets. Finally, Section 5 positions Sisyphe and these contributions with regards to literature before Section 6 concludes this paper by discussing future work.
Source code archiving. To tackle the source code availability problematic, the source code of the Sisyphe platform as well as the source code of the experiments run on the platform are distributed under open-source licences. Yet, distributing the source code, for example by hosting an archive on some institutional or personal web-page is not enough. Indeed, they may disappear on the occasion of a website redesign or a change of affiliation. Thus, source code sharing platforms such as Github or Gitlab represent a more promising avenue. However, recent history  [5, 7, 19]  has shown they are not perfect because they can also close. To ensure source code availability, we therefore rely on software archiving made possible by Software Heritage  [10]. It is a non-profit organization backed by Inria and the UNESCO, whose goal is to establish a long-term software and source code archive.
In particular, unique and stable identifiers called SWHID are attributed to the different software components of Sisyphe ensuring an easy access to those components source code. For example, the identifier of the Sisyphe source code, available at https://github. com/sisyphe-re/infrastructure-ng is swh:1:dir:6b23bcefe73bbaea308b6ea99d7e75cd37ded16fe and allows the exploration of a project's source code in a similar way to the Github web interface. In addition to preserving the source code of the platform, Software Heritage is also used to archive the source code of the experiments every time they are run in an automated manner. In particular, we ensure that the source code is present in the Software Heritage archive before running the experiments, preventing mismatch between the ongoing experiment and what is archived in a long-term manner.
Reproducible Builds. Any researcher that already tried to run old code they wrote for a scientific contribution knows how hard this can be. Having access to the source code is only one part from the broader "reproducibility challenge", as underlined by the results from the "Ten Years Reproducibility Challenge" presented in  [27]  : lacking documentation or access to obsolete computing environments can also represent hard obstacles to overcome. In Sisyphe , we use the Nix package manager  [14]  and the NixOS  [15]  Linux distribution to provide reproducible development and computing environments. Nix uses a functional approach to package management by linking software and their dependencies using cryptographic hashes. It so allow us to provide an easy way for third-party to re-use our code, without impacting the rest of their system.
For example, it is possible to build the RIOT-OS based firmwares from Section 3. 2, without having to deal with the so-called "dependency hell", and as long as the Nix package manager is available, by using a single command, namely 'nix build', as shown on 1. Listing 1: Firmware Compilation using Nix $ g i t c l o n e g i t @ g i t h u b. com : s i s y p h e -r e / f i r m w a r e s $ cd f i r m w a r e s / $ n i x b u i l d [ 1 b u i l t ] $ l s r e s u l t / g n r c _ b o r d e r _ r o u t e r. e l f g n r c _ n e t w o r k i n g. e l f The more global architecture of Sisyphe is itself written in Nix and based on the NixOS Operating System and thus adopt the "Infrastructure As Code" paradigm. Nix and NixOS try to be reproducible down to the bit level, they so detect quickly existing projects that exhibit non-deterministic patterns in their builds.
We discovered an example of such behaviour in the RIOT operating system's code during the development of Sisyphe 3. Testbeds. As mentioned in  [9, 27] , hardware access may also hinder reproducibility, especially when it involves exotic hardware. Providing remote access to standard x86_64 machines might not be useful for reproducibility of system research, as it is easy to gain access to such machines (at least in 2021), but networks and especially IoT networks are a different matter. The fast pace of evolution of such networks means some hardware can be sunset in just a few years time. Moreover, their diversity means reproducing some experiment might come at a high cost, in terms of hardware roll-out or time. We ease the reproduction process in Sisyphe by using testbeds, instead of relying on local deployments.
Continuous Integration and Automation. The radio environment evolves quickly with the evolution of radio spectrum allocation, changes in the users habits, changes in the communication technology, changes in the applications, operating systems. Thus, Sisyphe adopts a continuous integration and full automation approach for the creation of datasets. Such automation allow identification of IoT networks' global trends, for example about the performance of this or that algorithm implemented in some operating system. Thus, it gain insight into the development of real networks. Most importantly, full automation decouples the experiment from the experimenter and highlight implicit dependencies that may otherwise be hidden. Indeed, the initial work put into automation effort is a form of documentation.
Architecture The global architecture of Sisyphe is presented in Figure  1. The processing pipeline is divided in two main steps, each with different level of reproducibility. The first one is the automated build step, which uses experiment blueprints ,from source code repositories, to create artifacts. These artifacts are then used during the second step, which is the automated evaluation step. Sisyphe built blueprints with Nix flakes, which are experimental features for easy containerization and composability of Nix-based projects  [13]. This assumes that the blueprints are already nix and flakes ready, like in Section 3. 2. In the case they are not, a bit of work might be needed as shown in Section 3. 1 and some intermediate adapter code is needed. Sisyphe assumes that calling "nix build" will build the artifacts and expose a "run" executable for launching the experiment.
Indeed, while the compilation environment is set up using Nix in Sisyphe , Nix is not used directly to build the firmwares. The source code is fetched on-the-fly in a non-reproducible manner over the internet, that is to say using Git. Any change in the source code repository will not be detected by the system: this first evaluation scenario is used to present how an existing code could be used in Sisyphe with minimal changes. The duration of the experiments are limited to at most 90 minutes. The second artifact uses the RIOT IOT Operating System  [2] , and is Sisyphe -ready, as it already uses Nix to build the firmwares and the different scripts used for the experiment execution. This second artifact is used to present how a more tailored experiment code can be used with Sisyphe. The duration of the experiments are longer, as each scenario runs for one week.
To generate simple traces for link evaluation, we based our firmware on a publicly available example based on Contiki 5  which sends broadcast messages on a regular basis. We made small modifications to adjust the behavior to our needs. To easily and quickly run experiments, we wrote a simple script which takes the following experimental parameters as input: the experiment duration, the sending frequency, the packets' payload size and the list of nodes used in the experiment. We have defined these parameters according to the characterization of the scenario done previously. They are summarized in Table  1. To get information about the nodes operations, they are configured to output data on their serial links as soon as they send or receive packets. For the hardware side, we chose to use the open nodes M3  6.
Those are based on STM32 micro-controllers and an ARM Cortex M3 processor. They offer power and flexibility, and thus are the ones that meets the largest number of applications. Our script execute the following operations. The firmware code is modified, based on the experimental parameters that are given. Then the firmware is compiled, and the nodes that takes part in the experiment are booked using the IoT-LAB tools. The serial aggregator from the toolset is started to log the serial output of every node from the experiment. For every line of log, a timestamp is registered along the source node's name. Once the experiment is ready to begin, the firmware is uploaded on the nodes. After the given duration of the experiment, the results are retrieved from the remote IoT-LAB server and a copy is stored on the local computer.
With that, we obtain a simple yet complete dataset about one hop communications. That dataset can then be used to train automatic learning models which needs realistic information and metrics about specific applications and experimental settings. In our work, we use the dataset to predict the communication's delay, based on the network's state and use case. To that end, we wrote scripts to automatically extract, compute, and graph different metrics about the dataset. Those scripts are made with Python, and freely available in open access on our Gitlab repository  7. Based on the needs, metrics can be simply extracted and graphed with quick modifications of the available scripts. Our scripts are intended to be reusable to extract other metrics, such as the message window, or other data with the same format.
Results. The results are gathered either from the server or from the sensors by a script running on the FIT IoT-Lab frontend servers. In particular, the border routers are not gathering any statistics to avoid such data collection to interfere with the experiment, as their serial link is already for the ethernet-over-serial (ethos) connection. The results for each scenario are streamed and compressed using the ZSTD compression algorithm 8 directly to Sisyphe server where they can be post-processed after the end of the experiment, in particular to format them. Originally formatted as text, the results 8 https://github. com/facebook/zstd are transformed into SQLite3 databases to allow for easy manipulation and querying. For the moment, we kept the database format simple, in particular by using no relationship between the tables, using SQLite3 as a poor man's binary file format.
Such databases are also compressed using ZSTD, as their uncompressed size can reach 100GB for an experiment of one week. The databases comprise tables with different level of information, from high level layer 3 statistics to low level phy information, e. g. average reception power of the frames of this or that neighbor in the RPL DODAG. While we will not go into the details of the database schema, which is documented in the campaign repository  9  , we present in Listing 2 an example of operation on the data. Theses operations give us the transmission timestamp, the sensor ID and reception timestamp for the first 5 received packets of the dataset. Listing 2: Example of simple data manipulation of the generated data $ s q l i t e 3 h v a c _ 2 6 3 6 8 5. db3 S Q L i t e v e r s i o n 3. 3 5.
POSSIBLE USAGES Traces of IoT applications are valuable information for wireless networks architectures, like edge computing. We can use datasets to train and evaluate resource allocation and task offloading mechanisms. Edge computing is characterized by a highly dynamic environment and heterogeneity of applications and resources. Thus, data driven modeling is a prominent solution for this type of network. Real time schedulers can recognise trace patterns and allocate resources such as memory, bandwidth and CPU, among users to optimize the network efficiency and reduce costs. Scheduling algorithms  [8]  decide the amount of resources allocated and the duration of each allocation into two different layers. In the first layer, resources from servers are distributed among several virtual machines.
In proactive fault-tolerance, the data traces can be used to predict potential faults and substitute the suspected node by some replicant node. In the reactive fault tolerance, we use data traces to detect the fault and take actions in order to decrease the influence of failure to improve the recovery time and the maintainability of the system. We require an advanced analysis to get meaningful insights of IoT QoS applications' behavior from generated time series datasets. QoS requirements, such as throughput, delay, and Packet Loss Ratio (PLR), associated with each IoT application helps us understand the main characteristics of these applications. Furthermore, there is a large number of IoT devices generating huge amounts of data within each application. Thus, if we predict the time varying characteristics of the device's traffic, we can guarantee a specific level of Quality of Service (QoS).
These QoS can be quantitative or ratio data type, representing the application datasets. The prediction of such metrics, by resorting to machine learning approaches, becomes of utmost importance. The machine learning architectures    efficiently extract useful features and suppress irrelevant variations in datasets  [22]. It has an ability to approximate the complex functions in order to build the prediction models for learning tasks and desired accuracy. Thus, machine learning constructs a powerful tool for QoS prediction problems by leveraging generated IoT application traces. We can predict the QoS metrics with historical datasets with various learning models, such as Recurrent Neural Network (RNN) and Long Short-Term Memory (LSTM). In a supervised learning setting, the relation between a set of input variables and one or more output variables is determined using a finite set of observations.
RELATED WORKS Pflanzner et al. [28]  provide an indexing service to retrieve open traces of applications available on the internet. [21]  presents a dataset from a test bench of solar-powered weather sensors. The data contains the power consumption and production of the application to help research in self-powered IoT applications. Xiao and al. [34]  introduce a ready-to-use on-board unit solution to collect vehicle trajectory data. Their solution contains a deep learning algorithm to fill gaps in data collection, such as GPS failures. [20]  provides a dataset from the FlockLab platform. Data collection is performed over a long period of time to capture long-term periodic patterns that affect the quality of wireless links. Software Heritage is at the heart of the source code archiving part of Sisyphe  [11] , but is not aimed at archiving experiment results or binary artifacts (such as firmwares) nor providing the automation for experiments, from the build to the results recovery, unlike Sisyphe.
, 2015)  or a footswitch device  (Alvim et al. , 2015) , but they did not all offer the same accuracy. Moreover, previous datasets were limited to <30 runners  (Alvim et al. , 2015; Leitch et al. , 2011) , which may be too small to allow generalizing the algorithm to every runner. In addition, rearfoot, midfoot, and forefoot strike patterns  (Hasegawa et al. , 2007) , which can be determined based on the foot-strike angle  (Altman and Davis, 2012) , can impact kinematic data and algorithm accuracy because they involve different biomechanical strategies  (Ruder et al. , 2019; Wei et al. , 2019). Relatively different errors (up to 30 ms) were reported for both foot-strike and toe-off among rearfoot, midfoot, and forefoot strikers using five methods  (Smith et al. , 2015). Similarly,  Leitch et al.
Experimental procedure After providing written informed consent, retroreflective markers were positioned on participants to assess their running biomechanics (Appendix A). For calibration purposes, a 5-second standing static trial using a standard anatomical position was recorded on an instrumented treadmill (Arsalis T150-FMT-MED, Louvain-la-Neuve, Belgium) for each participant. Then, a 7-minute warm-up run was performed (9 km/ h). After a short break (<5 min) participants completed three 1-minute runs (9 km/h, 11 km/h, and 13 km/h) performed in a randomized order with a 1-minute recovery between each run. These speeds were chosen because they are like those used in prior studies  (Alvim et al. , 2015; Leitch et al. , 2011; Milner and Paquette, 2015). Three-dimensional (3D) kinematic (200 Hz) and kinetic (1000 Hz) data were collected during the static trial and for the first 10 strides following the 30-second mark of the running trials.
Discussion Systematic biases were reported for foot-strike and toe-off at all speeds, refuting the first hypothesis. The RMSE was mostly constant across foot-strike angles for toe-off (7. 4 ms) but not for foot-strike (4. 1-11. 1 ms), which partly refuted the first hypothesis. Systematic biases, as well as significant differences, were reported for t c at all speeds. The RMSE for t c increased with increasing foot-strike angle (3. 5-5. 4%), thus refuting the second hypothesis. Nonetheless, smaller errors than those obtained by existing methods were obtained for footstrike, toe-off, and t c. Therefore, this novel KA can be applied to accurately estimate foot-strike, toe-off, and t c from kinematic data obtained during noninstrumented treadmill running independent of foot-strike angle. The RMSEs for foot-strike were ≤8 ms at all speeds (Table  2 ).
estimate foot-strike, toe-off, and t c from kinematic data obtained during treadmill running, independent of foot-strike angle. inertial properties and center of mass locations based on their shape  (Hanavan, 1964) , and attributed relative mass based on standard regression equations  (Dempster, 1955). The foot segment angle was defined as the orientation of the foot segment relative to the laboratory coordinate system and computed using an x-y-z Cardan sequence. The foot segment angle at foot-strike defined the foot-strike angle.
To this end we use data from two separate locations in the Swiss Alps: data set (i), recorded at Illgraben, contains signals of several dozen slope failures with low SNR; data set (ii), recorded at Pizzo Cengalo, contains only five slope failure events albeit with higher SNR. The low SNR of slope failure events in data set (i) leads to a classification accuracy of 70 % for SF, with the largest confusion between NO and SF. Although data set (ii) is highly imbalanced, lowering the prediction threshold for slope failures leads to a prediction accuracy of 80 % for SF, with the largest confusion between SF and EQ. Standard techniques to mitigate training data imbalance do not increase prediction accuracy. The classifier of data set (ii) is then used to train a model for the classification of 176 d of continuous seismic recordings containing four slope failure events.
Here, we compare the one-step approach's performance in non-ideal conditions, applying it to a data set with (i) many small slope failure events with low signal-tonoise ratio (SNR, Illgraben) and (ii) few events but a higher signal-to-noise ratio (Pizzo Cengalo). Furthermore, we show that, by adjusting our methodology to a network with a suboptimal configuration and a data set with only a few recorded events available for training, automatic detection of potential slope failures is still possible. The scope of this study is to (a) test a system of continuous classification of windowed seismic data on two different types of data sets, (b) test the influence of signal-to-noise ratios and an imbalanced training data set on classifier performance, (c) discuss insights on the transferability of trained classifiers to other sites, and (d) mimic operational conditions to assess our approach's capability as an alarm system for slope failures.
, 2009; Bennett et al. , 2013). The fractured quartzite with erosion rates of tens of centimeters per year is the main contributor to sediments transported via debris flows  (Bennett et al. , 2013). A seismic network of eight high-quality stations was installed throughout Illgraben between May and September 2017 to monitor rock-slope as well as debris-flow activity. Walter et al. (2017)  used seismic data from a similar array to locate a debris-flow front as it propagated along the channel. In this study, we focus on slope activity at the Illhorn northwest face, which at peak times is characterized by several slope failures per day. Slope failure volumes are to date not quantified, but direct field observations by the authors indicate volumes of tens to hundreds of cubic meters. We use seismic data recorded in 2017 by three seismic stations (ILL06-ILL08) located closest to the area of interest (Fig.