dataesr/scientific-paragraphs-categorization huggingface dataset:
Data availability The best practice recommendation workbooks  64  are hosted on the Zenodo platform, an open data server for public comment to ensure dynamic and timely updates and include a DOI for referencing. These workbooks are MS Excel. xlsx files that can be converted to. csv format and opened by other software. The workbooks are considered living documents as we encourage active participation in updating these best practice protocols by the tephra community at large and ask that feedback and comments be emailed directly to the lead author following which they will be vetted by the community. The spreadsheets will be versioned periodically with updated recommendations from the community. We encourage the use of the current version of the recommendations in developing field and analytical templates, data supplements for publications, databases, training guides, etc.
However, applying those same measures to an MEC paradigm would not be the most efficient way to increase throughput, as the corresponding issues mainly concern mobility and handover rather than routing. The choice made to address this issue is going to greatly affect the total delay of every operation within the architecture. From this point on, we can distinguish two main directions that were researched in order to solve the issue of delay-sensitive applications: Mobile Edge Computing and Fog Computing (FC). In a nutshell, these technologies strive to free themselves from data centers, by gathering computing and networking resources from end users, which pack some processing power within their on-board unit (OBU)  [37] , and near-user road side units (RSU)  [38]. The main takeaway from this is the distribution of resources, and the applications and services that come with them, as compared to the centralization of the cloud.
In a way, MEC is a portion of FC, in that fog computing encompasses all dynamic cloud-to-terminal communications, while edge computing focuses itself on the network edge specifically. As stated previously, both are edge-oriented which allows them to shorten data transmission paths, reaching lower latencies, while still being able to rely on cloud resources if applications require an amount of resources that surpasses what the end devices can provide. However, separating MEC and FC are various factors. Firstly, they are supervised by different research groups: respectively ETSI (see 2. 3) and the OpenFog consortium  [39]. Secondly, MEC can extract resources from RSUs exclusively, without relying on vehicles. Indeed, some deployments prefer not to rely on vehicular edge computing (VEC) when accomplishing tasks, whilst others allow to offload some of their requests to nearby vehicles if this process can reduce queue size and overall processing time  [40].
The data transmission between the two tiers happens via file exchange. This work showcases CoFluent's large modelization potential, with the simulation of most parts of an MEC environment, including the User Plane Functions and the MEC apps running within and MEC host. However this example serves as a basis for a 5G MEC architecture simulation, without treating the aspect of vehicular mobility. On the other hand, works like  [55]  implemented an MEC architecture using the Open Network Edge Services Software (OpenNESS), another Intel-developed toolkit, in order to model vehicular mobility in an urban context. In this experiment, each abstracted edge node acts as a host to OpenNESS services (i. e. the MEC apps defined earlier), and is thus reachable by other nodes seeking to consume a given set of.
In that regard, an edge computing architecture integrating 5G NR as a RAT appears to be the best candidate for remote driving  [58]. It can thus be understood that the choices of MEC architecture designs have to be made with respect to the applications and use cases that need to be satisfied in their given context. These potential choices and the reasoning behind them are exposed later in this survey, classified in three categories: Section 3. will cover the question of mobile network availability. Section 4. addresses how the architecture needs to evolve in order to improve service reliability as well as vehicular behavior in the case of loss of connectivity. Finally, Section 5. discusses the issue of the large amounts of data often handled by vehicular networks, given the extent of sensor information to transmit to satisfy a variety of applications.
Indeed, network service providers have been enduring increasing electricity costs  [33]. So, when facing the necessity to multiply the amount of base stations to extend coverage, the Cloud-RAN solution is envisioned instead. However, when combined with MEC, the amount of decentralized resources is doubled: network resources are split, and computing resources are brought to the edge of the system. The impact on user experience boils down to a need for two-tier resource allocation, where both resources need to match the required service in order to satisfy QoS requirements. In that regard, Wang et al. conceived a dynamic resource scheduling scheme dedicated to C-RAN MEC architectures  [71]. The resulting joint optimization problem increases the yield of power consumption and adapts to input data flows and job requests, but strays from a typical 3-tier MEC architecture.
In order to ensure continuity of wireless connectivity when a device leaves cell coverage, the current and upcoming BS share data to register the device's new position, in a new cell. Migration however, is a computing process regarding resource usage by mobile users  [73]. In the case of MEC, computing resources i. e. VMs and containers, are stored at edge servers. When a task is offloaded by a vehicle leaving edge server coverage, be it connected to an RSU or a BS, resource migration occurs. Thus, handover can be primarily perceived as a network issue, and migration as a system-oriented issue. A few works aimed at considering both questions concurrently  [74] , but their differing nature tends to motivate separate projects. The concept of fog computing was summarized earlier in this article.
As early as 2016, an extension called vehicular fog computing (VFC) became a major example of a way to get rid of the handover problem altogether: by relying on vehicles only, the intervention of network infrastructures is not needed anymore, as conceived in  [75]. With every piece of data traveling through the vehicle layer, latency is drastically lowered because no transmission needs to reach the core of the network, and load balancing is operated independently from a central controller. However, the obvious drawback is that performance depends directly on vehicle density, which can be a great opportunity to gather resources from neighboring and parked vehicles in urban environments, but loses its edge in highly mobile, sparse contexts. It could be assumed that there are fundamental disparities between VFC and MEC V2X like when used in a VEC infrastructure, with one striving to be exclusively dependent on vehicles and the other finding most of its scheduling processes within an edge computing infrastructure.
This intelligence can then be shared between servers to maintain a mutual awareness of devices and contexts in a wide area. Consequently, the implementation of deep-learning algorithms on top of cloudlet transmission and computing mechanisms implies supplementary CPU load. However, this investment provides the system with robustness in the face of context dynamicity, as well as quick data aggregation and latency reduction, especially when accessing Cloud services. This section established a number of ways to ensure reliable and efficient network distribution scenarios for various kinds of vehicular MEC applications. Whether the context of deployment is static or highly dynamic, concentrated or wide, dense or sparse, the amount of research that was conducted in this field brings enough tools to ensure satisfying coverage and handover.
Reliability and loss of connectivity In edge computing paradigms, the support of infrastructures is often needed to execute tasks that cannot be directly handled by the devices themselves. This support can be solicited because the available local resources are not sufficient to process a given task, or because the execution would take too long to satisfy delay constraints. In those cases, in V2X MEC networks, tasks need to be offloaded to edge servers, hosted by RSUs or BSs. To this end, vehicles make use of network coverage to send their data with the V2I interface. However, in the case of a loss of V2I connectivity (for instance when a vehicle is out of a coverage area), a mechanism needs to be implemented in order to guarantee continuity of service. This section exposes such mechanisms.
Compared to 802. 11p, with this novelty, V2I and V2V communications will not load the same channel and benefit from larger amounts of bandwidth. Consequently, inter-vehicular data transmissions are rendered more efficient and more flexible, as they can happen independently from infrastructure data reception. This represents a great improvement for MEC and VEC time-sensitive applications like alert-spreading and remote driving, as different blocks of data can be simultaneously transmitted toward vehicles and RSU edge servers to be processed. Nevertheless, the integration of 5G-V2X within a network infrastructure implies the deployment of 5G antennas, which has to be done strategically in order to serve all areas welcoming vehicular traffic. Also, this new standard relies heavily on network slicing to allow the network to adapt its service to a variety of demands and data types  [94].
This section provided an addition to the network coverage answers from earlier, by focusing on the issue of reliability in V2X MEC. It was shown that the advent of new-generation cellular technologies like 5G-V2X participated in the satisfaction of reliability constraints, but also that older, more widespread radio technologies like 802. 11p still had ways to perform reliably within vehicular networks. In V2X deployments, these improvements in success rates will be exploited to tackle the burning issue of large data transmission, computing and storage, stemming from the previously-exposed massive amounts of information generated by vehicular sensors. With highly populated, highly dynamic scenarios like urban mobility, the ability to handle large amounts of packets unlocks potential for a wide variety of use cases, from remote driving to infotainment.
Handling large data As the concept of IoV became increasingly widespread, a variety of applications that could be deployed over it emerged. As discussed earlier, some of these applications require ultra-low latency or flawless reliability. However, the advent of infotainment brought a new need to the table: the ability to handle large amounts of data. The following section helps explain why MEC and VEC satisfy this novel requirement that could have been overlooked in the first deployments of vehicular networks. We consider the potential to handle large amounts of data as the satisfaction of two requirements: an efficient computation offloading strategy in order to process complex tasks, as well as an appropriate storage policy to store and deliver data and computation results quickly and efficiently.
Computation offloading The main contribution of MEC is the reduction of latency when accessing remote computing resources. In MEC as well as VEC, devices are encouraged to exploit their surrounding devices' resources using task offloading. The content delivery mechanisms, especially for large amounts of data, can be conceived in multiple ways, depending on the performance metric that is prioritized. Offloading is built upon two facets: task computation and content delivery. The issue with content delivery in edge computing is the lack of efficiency when packets have not been cached at the edge servers, and thus need to be fetched on the cloud level. This process involves an uptick in latency (as data centers are located far away from the MEC server), which degrades the delivery efficiency.
Content categorization was also explored from an SDN standpoint. Liu et al. introduced cooperative data scheduling in an 802. 11p vehicular network, making use of both V2V and I2V communications dedicated to respectively sharing singular pieces of content requested by one user, and popular blocks of content requested frequently by multiple users. Both types of communication are overseen by the RSU, which hosts a central scheduler to help it target vehicles and data based on the neighboring information broadcast by all mobile devices  [103]. SDN entertains a global knowledge of road users, which allows for an optimal selection of the devices for whom the MEC server will fetch data. However, the amount of neighboring data coming to the RSU could overload the network in denser environments. Regarding large data handling, decision processes are many.
MEC integration within the RAT deployment is another approach to have been taken in the past few years. Concurrent to Cloud-RAN, the multiplication of RRHs on the road facilitates the handling of the highconsumption, highly dynamic traffic demand induced by 5G  [115]. Moreover, MEC platforms can be deployed closely to the BBU pool, which accelerates V2I exchanges and task offloading towards the edge layer depicted in Fig. 2. Tang et al. worked on the intricate link between cache pooling and user data to reduce delay for the delivery of popular content  [116]. They then experimented on various QoS-based cache management adaptive algorithms in order to determine which storage allocation strategy allowed to reach the highest hit ratio and the fastest content fetching speeds. It is observed that each algorithm, along with their dynamic variant, takes the lead in their own distinct field: field rate, access time, both with high and low RAM.
We understand that architectural choices are not the only criteria to be taken into account when designing V2X applications: algorithm selection plays its part in the fine-tuning of network performance. This section provided an analysis of the methods used in recent MEC and VEC architectures to handle large amounts of data. As vehicles pack a very limited amount of resources, it is indeed crucial to implement mechanisms that assist in the computing and storage of the numerous pieces of data generated by onboard sensors and fetched from the cloud. In this regard, offloading strategies provide additional computing capacity to users, be they load-centered or QoS-centered, with or without V2V support, reliant on cloud resources or not. Similarly, the cachemanagement solutions presented earlier all allow for better usage of space.
Major takeaways This section summarizes the findings introduced in this survey, focused on MEC-based vehicular network deployments. This summary is organized similarly to the core of our research: the first subject we address is network availability, followed by reliability, and then large data handling. Regarding network availability, here are the major conclusions we draw: • Multi-RAT deployments can cover wider areas and allow vehicles to circulate freely while using multiple links simultaneously. In exchange for additional MAC layer programming, heterogeneous networks balance channel loads, adapts to various densities of devices, and tailors their service depending on the user's needs. • Virtualized architectures reduce costs across the board, from request admissions to network equipments.
Privacy Data breaches represent a major risk in V2X MEC, as personal and device information may transit from the UE to the MEC server. This is already a burning issue with MEC  [19] , but its severity is increased in VEC, thanks to the advent of novel access points found in RSUs, it is now even easier from an outside observer to understand usage patterns. Indeed, an intruder can trace packet traffic that is exclusive to vehicular devices by focusing on data passing through these RSUs. By learning usage patterns of a given vehicle (context beaconing, safety alerts, etc. ), it can be easier to deduct activity and intervene in a malicious way. One way to counterbalance this issue is the implementation of multidestination task offloading, so as to throw off any attempt at catching patterns in the network usage.
Moreover, as applications are widely diversified and plan on staying this way, users need to rely on a multitude of third-party service providers. By soliciting these services, UEs need to provide context information to their current MEC server. Other than the fact that this mechanism is in and of itself risky if the third-party is not trustworthy, an intruder could deduct sensitive information from this context data. Consequently, there is a need to, firstly, certify third parties as trustworthy before authorizing their services to access the MEC system, and secondly, secure context-sharing so as to obfuscate personal information to attackers. Finally, it is important to remind ourselves that task offloading using V2V and V2I communications boils down to successive data transmission from point to point.
We will now see how, by achieving its advertised performance, the next generation of cellular networks is more than likely to call into question the MEC paradigm as it currently stands. Indeed, the sixth generation of cellular network aims to combine terrestrial base stations with satellites and UAVs in order to compensate for blind spots, thereby guaranteeing QoS continuity. Moreover, in order to reach the greatly publicized terabyte-per-second data rates, many changes in the way mobile networks operate need to take place  [130]. In the field of vehicular communications, the advent of quantum computing and their inherent security mechanisms will provide immense CPU power gains as well as protection against external threats. As for latency constraints, crucial to V2X, 6G will most likely integrate a variation of Non-Orthogonal Multiple Access (NOMA), which optimizes spectral efficiency and latency thanks to the removal of the grant period, hitherto crucial to OMA-based networks.
Heterogeneous computing is the major driving factor in designing new energy-efficient high-performance computing systems. Despite the broad adoption of GPUs and other specialized architectures, the interest in spatial architectures like fieldprogrammable gate arrays (FPGAs) has grown. While combining high performance, low power consumption and high adaptability constitute an advantage, these devices still suffer from a weak software ecosystem, which forces application developers to use tools requiring deep knowledge of the underlying system, often leaving legacy code (e. g. , Fortran applications) unsupported. By realizing this, we describe a methodology for porting Fortran (legacy) code on modern FPGA architectures, with the target of preserving performance/power ratios. Aimed as an experience report, we considered an industrial computational fluid dynamics application to demonstrate that our methodology produces synthesizable OpenCL codes targeting Intel Arria10 and Stratix10 devices.
Domainspecific architectures (DSAs) like GPUs and deep-learning focused devices (e. g. , Google TPU, Nvidia Tensor-Cores) overcome such limitations by tailoring to a specific class of computations. However, such advantages still remain restricted to specific application domains, generally making DSAs poor performing in others. Since their infancy, field-programmable gate arrays (FPGAs) were used as a means for fast prototyping application-specific integrated circuits (ASICs) or to speed the development of the software stack for a given architecture. The fast progress of manufacturing processes allows FPGA manufacturers embedding an ever-increasing number of functional blocks, leading to reconfigurable fabrics capable of accommodating very complex overlay computing architectures  [2, 3]. All this is making FPGAs more attracting, thus leading to an increased number of applications successfully ported on such spatial computing devices.
All the major FPGA manufacturers offer high-level synthesis (HLS)-based frameworks (i. e. , Intel's OpenCL-AOCL and most recently Intel oneAPI, Xilinx's HLS-SDAccel, Maxeler's dataflow compiler) to avoid the application developers the burden of optimizing their code both for (execution) time and space (i. e. , minimizing the number of on-chip resources that are used and also limiting the off-chip communication as much as possible). HLS tools are generally based on high-level programming languages and frameworks, like C/C++ and OpenCL; however, there is a lack of libraries of reusable components. Despite this, writing high-performance parallel code targeting modern FPGA fabrics is still a challenging task. Notably, fBLAS  [4]  represents an example of the effort for offering a high-level library of reusable components, which preserve performance across various target devices.
Here, the challenge is tougher than for DSAs since the interfaces of the components must conform to specific (high-level) standards to correctly exchange data each others. This introduces additional constraints to the compiling tool-chain that is in charge of translating high-level application codes into a register-transfer level (RTL) representation. Further, fBLAS re-usability is restricted to only C/C++ applications. Meta-programming frameworks have been proposed to ease the exploitation of spatial computing devices (e. g. , Maxeler), but their broader adoption is still far, as well as their capability of coping with the requirements of the large body of legacy scientific codes that are in use today.
3 Accelerating legacy applications with spatial computing… As a matter of fact, Fortran-based applications remain out of the support of such frameworks. While heterogeneous-oriented programming frameworks provide a clear pathway for 'code portability,' 'performance portability' challenge across multiple devices is not yet fully addressed. For instance, Zohouri et al. [5]  showed that porting OpenCL code optimized for GPU devices on FPGAs ended in a functionally correct code on the latter devices, but paid in terms of performance. Conversely, code optimized for FPGAs allowed to achieve better power efficiency. Recently, Intel introduced the oneAPI framework  [6] , which leverage on high-level coding to smoothly support CPUs, GPUs and FPGAs. Similarly, AMD offers tools easing the code acceleration using GPUs and FPGAs.
Specifically, we derived a methodology to map a selected Fortran routine (acceleration target) on an equivalent HLS synthesizable code, which can be accelerated on a FPGA device. To this purpose, our methodology is composed of three main steps, as follows: • (Automatic) translation of the original Fortran routine to be accelerated into a HLS-friendly language (OpenCL and C/C++ in our setup); • Creation of the additional FPGA kernel(s) and data handling support code; • Creation of data wrappers to properly map Fortran data structures with C/C++ types and data structures. The remainder of this paper is as follows. Section 2 introduces the selected test vehicle routine as the target for FPGA acceleration. Its subsection details the proposed methodology for mapping Fortran legacy code on the FPGA high-level synthesis (HLS) environment.
To this end, we looked at to the smoothing routine, that did not show such drawbacks. In fact, this routine caught our attention, since it shows interesting features that helped us to focus on the porting aspects of the code to the FPGA-based environment. Specifically, the routine is short and self-contained (does not rely on external libraries) and uses only easy mathematical operations (sums, multiplications and divisions) on arrays of single precision floats. As such, for the sake of simplicity, the whole application has been stripped down to a bare minimum, keeping only a Fortran main entry point, which is in charge of allocating the data arrays, loading input test data from a file and launching the routine. One important aspect concerns also the way the input dataset has been generated.