dataesr/scientific-paragraphs-categorization huggingface dataset:
A. SIMULATION SETUP The computational simulations were run in an Intel Xeon 3. 1 GHz computer with 16 GB RAM and 1TB, running a Ubuntu 15. 10 64-bit operating system. The algorithms were implemented in Java programming language using the jMetal Framework  [59]. We noticed that it was necessary to develop a script in Bash to communicate the Java code with the network simulation platform. The simulation platform was network simulator 2 (NS2)  [60]  version 2. 35. The NS2 is a robust and well-known tool that implements several routing protocols, including AODV. Using this platform, we implemented the modifications on the AODV to include the new parameters for route recovery decisions (SW1, SW2, LW1, and LW2), modifying the structure of the packets and the route repair mechanism. Also, using the NS2, we modeled a network with 50 nodes with a maximum speed of 20 m/s.
B. PERFORMANCE METRICS The performance of the routing protocols was assessed using the following metrics: 1) Normalised route delay (RD or Delay): is defined as the average time it takes for data packets to arrive at the destination node divided by the number of active connections in the network. The Delay is calculated using Equation  14. Delay = DP i=1 ArriveTime -SendTime N i=1 NumberOfConnections , (14) where ArriveTime, and SendTime are, respectively, the time when the packet arrived in the destination node, and the time when the packed left the source node, NumberOfConnections is the number of active connections in the network, N is the number of nodes, and DP is the number of data packets received. 2) Packet loss ratio (PLR): measures the fraction of the data packets that were not delivered to the destination as presented and can be calculated by applying Equation  15.
C. RESULTS We found that NSGA-II, SMPSO, and SPEA2 presented a similar Pareto front while minimising energy consumption and normalised route load. Figure  8  A depicts the Pareto front achieved by the three metaheuristics. It is possible to observe that all algorithms found few solutions: four solutions found by NSGA-II and three obtained by SMPSO and SPEA2. Although the NSGA-II was able to get some superior answers regarding the SMPSO and SPEA2, the Pareto front of these two algorithms dominates the one found by NSGA-II. Concerning the absolute variation of the metrics values, the PLR values variation is higher than the EC variation. This variation may occur because reducing the energy consumption is more complex than reducing the packet loss ratio. Given that the NRL measures the balance between the packets and data packets sent during the simulation and that the number of transmitted data packets is fixed, only the amount of routing packets can be reduced to minimise the NLR.
As mentioned, our approach optimises the route recovery of the AODV to suit the characteristics of the environment best. In this case, the simulated scenario must capture the main features of the actual conditions to ensure an optimal performance. Hence, better modelling can positively affect the implementation of the proposed solution. Another drawback is related to the simulation process, which can be done offline on a computer with more robust hardware but requires hours to reach the optimal value. Because the simulation setup involves different programs (e. g. , Python scripts, Java implementation of the multi-objective algorithms, and NS2 simulator), the interconnectivity between these components and the information exchange can be timeconsuming. Multi-objective optimisation is a more complex process than the mono-objective one, but the improvements achieved in one of the metrics can be slightly inferior compared to the mono-objective.
Contributions of this paper On the basis of the knowledge gaps identified previously, this article presents the following contributions. 1. Problem resolution: We present two different population-based MOEAs (SH-NSGA-II and MA), which are Pareto-based techniques, to address the computational hardness issue of the exact method for the large-scale spatial zoning optimization problem in MSP. Initialization, stop condition, chromosome encoding, crossover, mutation, check and repair operators, constraint management methodologies, and algorithm structure in raster data are all suggested as innovations. The proposed MOEAs are used to simultaneously optimize the interestingness and compactness objectives of the new activity's zone.
Crossover Operators Two proposed MOEAs utilize four crossovers, namely Crossover-1 (2. 3. 2. 1), Crossover-2 (2. 3. 2. 2), Crossover-3 (2. 3. 2. 3), and Crossover-4 (2. 3. 2. 4), which are explained in details in this section. They are applied to three separate sections of the chromosome, to thoroughly investigate the search space of the problem. We must choose two parents as inputs for this operator for each crossover. As a result, binary tournament selection is chosen as a selection method to pick two selective parents  [10]. The chromosomes of both parents are then encoded and sorted according to x-coordinate/y-coordinate. Having selected a random crossover i as mentioned on line 8 of the pseudo-code 1, the parent populations go through the tournament selection and two of them are selected.
There are k = 4 factors for SH-NSGA-II and k = 6 factors for MA, each with three levels, i. e. low, medium, and high, and each signed by -1, 0, and +1, respectively. The data generation parameters of the spatial zoning optimization problem are summarized in Table  1. We vary these problem-specific parameters in three different levels (low, medium, and high) for three different map sizes (55 × 55, 300 × 300, 1000 × 1000) as shown in Table  1. The total number of artificial datasets for each map size that have been generated are 3 4 = 81. Among 81 datasets, 8 of them are randomly selected to be used in all evaluations for each map size. Moreover, the anonymous link where anyone with the link can view all coded algorithms along with all used data is provided in the repository  [3]. Using the data in Table  1 , the coded MOEAs were executed based on the BBD for four factors in three levels with a center point for SH-NSGA-II and six factors in three levels with a center point for MA, shown in Table  2.
1. 2, respectively. All experimental tests are done on an OpenStack virtual machine running Linux/Ubuntu 20. 04. 1 LTS with 20 VCPU, 10 GB disk, and 30 GB RAM. Then, the response function is estimated and optimized using MRSM. Furthermore, for each MOEA in each size, the design should fit the second-order regression model (a quadratic model), that is, the one containing squared terms, product of two factors, linear terms, and an intercept. To find the subset of variables in the dataset resulting in the best performing model, that is, a model that lowers prediction error, the feature selection technique is applied to iteratively add and remove predictors in the predictive model. In this article, we employed a feature selection strategy for all regression models that combined stepwise regression and cross-validation to produce the highest performing model.
Experimental Validation Once the parameters have been tuned, the goal is to compare the performances of SH-NSGA-II vs. MA. To evaluate both methods, 8 different randomly selected datasets are used, as presented in table  1. Then, to evaluate a much more robust comparison, each instance is implemented 30 times and each reported value is the median of 30 runs of each problem with its respective method. Before presenting the results, the selected performance metrics are presented in the subsection 4. 1.
Conversely, the CVP-1 "public"  [31]  and "secret"  [32]  Aarch64 traces generated at Qualcomm are of large interest to the research community as i) They are numerous (135 and 2013 traces respectively) ii) They cover a wide range of workloads of interest to industry: Compute INT/FP, cryptography and datacenter/server iii) They embed output register values, allowing studies that rely on actual program values and iv) They include system activity, which is typically not the case for traces obtained with Pin  [33]. Unfortunately, those traces are anonymized, meaning that the actual workload is not known, and some information has been removed from the traces (e. g. , Execution Level and Address Space IDentifier, instruction bytes, exact opcode, addressing mode, etc. ). Given those two observations, being able to run CVP-1 traces in ChampSim would provide the research community with a large amount of good traces running on an easy to use infrastructure.
This hinders memory level parallelism as any instruction depending on the base register may, in the worst case, have to wait for a DRAM access to compute its address. This limitation was made known to the ChampSim community in January 2021, 1 but is currently not addressed in the existing cvp2champsim converter. 1. https://github. com/ChampSim/ChampSim/issues/112 In that spirit, this paper revisits the CVP-1 traces and performs a thorough analysis allowing a better conversion of the CVP-1 traces to the ChampSim format. During this analysis, we discovered some design decisions in the initial conversion to the IPC-1 format affecting performance and even the final outcome of the IPC-1. One example is that a very high misprediction rate was observed for return instructions in 10 IPC-1 workloads out of 50, despite ChampSim implementing a Return Address Stack (RAS)  [35].
Design Decisions in the Original cvp2champsim The original cvp2champsim converter program was written out of a requirement of being able to model workloads with interesting front-end behavior in ChampSim. The intent was to study instruction cache and branch predictor optimizations, for which the Aarch64 to x86 conversion is comparatively straightforward. Some of the CVP-1 workloads had been identified as having very large instruction working sets, the kind of which were as yet unavailable in other open benchmarks. The original emphasis of the converter was therefore to generate ChampSim traces that captured this particular front-end behavior. Specifically, ChampSim deduces branch type using x86specific registers, while CVP-1 encodes Aarch64 instructions, so great care was taken to make converted instructions appear to follow the x86 semantics for branches, as we will detail in the next Section.
To determine if the instruction is a load or a store, ChampSim looks, respectively, at the memory sources and destinations. Instructions that are not branches, loads, or stores are considered arithmetic instructions. Furthermore, the trace format does not encode the branch type. ChampSim resolves the type of the branch based on the registers from which the branch instructions read from or write to. For example, if an x86 instruction reads and writes both the stack pointer and instruction pointer, but does not read other registers, it must be a direct call instruction. Next, we discuss different issues we have identified in the original cvp2champsim converter and describe the improvements we propose to make the ChampSim traces converted from the CVP-1 traces more accurate. Table  1  summarizes these improvements.
Branch Instructions ChampSim models a relatively detailed processor frontend, including a branch target buffer (BTB). Modern BTBs usually store the branch type in the main BTB table and implement separate structures to predict the targets of indirect branches and returns more accurately. ChampSim differentiates among different types of branches even though the ChampSim traces do not encode the branch type directly. ChampSim resolves the type of branches based on the registers from which the branch instructions read from or write to. For example, a conditional branch reads from and writes to the instruction pointer register, reads the flag register, and does not read nor write the stack pointer register. The CVP-1 traces only distinguish between three different types of branches (conditional, unconditional direct, and unconditional indirect), ChampSim differentiates among six types.
Evaluation and expected results After the traces are converted, the ChampSim simulations should be launched. As done for the conversion, we provide scripts to launch them sequentially and in parallel using Slurm: $ run-champsim-seq. sh ChampSim_binary improvement suite  [benchmark]  $ run-champsim-paral. py ChampSim_binary improvement suite For example, we can run all CVP-1 public traces with all trace conversion improvements using the main version of ChampSim with: $ run-champsim-paral. py ChampSim/bin/champsim All_imps CVP1public Unlike trace conversion, ChampSim executions are quick (a few minutes each) and do not have any disk space requirement. We also provide the script run_ALL_champsim_paral. sh, which takes no input parameter, to launch all the ChampSim executions needed to reproduce the results of the paper.
Finally, we provide a set of scripts to obtain all the results reproduced in the paper: results_fig1. sh, results_fig2. sh, results_fig3. sh, results_fig4. sh, results_fig5. sh, results_tab1. sh, and results_tab2. sh. The scripts assume that all required ChampSim executions are already completed. The scripts take no input parameter and give as output the data plotted in the corresponding figures.
Acknowledgments This project has received funding from the  European Research Council (ERC)  under the  European Union 's  Horizon 2020 research and innovation programme  (grant agreement No  819134 ), from the  MCIN/AEI/10. 13039/501100011033/  and the " ERDF A way of making Europe" ,  EU  (grants  PID2021-123627OB-C51  and  PID2022-136315OB-I00 ) and the  European Union NextGenerationEU/PRTR  (grants  RYC2021-030862-I  and  TED2021-130233B-C33/C32 ), from the  National Science Foundation  (grants  CNS-1938064  and  CCF-1912617 ), as well as generous gifts from  Intel. Portions of this research were conducted with the advanced computing resources provided by  Texas A&M High Performance Research Computing.
The attention on blockchain technology (BCT) to create new forms of relational reliance has seen an explosion of new applications and initiatives, to assure decentralized security and trust. Its potential as a game-changing technology relates to how data gets distributed and replicated over several organizations and countries. This paper provides an introduction to BCT, as well as a review of its technological aspects. A concrete application of outsource access control and pricing procedures in cellular networks, based on a decentralized access control-as-a-service solution for private cellular networks, is also presented. The application can be used by service and content providers, to provide new business models. The proposed method removes the single point of failure from conventional centralized access control systems, increasing scalability while decreasing operational complexity, regarding access control and pricing procedures.
Introduction Blockchain technology (BCT), as the foundational design of distributed ledger technology (DLT), has revolutionized many aspects of business models and operations. Based on the traditional idea of hash chains to assure the integrity of data over distributed computing scenarios, BCT is believed to bring innovative new solutions, due to its key characteristics, such as decentralization, transparency, and immutability. Decentralization relies on the distribution of nodes over a global network, whose records are stored in registers (e. g. , blocks) containing every transaction initiated in the system. All transactions are verified by multiple entities and securely recorded several times, through the use of encryption keys and electronic signatures. Records cannot be reversed, modified, or repudiated, thus creating an irrevocable and verifiable history of transactions.
Registry management is decentralized and operates without a control body or centralized storage. The use of BCT has received increasing attention, with Bitcoin  [1]  being the most famous application in the realm of cryptocurrencies, as well as Ethereum  [2]  and the extension of the concept of smart contracts  [3] , to autonomously execute agreements reached between distributed nodes. Together, these methods offer new possibilities to validate data transactions while offering traceability in a wide range of complex scenarios, far beyond the original usage of cryptocurrencies  [4]. Examples include copyright management, sharing healthcare information, supply data, and real state control  [5] [6] [7]. The intrinsic advantages of BCT are expected to change many aspects of business models, management, and operations in a range of fields.
Blockchain and Distributed Ledger Technologies Blockchain technology's (BCT) proposal dates from 2009  [1] , and it is tied to the Bitcoin cryptocurrency, where a practical implementation of the traditional concept of hash chains to ensure data integrity was revisited. A hash chain is the successive application of a cryptographic hash function to continuous flows of data transactions. In BCT, the authenticity of such transactions is also assured by digitally signing them by a sender, before broadcasting the result to a peer-to-peer network  [11]. Special BCT users in that peer-to-peer network, known as miners. The term miner is commonly used in consensus models derived from the Bitcoin cryptocurrency. For the other consensus models, terminologies such as block validator or leader can replace the term miner).
) the new block is also added to their local replicas of the ledger. Indeed, two main concerns in this simple example (as well as other Blockchain-based distributed systems) are the lack of centralized authority to manage the synchronization of the transactions, as well as their ordering, and the integrity of data. Addressing the challenges of data transaction ordering, synchronization, and integrity of data in BCT is done by the difficulty of rolling back in the chain of blocks. This provides strong immutability in BCT that makes the partial chain rendering unfeasible. In other words, by hashing the preceding block and inserting this amount as a header in the current block, any simple modification of a transaction included in previous blocks would require solving a consensus problem for all of the subsequent blocks.
This assures the integrity-by-design feature. Additional properties associated with BCT systems include traceability, transparency, non-repudiation and permanence. Traceability and transparency mean that all data transactions are available to be seen and tracked by any nodes with access to the system. In other words, data must always be available and traceable at any time. Non-repudiation in BCT means that nobody can deny their actions in the system. The use of cryptography in BCT ensures that all parties must digitally sign their actions, hence avoiding the possibility of action denial by BCT entities. Finally, permanence means that all data in a BCT can be available at any time (nothing may be removed from the network). In terms of data structures associated with BCT, blocks are composed of a body and a header (cf.
Any modification affecting a transaction (i. e. , even a bit-flip) will render to a different Merkle root; hence verification and comparisons can be conducted by simply looking at the Merkle root of the block, without the need to go through all the transactions stored in a block. The more general concept of distributed ledger technology (DLT) includes aforementioned designs around the concept of blocks and Merkle trees, as well as alternative designs, including different data structures, consensus algorithms, and governance solutions. Blocks can be replaced by other non-linear data families, including with the use of directed acyclic graph (DAG) or any other hybrid data structures. Different designs can be classified depending on the rule that regulates as to which nodes can access, verify and validate the transactions in the system  [12].
Although these organizations might not fully trust each other, they can work together by altering the consensus algorithm, based on the level of trust among them. Consortium platforms can also be used as a distributed and reliable database for predefined enterprises for business-to-business purposes. However, only the eligible nodes, defined by participating organizations, can join in the consensus process. The anonymity of users can be violated. Moreover, the use of tokens or fees is not mandatory for the process or for validation of transactions. For the sake of simplicity, we assumed in previous explanations that to reach transaction validation, it suffices to validate the correctness of digital signatures associated with the transactions, as well as asset ownership and double spending avoidance.
Access Control Models Access control regulates who or what (i. e. , a subject) can perform which action (or have which permissions) upon an object (e. g. , network resource, applications, services, databases, etc. )  [16]. The access control procedure is done in three main steps. We must first define a series of rules associated with a policy, determining the conditions for accessing an object. Each rule definition is varied based on the access control model. Secondly, access verification is conducted, in which the access control server examines the received access request based on a subject's permissions. If they match, an access solution based on the enforcement method will be assigned to the subject. The recording of access logs completes the third step, in which all activities of the subjects and their accesses will be recorded.
OAI is an open-source platform to provide services for the software-based implementation of different cellular network infrastructures, such as user equipment, radio access networks, and core networks  [27]. OAI complies with standards from the 3GPP partnership program. It supports 4G LTE and 5G broadband cellular network implementations. Along with the software version, OAI provides features to integrate commercially available hardware, such as smartphones, programmable SIM cards, and universal software radios, for transceiver functionality. On the other hand, the Magma core is an open-source implementation of the cellular core that supports 4G LTE and 5G radio access technologies. It consists of three major components: the Access Gateway, the Orchestrator, and the Federation Gateway. The Access Gateway (AGW) represents the core network services and policies.
System Design In this section, we provide a brief description of the smart contract models, which handle the registration, access control, and payment procedures in the system. In this regard, we categorized the smart contracts into the following groups: (i) reference contracts; (ii) database contracts; (iii) policy definition contracts; (iv) manager contracts. Figure  3  depicts the connection between contracts and contract attributes, and their definitions. is a with the following variables: • 𝐶𝑜𝑑𝑒𝑆𝑃 • 𝐶𝑜𝑑𝑒𝑠𝑒𝑟𝑣𝑖𝑐𝑒 • 𝐸𝑥𝑝𝑖𝑟𝑎𝑡𝑖𝑜𝑛 𝑡𝑖𝑚𝑒 • 𝐴𝑣𝑎𝑖𝑙𝑎𝑏𝑙𝑒 𝑆𝑡𝑜𝑟𝑎𝑔𝑒 • 𝑃𝑎𝑦𝑚𝑒𝑛𝑡 𝑡𝑦𝑝𝑒 Here  is a with only  as its identifier. Price of each service is defined by service provider.
Policy Definition Contracts For the first setup of the system setup, we define five rules to validate the request's access attributes. Each policy is defined in the different smart contracts, and the service providers can add the list of applicable policies to their services. The following rules are set in the first setup of the system. If any SP needs to add a policy, such an SP deploys a smart contract for that and adds its code to their service. -For the prepaid services, the user's balance needs to be checked in the registration step. -For the prepaid services, the service provider's balance needs to be checked in the access control step. -For the PAYG services, the user's balance needs to be checked in the access control step.