dataesr/scientific-paragraphs-categorization huggingface dataset:
During the simulation of the Timed Petri Net, the activation instants of each register in the circuit are stored in a text file. Then, a Matlab function reads this file and produces the current curve. At each activation a current peak is associated due to the parameters obtained during the static timing analysis and the high level current modeling (see  Section 5). Then, the Genetic Algorithm is started and its fitness function is called upon to evaluate the current curve. This is performed for each individual and for each generation of the genetic algorithm in order to find an individual with a spectrum fitting the spectral mask specified by the designer. Once a solution is found with the co-simulation, the delays are generated by concatenating several elementary delays, and finally, then inserted in the circuit.
To construct the model, the designer extracts from its RTL description, or alternatively from a netlist, the communication channels corresponding to bundled-data stored in registers. The channels are modeled by a transition in our Timed Petri Net, while the combinational part or the delays in the controller are represented by a place (see Figure  4 ). Notice that not only the direct path (request) is depicted but also the feedback path with a dashed arrow (acknowledgement). This will be later useful for interpreting the protocol impact on the circuit behavior when the Timed Petri Net model will be enriched in its SystemVerilog description. The approach can be generalized by considering communication channels, like joins, forks, splits, and merges when the pipeline structure is no longer linear  [23].
An example of our Timed Petri Net model is given in Figure  6. To summarize, the circles represent the timed places. The bars represent the transitions allowing the synchronization between two places. Finally, the arcs represent the bundled-data channels, with the request signal (solid arc) and the acknowledgment signal (dashed arc). The connections between the places and the arcs are made with SystemVerilog interfaces. The timings stored within the places are coming from a standard delay file (. sdf), which contains all the delays of the control path. A transition fires if the three following conditions are met:.
Nevertheless, it is also possible to simply model the current peak using a triangle. The time constants of the current peaks are determined for each stage using the extracted delay of the circuit during the timing analysis. The rise time of the first exponential is equal to the delay from the controller to the registers, represented by D l_path in Figures  1  and 8. This time depends on the number of registers N reg that are driven by the controller. Indeed, the length of the request signal tree between the controller and the registers depends on N reg. This number also determines the height of the peak. The maximum of the consumption occurs when all of the stage sample data are registered. The consumption for the memorization of one register is determined thanks to the datasheet of the library or with a spice simulation.
Simulation Results An Advanced Encryption Standard (AES) has been designed in micropipeline style with the proposed flow in order to shape its electromagnetic spectrum. Figure  11  shows the Timed Petri Net model of the AES. For the sake of clarity, the acknowledgment arcs are not represented. The bars represent the controllers, here with a 4-phase protocol. The arcs represent the request signals. The circles represent the delays. In the AES model, a merge and a split structure have been used for the data selection and a join for the synchronization with the counter. The first step of our flow is to design the circuit at RTL level. Here, the micropipeline AES is designed in VHDL and the data path is synthesized with standard EDA tools. Next, a static timing analysis is performed to extract the minimal values of the delays and the parameters required for modeling the current pulses.
Then these parameters are used in Matlab to initialize the genetic algorithm. In parallel, the behavior of each controller block is described in SystemVerilog. The controllers are connected together in order to create the Timed Petri Net like in Figure  11. The co-simulation between the genetic algorithm and the Timed Petri Net is performed to find a solution fitting with the spectral requirements. Once the spectrum of an individual is under the spectral mask, the number of buffers needed for each stage is deduced from the solution. Finally, the micropipeline AES is implemented by associating the synthesized data path, the controllers, and the delays. For clarity, in Figure  12  (too many peaks for the full AES), the evaluation, thanks to our fast simulator based on our high-level current model, is performed only using the second stage of the AES.
The heights, the path delays, and the rise and fall times of the peaks are determined thanks to the data used and produced by the static timing analysis tools. The genetic algorithm reevaluates the current curve corresponding to a set of delays at each new generation until a solution fitting within the spectral mask is found. A co-simulation backbone is used between the Timed Petri Net described in SystemVerilog, the Matlab current simulation, and the genetic algorithm. This way, the genetic algorithm exchanges the delays with the Timed Petri Net model, and the latter sends it back to the activation instants required for modeling the circuit current. Once a solution is found, the circuit can be implemented by adding the generated controllers to the synthesized data path with the right delay values.
This paper describes the principles and implementation results of reinforcement learning algorithms on IoT devices for radio collision mitigation in ISM unlicensed bands. Learning is here used to improve both the IoT network capability to support a larger number of objects as well as the autonomy of IoT devices. We first illustrate the efficiency of the proposed approach in a proof-of-concept based on USRP software radio platforms operating on real radio signals. It shows how collisions with other RF signals present in the ISM band are diminished for a given IoT device. Then we describe the first implementation of learning algorithms on LoRa devices operating in a real LoRaWAN network, that we named IoTligent. The proposed solution adds neither processing overhead so that it can be ran in the IoT devices, nor network overhead so that no change is required to LoRaWAN.
A. PoC setup This PoC is based on 4 USRP platforms from Ettus Research and NI 1. The development has been done using the GNU Radio 2 software, and the source code of the PoC can be found on-line 3  in order to reproduce our results. We have not implemented a real IoT standard in this PoC, in order to show that it can be applicable for any IoT standard. However, we took some characteristics rather corresponding to the LoRa context (not ultra-narrow band, reduced number of channels, frame duration around a few hundreds of milliseconds, etc. ). One USRP platform is a traffic generator which emulates as much (random) IoT traffic as we want, to be able to tune each channel's load independently, on demand. We typically choose channel loads from 0% to 20%, which is the scale supported in theory by a pure ALOHA channel access scheme.
A. LoRaWAN architecture The implementation of the learning algorithm we propose is decentralized, it takes place only on the LoRa device side. As stated earlier, no aspect of the LoRaWAN network is impacted. We explain below a little bit more the LoRaWAN network side configuration  [1]   [19]. A LoRaWAN network, as any other IoT network, can be summarized by four main elements, as shown in Fig. 5:   LoRa devices (our devices run the UCB algorithm here),  LoRa gateway(s) receiving all LoRa radio signals in their radio range,  A Lora Network Server (LNS) that discriminates devices subscribing to its network from others,  An Application Server (AS) that receives the data sent by devices and sends back ACK to them (mandatory here). The IoT devices are associated to a given LoRaWAN network with a "join phase", at their very first communication through a gateway of this network.
The appairment is done at the LoRa Network Server (LNS) side as explained below. Finally, data extracted from radio signals, sent by the IoT devices, are sent to the Application Server (AS) that manages data (i. e. processes them, sends them to a storing place in the cloud and/or an application). Then the role of the AS is to initiate a sending of an ACK to the IoT device, through LNS and a gateway, down to the IoT device.
B. Device side As an IoT device, we use, as shown on Fig. 6 , a Pycom card [17] composed of an Expansion Board and a LoPy module which can support LoRa wireless connectivity. The Pycom card is programmed in the Python language. The frequency channels used in the experiments are those authorized in the country of experimentation, i. e. , France. Three channels are usually used in Europe for uplink (UL) with a duty cycle of 1%: 868. 1 MHz, 868. 3 MHz, 868. 5 MHz. Our proposal IoTligent is completely agnostic to the number of channels in the standard, so it can be used in any country. Note that some amendment had to be done to the Pycom firmware in order to enable programming channel assignement in the Python program, in LORAWAN mode.
C. Network side We have access to the LNS provided by the Acklio Company. Acklio has several gateways in the city of Rennes, where the experiments were made. LNS sends the received messages to an AS which is a Linux server, running in the cloud. AS is running a Python program that enables to display data and metadata (i. e. , frequency, time of reception, etc). This programs also contains instructions to send an acknowledgment to the device, using in DL the same frequency used by the IoT device at UL. The transmit channel frequency is then chosen in a set of N channels which is set here at N = 3. We use standard Europe UL channels with the following frequency table (in MHz): IoTligent device infinite while loop is started, running the algorithm presented in the next section and  [2] , in order to choose which frequency to be selected at each iteration before executing a send operation.
C. Network side -Application Server The AS runs a Python program that receives data from the LNS, as well as LoRa metadata with all parameters of LoRaWAN transmission (frequency, SF, BW, time of arrival, etc). This program also sends an acknowledgment message to the device in DL. First, an acknowledgment attempt is sent by default at the same frequency than the message transmitted by device it answers to. Then we block any other retransmission. This is exactly what is necessary for the learning of IoTligent:  to use the same channel in both UL and DL,  to avoid retransmission in order to save batteries of devices on the one hand, and radio frequency overload on the other hand.
VI. LEARNING ALGORITHM IN PYCOM DEVICE The learning algorithms used in IoTligent are (any) bandit algorithms, such as those first used for Cognitive Radio dynamic spectrum access in  [2] , and implemented in the SMPyBandits Python library  [18]. We take here the example of UCB1 algorithm, as presented above  [5]. We have chosen these algorithms for their ease of implementation. The only data necessary to be stored for UCB1 algorithm are:  an iteration index initialized at 0: itindex,  a table of size N (the number of channels, 3 in this implementation example, but it could be arbitrarily high) for the number of times each channel has been chosen, representing Nk of (2): From the learning algorithm point of view, a success occurs when an IoT device receives an ACK from the IoT network (as explained above), which means that the currently used frequency channel suffered no collision both in UL and DL.
Progress in genome sequencing and bioinformatics opens up new possibilities, including that of correlating genome annotations with functional information such as metabolic pathways. Thanks to the development of functional annotation databases, scientists are able to link genome annotations with functional annotations. We present MetAboliC pAthways DAtabase for Microbial taxonomic groups (MACADAM) here, a user-friendly database that makes it possible to find presence/absence/completeness statistics for metabolic pathways at a given microbial taxonomic position. For each prokaryotic 'Ref-Seq complete genome', MACADAM builds a pathway genome database (PGDB) using Pathway Tools software based on MetaCyc data that includes metabolic pathways as well as associated metabolites, reactions and enzymes.
To ensure the highest quality of the genome functional annotation data, MACADAM also contains MicroCyc, a manually curated collection of PGDBs; Functional Annotation of Prokaryotic Taxa (FAPROTAX), a manually curated functional annotation database; and the IJSEM phenotypic database. The MACADAM database contains 13 509 PGDBs (13 195 bacterial and 314 archaeal), 1260 unique metabolic pathways, completed with 82 functional annotations from FAPROTAX and 16 from the IJSEM phenotypic database. MACADAM contains a total of 7921 metabolites, 592 enzymatic reactions, 2134 EC numbers and 7440 enzymes. MACADAM can be queried at any rank of the NCBI taxonomy (from phyla to species). It provides the possibility to explore functional information completed with metabolites, enzymes, enzymatic reactions and EC numbers.
Introduction For many years, Bergey's Manual of Determinative Bacteriology  (1)  and its successor, Bergey's Manual of Systematic Bacteriology  (2) (3) (4) (5) (6) , which provides descriptions of the taxonomy, systematics, ecology, physiology and other biological properties of all described prokaryotic taxa, has been the best consensus for an official prokaryotic classification and the best source of information for prokaryotic organisms and taxa. Thanks to advances in genome sequencing and bioinformatics, it is now possible to link genome annotations and functional information. To make this possible, databases have been built and contain metabolic pathways, e. g. series of chemical reactions catalyzed by enzymes within a cell. For instance, the KEGG database  (7)  can display any of these pathways in a graphical environment.
The Human Metabolome DataBase (HMDB)  (8)  and Reactome  (9)  are highly curated and complete databases specializing in human metabolism. WikiPathways  (10)  is an open access collaborative platform containing metabolic pathways across different species. PATRIC  (11)  is a bacterial database containing >201 000 prokaryotic genomes, each associated with functional information. BioCyc  (12)  links the genome sequence of an organism to its functional annotation in >14 560 eukaryotic, bacteria and archaea species. All these databases are referred to as pathway genome databases (PGDBs); i. e. they associate the genome sequences with metabolic pathways. Currently, among available databases, some databases are highly curated, including the EcoCyc  (13) , BsubCyc  (14)  and HumanCyc  (15)  databases devoted to Escherichia coli K-12, Bacillus subtilis or human metabolic pathways, respectively.
They are based on the MetaCyc  (16)  database, which is a highly curated database containing >2666 metabolic pathways throughout the living world. The MicroCyc database  (17) , based on the MetaCyc database, has been improved by automatic and manual curation by specialized biologists. Finally, some other databases are also curated using functional information from the literature, e. g. FAPROTAX  (18)  or the IJSEM phenotypic database  (19, 20). Each of these latter databases has limits to link microbial taxonomy to functional information and is not easily down-loadable. HMDB, Reactome and WikiPathways are manually and highly curated, but, despite the high quality of their functional information, they cover a small number of organisms [1, 1 and 31 (3 of which are microbes), respectively]. KEGG, despite having >5299 prokaryotic organisms, has moved to a subscription mode and cannot be accessed offline.
PATRIC depends on the KEGG pathway data and cannot be downloaded (Table  1 ). The BioCyc database is a microbial genome web portal that combines thousands of genomes with pathway information, but the BioCyc website uses a subscription model, free access to the derived BioCyc database is limited to a 2-year-old collection of PGDBs and online consultation is limited to a specific number of times per month. Further access requires a paid subscription. MetaCyc contains a greater number of metabolic pathways than KEGG (21) (2666 vs. 530 metabolic pathways, respectively), and it is freely available for academics, but only a few metabolic pathways are retrievable via a taxonomy or an organism name. With existing databases, it is difficult to request up-to-date functional annotations and up-to-date taxonomic lineages for a taxon (e.
g. a whole family). But one MACADAM feature is not provided by these databases: the possibility to infer functional information for prokaryotic taxa with no functional information associated with it. That is why we built MACADAM (MetAboliC pAthways DAtabase for Microbial taxonomic groups), a user-friendly database that makes it possible to find presence/absence/completeness statistics for metabolic pathways at a given archaeal and bacterial taxonomic rank or organism and to be able to infer functional information using the taxonomy for taxa without functional information. MACADAM is not intended to replace existing databases but provides additional information for scientists wishing to better characterize the functional information of all taxonomic groups, from phyla to species.
Building PGDBs between RefSeq and MetaCyc To build the MACADAM database (Figure  1 ), we first sourced genomic data of prokaryotes from NCBI RefSeq  (25) , version 92 (16 January 2019). To ensure high-quality genomic data, we only kept the 11 794 organisms (11 514 bacteria and 280 archaea) with 'complete genome' RefSeq labels (Table  2 ). These genomes have no gaps, no runs of 10 or more ambiguous bases and the entire chromosome is present  (26). This quality allows better annotations using the NCBI prokaryotic genome annotation pipeline  (27). Out of the 11 794 genomes, 1683 were labeled 'representative genomes' (1543 bacteria and 140 archaea), i. e. a subset of genomes with an additional quality assurance analysis based on annotation quality metrics. In addition, 118 bacteria are labeled 'reference genome' (no archaea).
They correspond to the highest quality data set, supported by the curation of NCBI scientific staff, and are manually curated. To associate metabolic pathway information with these genomes, we used Pathway Tools software (28) (version 20. 5) that relies on MetaCyc data. We thus build a PGDB per organism, i. e. 11 794, that consists of a list of pathways based on the genome annotation. Moreover, to complete pathway information, MACADAM includes the metabolites, reactions, EC numbers, enzymes and hierarchical classification of each pathway. The result is a set of PGDBs and an up-to-date functional annotation of multiple organisms.
Embedding PGDBs from MicroCyc In the second step of MACADAM building, we added data from MicroCyc  (17). MicroCyc is a collection of PGDBs created within the framework of the MicroScope project  (29)  based on MetaCyc data. These PGDBs are generated from genomes that are (i) manually (re)annoted, (ii) improved thanks to the addition of enzymatic function predictions that are computed with PRIAM software  (30)  and (iii) completed by annotations from biologist curations using the MaGe system  (31). Using the standardized pathway score (PS; Figure  2 ) proposed in Pathway Tools 16. 5, we compare MetaCyc and MicroCyc PGDBs for each organism that is present in both databases. As expected, due to the curation process, MicroCyc PGDBs exhibit more metabolic pathways with a PS equal to 1 than Meta-Cyc PGDBs (Figure  3 ).
Embedding functional annotations from the FAPROTAX and IJSEM phenotypic database In the third step of MACADAM construction, we added functional traits extracted from the FAPROTAX database  (18)  and the IJSEM phenotypic database  (19). FAPROTAX contains soil and marine bacteria. FAPROTAX maps prokaryotic clades (e. g. genera or species) to establish metabolic or other ecologically relevant functions using the current literature on cultured strains, e. g. Bergey's Manual of Systematic Bacteriology (2-6), the Prokaryotes (32) and the IJSEM journal  (33). The IJSEM phenotypic database contains phenotypic, metabolic and environmental tolerance data of prokaryotic strains manually extracted from articles in the IJSEM journal. We completed MACADAM with 82 functional annotations from FAPROTAX and 16 from the IJSEM phenotypic database (Table  3 ).
Taxonomy in MACADAM To link this information, we connected data from PGDBs, the FAPROTAX and the IJSEM phenotypic database with their NCBI taxonomy ID (taxID). This taxID is a unique time-stable identifier because of its interoperability with other taxonomic databases  (34). Briefly, in MACADAM, each organism taxonomy has seven taxonomic ranks: superkingdom, phylum, class, order, family, genus and species. Each rank and organism is described by its NCBI taxID. Each MACADAM organism is therefore associated with its numeric lineage formed by seven taxID. For example, E. coli is described as Bacteria, Proteobacteria, Gammaproteobacteria, Enterobacterales, Enterobacteriaceae, and Escherichia. E. coli is linked to this lineage 2. 1224. 1236. 91347. 543. 561. 562 in MACADAM. However, even if MACADAM data are not associated with minor ranks, e.
g. subclasses or subgenera, these minor ranks are kept in MACADAM so that users can find functional information at these minor ranks. In conclusion, to create MACADAM, we need (i) Ref-Seq 'complete genomes', (ii) Pathway Tools with MetaCyc, (iii) MicroCyc PGDBs, (iv) NCBI taxonomy files, (v) the FAPROTAX file and (vi) the IJSEM phenotypic database file.
Structure of the MACADAM database The MACADAM database is a SQLite database (35) that optimizes and facilitates querying. SQLite is an objectrelational database management system. It increases the query speed of databases. MACADAM is organized into 12 tables (Figure  4 ). As shown in Figure  4 , the taxonomy table contains all of the prokaryotic taxonomic names of NCBI taxonomy, whether a PGDB exists or not. Indeed, each PGDB is associated with an organism, i. e. with a species or a strain taxID and PGDBs do not exist at upper taxonomic ranks as genus, family and others. However, to provide users with functional information at these upper ranks, MACADAM needs to store all prokaryotic taxonomies. Thus, the corresponding table in MACADAM contains the taxID of each taxonomic name, the taxID of its parent (parentTaxID) and its taxonomic rank name (taxonomi-cRank), if any, and the numeric lineage up to this taxID, e.
g. taxonomic name = Proteobacteria-taxID = 1224, par-entTaxID = 2, taxonomicRank = phylum-lineage = 2. 1224. An important table is the pathway table (Figure  4 ). This table is composed of nine keys. The first one is the taxonomy key that is the numeric lineage. The second one is the ID key that is a unique identifier associated with each PGDB. It consists of the taxID of the corresponding organism, the RefSeq genome label ('rep' for representative genomes, 'ref' for reference genome or 'nan' for complete genomes) and its database of origin (MetaCyc or Micro-Cyc). The third key is the strainName of a true strain name if it exists. Otherwise, it is provided with the species name. The fourth key is the numberOfPGDBInSpecies. For example, MACADAM has 667 PGDBs linked to E. coli species. This means that these 667 PGDBs are linked to 667 strains of E.