dataesr/scientific-paragraphs-categorization huggingface dataset:
The authors correctly point out the benefits of the SDR technology to address the dynamic context of an emergency crisis, because new communication links or different modulation schemes can be used depending on the operational conditions. The authors in  [17]  indicate the main challenges for the implementation of the platform and present the results achieved during the SALICE project. In particular, the integration of the networking architectures and the coexistence and synchronization of the different communication systems used in the project were particularly complex. These challenges are also present in the demonstration system described in this paper. The SALICE project did not use SDR technology based on SCA unlike the EULER project. Indeed, the reconfigurable SDR-based terminal able at encompassing functionalities of assisted localization and data connection restoring has been emulated by means of the GNUradio open source platform (see  [18]  for additional details and results).
System architecture The overall architecture and the applicability to disaster management scenarios of the SDR-based network is shown in Figure  1. As described in the introduction, the underlying technology used in the EULER project is SDR, which is used to support the interoperability among conventional wireless communication technologies like TETRA, WiMAX, and satellite communications. This is achieved through a high data rate (HDR) waveform (WF) called EWF, which supports an internal LOS wireless network used to link the various conventional wireless communication technologies. The system can be based on the following types of equipment: • Handheld terminals with limited processing capacity. These handheld terminals can be basic http://jwcn. eurasipjournals. com/content/2014/1/169 The PPDR organizations (e.
The data rates are in the order of several MBs, the nature of which is dependent upon scenario. For the purpose of the scenario, the application of video streaming was demonstrated, which requires at least several hundred kbps, which are much higher than data rate provided by TETRA release 1, whose data rate is in the order of several tens of kbps. Figure  4  shows the setup of the test-bed, where video streaming from a video-surveillance camera was used to validate the test-bed. Validation parameters included bit error rate (BER), jitter, and latency.
Network management services The demonstration system is equipped with network management capabilities based on Simple Network Management Protocol (SNMP). A management information base (MIB) database was defined for the network and the various test case scenarios. The network management system was evaluated on a test-bed based on the combination of the WiMaX-based scenario and a service network with application servers, communication server, and monitoring servers. The overall setup is described in Figure  10  where the service-specific MIB elements and the platform/OS-specific MIB elements are highlighted.
We have to mention that in  (Soua and Afifi, 2013) , we presented a short description of ADOPEL with a limited performance study. Here, a refined description is carried out to explain in depth the different functioning steps of ADOPEL. In fact, we reveal how our proposal reacts towards the challenging characteristics of a VANET network: Some issues such as the high mobility of nodes, the selection of next relay, the stability of the route towards the control center, etc. In addition, the performance evaluation part will be enriched with additional details that confirm the efficiency of our scheme compared to non-learning techniques. The remainder of this study is organized as follows. The next section presents the related work and outlines the different procedures undertaken to design efficient data collection protocols devoted to VANETs.
This protocol uses two types of reports: Primary and aggregated records. The first ones are broadcasted periodically by the nodes and comprise the local view of each vehicle. Then, the local view is grouped into clusters and used to compact and aggregate the local view data into an aggregated record. This aggregated record is then broadcast to neighboring vehicles to provide them information about vehicles beyond the local view. This technique allows vehicles to have an extended view of the road behind and then accurate information about upcoming traffic conditions. JCS Science Publications However, their approach introduced a large overhead to build the global view. Another effort carried out by  Dieudonne et al. (2012)  focuses on a distributed collection information for VANETs. It collects data produced by vehicles using inter-vehicle communications only.
Simulation Design We used MATLAB to conduct simulations using Freeway mobility model. The freeway mobility model emulates the motion behavior of vehicles in a freeway. In our study, we use a freeway which has two lanes in each direction. All lanes of the freeway are 20 Km in length (Fig. 3 ). To make the proposed scheme tractable, we make the following assumptions: In addition, each vehicle stores its own Q-values and the ones received from neighboring nodes (using hello messages) in a matrix to be used in the relaying process. Furthermore, we compare our scheme to a nonlearning version. For that purpose, we suppose for the non-learning schemes that at each relaying operation, a node has a 20% (respectively 40%) probability of choosing the most surrounding vehicles as a next relay and 80% (respectively 60%) to choose the node with the largest advance toward the destination node.
Compared to other techniques present in literature, such as  (Saleet et al. , 2010; Ibrahim and Weigle, 2008) , our scheme gives vehicles the possibility to auto-adapt their gathering process based on their experience in the network and hence adds the dynamicity aspect to the data collection parameters rather than fixing all of them since the beginning. Moreover, adding the instability of links in the learning process variables represents another important feature of our method that distinguishes it from previous works  (Yu et al. , 2010). To analyze the performance of our proposal, we compared it to a non-learning version to study the effect of the learning technique. We used two important metrics which are directly linked with the efficiency of our collecting approach: The collection ratio and the number of hops.
A. T. M. A. N) in Android devices. However, this implementation is conducted to test the web caching mechanism without detailed assessment toward the underlying routing protocol. [6]  presents the implementation of new approach for consistent and efficient name resolution using adaptive routing techniques in Linux-based platform using the Click Modular Router and its validation using the Network Simulator 3. The study lacks of detailed reports about the routing performance. In  [7] , an exploration of Atheros ath5k driver for wireless ad-hoc routers is shown. Although this study does not specify any routing protocol, it elaborates the technical detail in MAC layer, its source code for the driver, and its realistic scenarios. None of the above studies are specifically assess AODV protocol and its implementation in real device.
Real world implementation is important since simulation environment such as NS-2 always gives underlying configuration provided flawlessly. By conducting real world implementation, we deal with other works regarding underlying protocol, firmware and hardware configuration, as well as detailed topology both in logical and physical adjustment. We can also observe the real performance further. In this paper we present the result of analysis towards AODV-UI implementation on real devices and play their role on a real MANET. The paper elaborates the general issues that arise about MANET and AODV. Our most valuable work is porting AODV-UI into Linux based embedded system (OpenWRT) with MIPS based processor. MIPS was originally acronym for Microprocessor without Interlocked Pipeline Stages. Today, the term MIPS is generally referes to a reduced instruction set computer developed by MIPS Technologies, Inc.
B. AODV Implementation Comparison As the fundamental studies, we include some AODV implementations that are available for public. They are AODV-UU, AODV-UCSB, Kernel AODV, and AODV-UIUC. AODV-UU is an AODV implementation that is developed in Upsala University. This AODV implementation is developed to be used in Linux user-space and also have been ported on NS2 simulator environment. AODV-UU uses kernel module to communicate with Netfilter and detect the event. All routing protocol processes and logics are processed by a daemon that resides in user-space. AODV-UU improves the performance of Hello packets to support unidirectional link support and signal quality threshold for received packets. AODV-UCSB is an AODV implementation that is developed at the University of California in Santa Barbara.
It was formerly developed by directly modifying the kernel without requiring kernel module or any user-space applications. Later, this protocol uses kernel module from AODV-UU release version 0. 4. On its latest release, most of AODV-UCSB logic is implemented in user-space daemon. The improvement that has been made includes options for the number of Hello message to connect to neighbor device. It avoids device in creating routes to neighbors based on a single spurious message reception. AODV-UIUC is another user-space implementation of AODV that uses Netfilter and the additional wrapper called Ad-hoc Support Library (ASL). ASL is a user-space library which provides an API to facilitate implementation of routing protocols for wireless ad-hoc networks in Linux. Ad-hoc Support Library provides a simple API to implement on-demand or reactive ad-hoc routing protocols in Linux.
It is implemented as a userspace library. No kernel modifications are required. AODV-UIUC is developed in University of Illinois at Urbana-Champaign. This implementation completely separates routing function and forwarding function. Routing functionality is handled in the user-space daemon meanwhile packet forwarding tasks is done by the kernel. By this method, packet forwarding can be processed immediately and the packet that should traverse between kernel-space and user-space is fewer. For these three implementations, most of the protocol logics are done in user-space. All interesting packets in the kernel space are captured using Netfilter then forwarded to userspace. Netfilter is a framework that enables packet filtering, network address and other packet mangling. Netfilter is a set of hooks inside the Linux kernel that allows kernel modules to register callback functions with the network stack.
A registered callback function is then called back for every packet that traverses the respective hook within the network stack. Kernel AODV is developed at the National Institute of Standards and Technology (NIST). Kernel-AODV uses Netfilter, whereas all of the routing protocol logic is placed inside the kernel module instead of user-space daemon. This placement improves the performance of the implementation, in terms of packet handling, since no packets are required to traverse from the kernel to the userspace. This implementation also supports Internet gateway, multiple interfaces and a basic multicast protocol. By using this kernel-level implementation, very low latency is expected.
MIPS (formerly accronym for Microprocessor without Interlocked Pipeline Stages) is a 32 and 64 bit Instruction Set Architecture (ISA) developed by MIPS Technology (MIPS technology has been acquired by Imagination since 2013)  [10]. MIPS ISA commonly found in embedded system environment, especially embedded network devices such as routers, residential gateway, and wireless access point  [11]. As explained before, in this experiment AODV-UI is ported to MIPS ISA due to the fact that many wireless capable embedded network devices suitable for MANET environment are powered by this architecture. Extensive development environment for this architecture can be easily obtained both as commercial or open source solution. This architecture is also supported in the mainline Linux kernel. The GNU C Compiler (gcc) target, tool chain and binary utilities for this architecture is also exist in mature state  [11].
D. OpenWRT OpenWRT is a highly extensible GNU/Linux distribution for embedded devices  [12]. It is a free operating system designed for wireless router. This operating system is developed based on Linux and uses Linux kernel. It has wide compatibility with many embedded CPU architecture and has wide support for many wireless chipset as it is designed intentionally to handle wireless router 's tasks. By utilizing this operating system, developer can freely customize the wireless router's capability. OpenWRT has its own writable file system and package management system. It contains hundreds software packages and provides free access to the source code to include more add-on packages. The OpenWRT source code is oriented towards developers by providing a development kit called OpenWRT Software Development Kit (OpenWRT SDK), which enabled us to develop adaptation part for the AODV-UI source codes.
B. Hardware and Software Stack As previously mentioned, AODV-UI routing protocol is intended to be implemented on low-end and inexpensive wireless routers. This is done by replacing the original firmware of the wireless router with OpenWRT and adding AODV-UI capability on it. We choose OpenWRT over other firmware codebase such as DD-WRT and FreeWRT because it offers greatest stability, general Linux utilities and modular compiling system that makes it easier for development. OpenWRT Backfire 10. 03 is used for TP-Link MR3220 v1. 0 wireless router as the first platform, and OpenWRT White Russian RC4 is used for Linksys WRT54GL v1. 1 as the second platform. TP-Link MR3220 uses AP99 Atheros AR7241 400MHz MIPS Processor and Linksys WRT54GL uses Broadcom 5352 200MHz MIPS Processor. AODV-UI is built based on AODV-UU codebase which is then cross compiled to MIPS architecture.
Fig. 2  depicts current implementation stacks of AODV-UI. Most of the logic and routing algorithm codes run on userspace to minimize effect of defective code on system stability. Kernel space implementation is limited to routing table manipulation codes only. Since the current implementation is based on AODV-UU codebase, it is available on several generic Linux platforms: such as x86, AMD64, MIPS little and big endian, and ARM. Current kernel module utilize Netfilter architecture stack to manipulate the network packets in kernel space as shown in Fig. 1 , therefore kernel module compatibility list is limited to kernel 2. 6. 32 and older. Implementation on newer kernel without Netfilter is in progress. Compilation is done on Debian Squezy with OpenWRT SDK, gcc4. 4. 5 linaro, Debian's build essential and full development environment installed, including binutils, glibc, m4, bison, autoconf, and automake.
B. Implementation Comparison Test This assessment intends to compare this implementation in all used platforms and an additional general computer based system as a reference. Control packet forwarding delay is compared. This delay is measured for a RREQ packet with no entry in the routing table starting from the time it enters the device and is forwarded to next node. This test reveals the time needed by the netfilter kernel module to grab the packet content, send it to the userspace daemon, then the daemon has to seek for its destination in routing table and if not exist resend it as a new RREQ or if exist reply with RREP. This test is considered important since this protocol is intended to be used on mobile device, which might be very limited in term of processing and power durability, yet expecting high data throughput for various communications.
No routing overhead taken into account in this test. The more powerful mobile computer system we use has AMD E-350 dual core x86_64 processor, 6GBs RAM, and 320GBs storage. It runs Linux kernel 2. 4. 30 and 2. 6. 32. It uses gcc 4. 6 and gnu toolchain for helping the development of the routing protocol. The result, as shown in Table  VII , denotes that Kernel AODV consume less time since packet only cross kernel-user space boundary once. Aside from the control packet forwarding delay, we also try to observe CPU usage on both MIPS architecture and PC based x86 processor. Unfortunately we could not reliably measure the performance of the implementation in the MIPS architecture due to limited computing performance. As an example, during route formation PC based implementation has only a little more than 1% CPU usage and almost negligible.
C. Basic AODV Functionality Tests This assessment intends to observe whether the device can discover its neighbor along with its performance. We use two nodes and conduct the analysis in one of them. We use synchronized time server and adjusted them before the AODV process begins. The process is to let the AODV populate its routing table with local entry (4 neighbors). We measure the time between the routing daemon is started until all four neighbor is detected. We repeat this experiment ten times in different network condition varied by its level of background traffic. In this experiment the background traffic is generated by a custom program running on each node. The program tries to send a dummy packet to any neighboring nodes at specified rate. At 0%, no traffic is generated at all. At 100%, the program will try to generate as much packet as the wireless link can handle (pre computed before).
Motivation: Automatic error correction of high-throughput sequencing data can have a dramatic impact on the amount of usable base pairs and their quality. It has been shown that the performance of tasks such as de novo genome assembly and SNP calling can be dramatically improved after read error correction. While a large number of methods specialized for correcting substitution errors as found in Illumina data exist, few methods for the correction of indel errors, common to technologies like 454 or Ion Torrent, have been proposed. Results: We present Fiona, a new stand-alone read error-correction method. Fiona provides a new statistical approach for sequencing error detection and optimal error correction and estimates its parameters automatically. Fiona is able to correct substitution, insertion and deletion errors and can be applied to any sequencing technology.
, 2011) , whereas 454 sequencers are prone to produce runs of larger insertions of the same nucleotide. Ion Torrent sequencers were shown to have a large amount of indel errors and a high-sequencing error rate  (Quail et al. , 2012). However, current error correction methods suffer a number of limitations as highlighted in a recent review  (Yang et al. , 2013). (i) Most methods cannot correct indel errors because they are tailored to correct only substitution errors and are therefore only applicable to Illumina reads. (ii) Most approaches need to be parameterized depending on the dataset, otherwise their performance is suboptimal. This either requires in-depth knowledge by the user or parameter optimization using downstream analysis, which often leads to longer running times in practice. (iii) Because the throughput of NGS technologies is growing steadily, many approaches are not applicable to larger datasets because of running time or memory limitations.
These caveats make it hard for users to choose the optimal tool for their dataset and NGS technology. Here we introduce a new approach to read error correction, called Fiona, which addresses all the above mentioned limitations. Fiona provides an accurate and highly parallelized method for correction, with the ability to correct indel errors, while it automatically adjusts its parameters. All read error-correction methods have to perform essential tasks: (i) computation of read overlaps, (ii) error detection in reads and (iii) error correction. In a recent review by  Yang et al. (2013) , the methods have been classified into k-spectrum based, suffix tree/array based and multiple sequence alignment (MSA) based. We will briefly explain the differences and weaknesses of these approaches but refer the reader to  (Yang et al.
, 2013) : k-spectrum based. k-spectrum based read error correction was introduced in the Euler assembler  (Pevzner et al. , 2001). There exist many variations on the k-spectrum based error corrections for NGS reads  (Yang et al. , 2013) , for example, approaches that were designed to select the necessary parameters using mixture models  (Chaisson and Pevzner, 2008; Kelley et al. , 2010). Popular methods are Quake  (Kelley et al. , 2010) , Reptile  (Yang et al. , 2010)  and the error correction module from the Allpaths-LG assembler  (Gnerre et al. , 2010) , all of which use base quality values. To our knowledge, only Allpaths-LG in this category can correct short indel errors. The general disadvantage for most of these methods is their inability to correct indel errors, a severe limitation for 454 or Ion Torrent sequencers.
In both methods, potentially correcting reads are compared with erroneous reads using hamming distance, seeded by the shared ðk À 1Þ-mers between reads. Further, both methods are sensitive to the input parameters and therefore show variable performance when compared in other studies  (Ilie et al. , 2011; Kao et al. , 2011; Kelley et al. , 2010) , and the full suffix tree data structure needs large memory resources. The HiTEC algorithm introduced automatic parameter selection using coverage statistics  (Ilie et al. , 2011). Seed lengths and coverage threshold are set automatically, given the genome length and the average error rate. HiTEC uses the suffix array instead of a suffix tree to save memory. However, HiTEC can only correct substitution errors and the automatic parameter selection works only for reads of same length as found for Illumina data.
MATERIALS AND METHODS We introduce the Fiona algorithm, which combines the strength of suffix tree-based methods with a clear definition of error correction as in MSAbased methods. The algorithm uses a suffix tree to detect and correct substitution and indel errors following Shrec and HybridShrec, but with enhanced overlap detection of reads with indel errors using edit distance comparisons. In the implementation, the suffix tree traversal is emulated using solely a partial suffix array that is presorted up to a fixed depth to reduce the memory footprint. All steps feature a parallel implementation to scale with larger datasets. Instead of treating discovered errors independently, Fiona collects them and solves a new formulation for optimal error correction inspired by the MSA-based correction methods.
Further, it uses new statistical methods to improve error detection at different k values and automatically estimates its parameters for reads of varying lengths as commonly found in 454 or IonTorrent data sets. The Fiona strategy is outlined in Figure  1. Notations. Let [i, j] and (i, j) be closed and open ranges of integers. Further, let S be the DNA alphabet (S=fA; C; G; T; Ng, and N represents an unknown base) and s a string of jsj characters. The concatenation of two strings s and t is denoted by st. A substring of s from position i to j is the sequence s½i; j:=s i s i+1. s j. s R and s denote, respectively, the reverse and the reverse complement of a DNA string s. We correct errors on a set R ðjRj=mÞ of DNA strings of lengths ð' i Þ m i=1 , sampled from a genome G of length n, possibly with sequencing errors.
We selected datasets for a diverse set of organisms to explore the impact of genome complexity and repeat content on error correction performance, from short genomes (Escherichia coli, Pseudomonas syringae) to longer and more complex ones (Drosophila melanogaster, Homo sapiens). Further details about all datasets and the evaluation are given in Supplementary Section S3. The only variable parameter besides the input read set given to Fiona is the estimated genome length (Supplementary Table  S1 ). Fiona was run with default parameters for all datasets, i. e. the sequencing error rate was 5% and the presorting q-gram length was set to 10.