Alexandre Van Kempen

Teodor Crivat

Benjamin Trubert

Debaditya Roy

Guillaume Pierre

MEC-ConPaaS: An experimental single-board based mobile edge cloud

de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. INTRODUCTION

Disruptive interactive end-user devices are reaching the consumer markets. Following the purchase by Microsoft of HoloLens (a headset which projects holographic images into real space [START_REF]Microsoft HoloLens[END_REF]) and the $4.5 billion valuation of Magic Leap (a startup producing head-mounted displays for augmented reality applications [START_REF] Lunden | AR Startup Magic Leap Raises $793.5M Series C At $4.5B Valuation Led By Alibaba[END_REF]), similar technologies are now available in the consumer market with virtual reality headsets being commercialized for a few hundred Euros by HTC, LG, Oculus VR, Samsung, Sony, etc. Simultaneously, the very fast growth of Internet of Things brings a wide range of new products on the market from low-throughput sensor/actuator devices such as thermostats and connected toasters, to complex systems such as coordinated sets of surveillance cameras covering an entire neighborhood.

We can therefore expect the very fast emergence of a new family of edge applications which are defined as applications building a seamless interactive continuum between the physical and digital world, blending atoms and bits [START_REF] Saracco | The fading line between atoms and bits[END_REF]. In the longer run, besides the obvious usage of these technologies for entertainment purposes, numerous applications are also expected in domains as diverse as live events coverage, healthcare, engineering, real estate, military, retail, and education [START_REF] Sachs | Virtual & augmented reality: The next big computing platform?[END_REF].

Following the current trend of ever-increasing importance of mobile devices and infrastructures [START_REF]The mobile economy[END_REF], end users will expect edge applications to be mobile. Applications will however require massive computation and storage to remain continuously available and responsive while processing potentially very large volumes of data. Yet, although large quantities of computing resources are readily available in cloud platforms, traditional cloud infrastructures are ill-equipped to fully address the challenges of future mobile edge applications. As they rely on a handful of very large data centers, public cloud providers are often located very far from their end users, which does not match the requirements of edge applications:

• Interactive edge applications require ultra-low network latencies. To guarantee an "instantaneous" feeling for the users, applications such as augmented reality require that end-to-end latencies (including all networking and processing delays) should not exceed 10-20 ms [START_REF] Abrash | Latency -the sine qua non of AR and VR[END_REF], [START_REF] Blog | John Carmack's delivers some home truths on latency[END_REF]. However, measured latencies to the closest available data centers typically range from 20-30 ms using high-quality wired networks, up to 50-150 ms on 4G mobile networks [START_REF]Planetary-scale cloud latency auditing platform[END_REF], making traditional cloud resources unsuited for demanding applications.

• Throughput-oriented edge applications require local computations. The sources of application input data and the destination of computation results are often located geographically close to each other [START_REF] Scellato | Distance matters: Geo-social metrics for online social networks[END_REF]. However, with only a handful of data centers from which to choose the location of data processing, input and output data are often transferred needlessly over long distances. This wastes long-distance networking resources, and may even create legal issues if the data center is not located in the same country as the end users.

• Dependable edge applications must tolerate poor network connections. Although cloud data centers are typically provisioned with excellent network connectivity, the same is not always true on the client side. Depending on the nature of the application, the availability of stable high-bandwidth wireless network connectivity may not always be guaranteed in locations relevant to the application. For example, an application dedicated to supporting emergency services during their operation must work seamlessly regardless of the location of the emergency (underground, in rural areas, etc.) where 4G network connectivity is often unreliable or even totally unavailable.

To address these challenges, the mobile networking industry is heavily investing in mobile edge cloud computing (MEC) platforms located at the edge of the networks, in immediate proximity to the end users [START_REF]Mobile edge cloud[END_REF], [11], [START_REF]Open Edge Computing Initiative[END_REF]. Instead of treating the mobile operator's network as a high-latency dumb pipe between the end users and the external service providers, MEC platforms aim at deploying cloud functionalities within the mobile phone network, inside or close to the mobile access points. Doing so will deliver added value to the content providers and the end users by enabling new types of user experience. Simultaneously, it will generate extra revenue Mobile edge clouds have very different geographical distribution compared to traditional clouds. While traditional clouds are composed of many reliable and powerful machines located in a very small number of data centers and interconnected by very high-speed networks, mobile edge cloud are composed of a very large number of points-of-presence equipped with a couple of weak and potentially unreliable servers, and interconnected with each other by commodity long-distance networks. This creates new demands for the organization of a scalable mobile edge computing infrastructure, and opens new directions for research.

However, deploying a realistic mobile edge cloud remains a challenge. Mobile operators have not deployed MEC technologies in production yet, which makes it impossible for researchers to deploy their technologies in actual mobile phone networks. An alternative for them is to emulate a mobile edge cloud which uses Wi-Fi connectivity instead of LTE between the users and the edge cloud, but here as well there exists very few open-source platforms which may support such experimentation. The most mature one is probably Open-Stack++ [START_REF] Ha | OpenStack++ for cloudlet deployment[END_REF], but this system relies on classical server machines for its deployment. Deploying an experimental testbed reproducing a realistic geographical dispersion of computing resources therefore remains a challenge.

In this paper, we claim that an easier way to deploy an experimental MEC testbed is to rely on single-board computers such as Raspberry Pis (RPis) and similar devices. These devices are sufficiently inexpensive and power-efficient to be realistically deployed over a metropolitan area while providing sufficient computation power to support a large range of edge applications. We therefore discuss the design and implementation of an open-source platform for mobile edge clouds. For simplicity, we use Wi-Fi connectivity instead of LTE-based one where the same devices act both as a Wi-Fi hotspot and a cloud node, naturally providing extremely low network latency between end-user devices and the cloud instance(s) serving them.

The remainder of this paper is organized as follows. Section II discusses the state of the art. Then Sections III, IV, V and VI respectively discuss the system overview, hardware design, system-level and middleware design. We present the evaluation of an application deployed on Raspberry Pis in Section VII. Finally, Section VIII concludes.

II. STATE OF THE ART

The trend towards pushing cloud computing to the edge of a network is expected to accelerate, and 2016 has already been named the "year of the edge" [START_REF] Edgeconnex | Edgeconnex R announces findings from webinar on improved internet performance via edge infrastructure deployments[END_REF]. Edge computing originated from research efforts on Cloudlets, which propose to deploy a specific infrastructure at the edge of mobile networks to support dynamic application deployment in the immediate proximity of the end users [START_REF] Satyanarayanan | The case for VM-based cloudlets in mobile computing[END_REF], [START_REF] Lewis | Cloudlet-based cyber-foraging for mobile systems in resourceconstrained edge environments[END_REF]. The outcome of this work is OpenStack++, an extension of the popular OpenStack cloud computing platform which includes mechanisms for application deployment in a fog computing context [START_REF] Ha | OpenStack++ for cloudlet deployment[END_REF]. However, this platform is meant to execute on powerful server machines, which makes it difficult to deploy in a realistic geo-distributed setting.

From the point of view of interactive applications, it has been demonstrated that co-locating cloudlets with their end users drastically improves the execution of latency-critical applications [START_REF] Clinch | How close is close enough? Understanding the role of cloudlets in supporting display appropriation by mobile users[END_REF]. However, the maximum tolerable distance between services and users depends on many factors including the level of interactivity of the application, the end-toend network latency, the hosts hardware and software stack capabilities, and the users behavior. Similarly, the impact of user-service proximity in highly-interactive applications such as video streaming and collaborative chatting has been studied in [START_REF] Fesehaye | Impact of cloudlets on interactive mobile cloud applications[END_REF]. A cloudlet-based approach always outperforms the classical cloud-based approach when clients are separated from their service with no more that two wireless network hops. Finally, the performance of different infrastructure settings (backend cloud, edge cloud and hybrid) are compared in [START_REF] Baguena | Towards enabling hyper-responsive mobile apps at scale using edge assistance[END_REF]. They concluded that a smartly balanced hybrid infrastructure can bring the best of both worlds: the low latency of edge clouds and the high computing power of backend clouds.

As a result, many efforts focus on improving various aspects of mobile edge clouds. For example, the European Telecommunications Standards Institute's Mobile Edge Cloud group is busy designing ways to implement mobile edge clouds as a part of the upcoming 5G mobile network standards [START_REF]Mobile edge cloud[END_REF]. The OpenFog consortium [11] (ARM, Cisco, Dell, Intel, Microsoft, etc.) and the Open Edge Computing Initiative follow similar objectives with slightly different technical principles.

Many efforts also focus on the lower layers, down the the hardware level. For example, the recent ARM "Intelligent Flexible Cloud" (IFC) initiative pushes towards distributing intelligence towards the network edge [START_REF] Fry | The intelligent flexible cloud[END_REF]. In particular, a new family of processors, the ThunderX was specifically designed to support very efficient virtualization and contribute to Mobile Edge Computing platforms. ARM IFC also proposes an architecture that makes intensive use of emerging Network Function Virtualization (NFV) technologies.

Developers should be able to leverage the computing power of such mobile edge clouds, without having to handle the complexity of application deployment, fault tolerance issues, reconfiguration, or elasticity. Abstracting the complexity of the underlying platform enables developers to focus on application-specific concerns rather than on cloud-specific details. Platform-as-a-Service (PaaS) is a well known paradigm that provides services to developers, like commonly used runtime environments, so that existing applications can easily be ported to any cloud platforms.

In this paper, we rely on ConPaaS, an open-source runtime management system for elastic applications in public and private cloud environments [START_REF] Pierre | ConPaaS: a platform for hosting elastic cloud applications[END_REF]. We now extend this work to mobile edge cloud environments characterized by the small size and broad geographical distribution of its computing resources. Following on previous work which investigated virtualization technologies for single-board computers [START_REF] Tso | The glasgow raspberry pi cloud: A scale model for cloud computing infrastructures[END_REF], [START_REF] Abrahamsson | Affordable and energy-efficient cloud computing clusters: The bolzano raspberry pi cloud cluster experiment[END_REF], we rely on single-board computers such as Raspberry Pis and PINE A64+. However, contrary to these earlier contributions, we exploit these devices to build a widely-distributed mobile edge cloud rather than a single inexpensive data center. The closest work to ours has been recently published in [START_REF] Bellavista | Feasibility of fog computing deployment based on docker containerization over raspberrypi[END_REF], where the authors show the feasibility of using constrained nodes as fog gateways. However, this work target Internetof-Things (IoT) scenarios where the fog gateways act as an intermediate layer between the IoT devices and a centralized cloud. In contrast, we seek to provide an open-source platform that enable developers to easily deploy applications within the fog platform itself, as close as possible to the end users.

III. SYSTEM OVERVIEW

MEC-ConPaaS is a mobile edge cloud platform designed to be physically deployed across a city center or campus-sized geographical area, and to execute single-user and multi-user edge applications where proximity between the cloud instances and their end users is important. We first present a typical use case, then discuss the system architecture which supports it.

A. Use case

One application domain of mobile edge clouds is the tourism industry. When tourists visit a place unknown to them, they are in frequent need of local information and services to handle practical matters (local transportation, restaurants etc.), cultural ones (heritage, history, etc.) and entertainment. An example application that may be deployed for them is presented in Figure 1: this application captures a live video taken from the user's smartphone or tablet, identifies written signs from this video feed, and super-imposes a translated version of the recognized text in a different language.

This application is too complex to be executed in typical end-user mobile devices: it requires real-time optical character recognition, translation and video synthesis, which are beyond the processing capacity of a tablet or smartphone. Any application attempting to execute such application locally would quickly drain the battery. At the same time, there is no strong reason to upload the video feed to a cloud data center since both the source and destination of the workflow are located in the end user's device. Processing this workload as close as possible from the end user can only improve the application's responsiveness while saving precious long-distance networking resources.

Depending on the requirements of the application, specific components may be preferably located on the end-user device, the mobile edge cloud, or a traditional cloud backend. For example, the optical character recognition operator may require heavy real-time computations, and the translation operator may require access to large volumes of data, two requirements incompatible with end users devices. These operators may therefore be placed in the mobile edge cloud, and dynamically scaled in and out according to the current workload. In addition, the appropriate network functions are automatically deployed and configured each time the requirements or the set of resources change, such that the application can abstract itself away from the architectural details of the underlying network.

B. Architecture

As shown in Figure 2, the MEC-ConPaaS platform can be deployed over single-board computers which are geographically distributed across the relevant area (such as a city center or a university campus). Each of the system nodes acts both as an access point and a cloud server: every node is equipped with a Wi-Fi interface to which client nodes can connect; at the same time, the same nodes operate as a virtualized infrastructure which can deploy applications in immediate proximity to the end users. The system is controlled by a traditional server which acts as the entry point of the system. The system's architecture, depicted in Figure 3, comprises multiple layers that we describe hereafter from bottom to top. The hardware layer is composed of single-board computers such as Raspberry Pis, which provide the required computing resources, acting as light-weight cloud-like facilities. All these low cost devices are equipped with wifi interfaces to directly communicate with users at the edge. The interconnection between those devices can be ensured via a wired backbone network, or by leveraging their respective wifi interfaces. In order to provide elasticity and fault tolerance, applications are deployed inside a virtualized environment hosted on the same single-board devices. MEC-ConPaaS relies on LXC containers, which provide great levels of flexibility while being much lighter-weight than traditional virtual machines. These containers are orchestrated with OpenStack, while the ConPaaS layer, on top of OpenStack, eases the deployment of actual elastic applications [START_REF] Pierre | ConPaaS: a platform for hosting elastic cloud applications[END_REF]. Each of these layers is described more thoroughly in the next sections. MEC-ConPaaS is readily available under a liberal opensource license 1 . It can be easily deployed over a set of singleboard computers to deploy a mobile edge cloud platform onthe-fly, in geographical areas with limited coverage. MEC-ConPaaS may also be used to bring mobile edge applications during a specific event (e.g., a scientific conference or a rock concert). Finally, keeping an application's data flow inside a controlled and secured platform, instead of relying on external cloud operators, is another typical use case of MEC-ConPaaS.

IV. HARDWARE LAYER MEC-ConPaaS relies on small single-board computers to act as both its Wi-Fi access points and its edge-cloud storage and computation servers. The rationale behind this choice is that simple-board computers offer a very interesting price/performance/power/volume tradeoff compared to traditional high-performance servers. For example, it is very easy to deploy a few dozen Raspberry Pi servers across a building. All that is required is to plug them in an electricity outlet and to connect them to the local LAN or Wi-Fi network. As Fig. 3: MEC-ConPaaS' system architecture weak as these devices might appear, we consider that they are largely powerful enough to constitute an excellent basis for a metropolitan edge cloud platform. To demonstrate the potential of these devices to act as cloud resources, in this section we measure and compare three single-board devices in terms of storage, CPU, memory, network and power consumption.

Raspberry Pis are the most famous line of single-board devices that may be used for such a purpose. However, other similar devices such as the PineA64+ or ODROID-C2 are currently reaching the market, each with their respective performance-price ratio. We compare the performance of two Raspberry Pi versions, the Raspberry Pi 2 and the Raspberry Pi 32 with the PineA64+ 2GB 3 , and with a recent HP 820 G2 laptop which acts as a reference point. An overview of their respective hardware specifications is shown in Table I. Note that for the ARM boards (RPi2, RPi3, PineA64+), we tested different SD cards in order to ensure that the cards themselves were not the performance bottleneck. We report results based on class-10 Verbatim MicroSDHC cards.

The results of our benchmark measurements of these four devices are presented in Table II. We conducted every measurement 5 times. We removed the minimum and maximum values, and report the average value among the remaining three measurements. In all cases the standard deviations remained within 4% of the average.

Storage throughput:

We compared the storage throughput using the sysbench utility, with a file size being the double of the available RAM to avoid caching effects. We report throughput results obtained under a random access pattern which is representative of the usage of a cloud server. The 32 GB card we tested is clearly the bottleneck here, as the three boards all provide a throughput around 2.5 MB/s. In comparison, the laptop's throughput based on a state-of-theart SSD drive is an order of magnitude faster.

CPU performance:

The CPU score is obtained via the sysbench utility as well, using 4 threads in order to fully utilize the quad-core CPUs. Interestingly, the PineA64+'s performance comes close to that of the laptop, while there is a significant difference between the PineA64+ and the Raspberry PIs. This comes from the fact that sysbench has been optimized for 64 bits instructions and the Raspberry Pis are still running a 32-bits operating system. We therefore expect that future single-board devices will feature CPU performance that is at least on-par with the PineA64+.

Memory throughput: we measured the memory throughput using the mbw tool. Results show little difference between the Raspberry Pi 3 and the PineA64+, which both outperform the Raspberry Pi 2.

Network throughput: measurements were conducted using iperf and are in compliance with each device networks cards. Interestingly, the PineA64+ is capable of saturating a gigabit link. In comparison the Raspberry Pis' network operates over the USB bus, which strongly limits the network throughput.

Here as well we can expect that future versions of the Raspberry Pi may feature significantly greater network capacity.

Power consumption: we measured the devices' power consumption using a power meter placed between the device and the electric outlet. To avoid any interference with the laptop's battery, we removed the battery during these measurements. We respectively measured the electrical consumption when the devices were idle and under full CPU load for two minutes, with one measurement taken every 5 seconds. When idle, the laptop and all the three boards were respectively consuming around 15 Watt and 2 Watt, on average. When running at full load, the Raspberry Pi 2, Raspberry Pi 3 and the PineA64+ were respectively consuming 3.6, 4.4 and 4.1 W in average, while the laptop reached 24.5 W.

Lastly, as explained in the previous section, MEC-ConPaaS heavily relies on containers to provide elasticity. We thus also ran every test inside an LXC container to evaluate the overhead due to virtualization. In all our tests, the virtualization overhead remained below 6%.

The conclusion of these benchmarks is that the single-board devices offer a very interesting performance/price tradeoff compared to the tested laptop. In particular, the Pine A64+ performs very close to the laptop regarding the CPU, memory and networking components, while being over one order of magnitude cheaper. We believe it demonstrates the ability of single-board devices to deliver excellent performance/price ratios. The only component for which it is still significantly lagging behind is storage, which is inherently limited by poor performance of the SD-card technology. However, newer devices such as the ODROID C2 are now starting to use (hopefully faster) eMMC storage devices.

The Raspberry Pis represent a slightly older generation of single-board devices. However, we expect that future versions are going to keep up with these very fast hardware developments. On the other hand, the Raspberry Pis excel in other dimensions such as the size and reactiveness of their user communities, and the variety of retail options. For these reasons, we based the implementation of MEC-ConPaaS (and the evaluation section of this paper) on Raspberry Pi 3 devices, in anticipation of future hardware improvements of Raspberry Pi devices.

V. SYSTEM LAYER

Although single-board computers such as Raspberry Pi and PineA64+ are very capable machines, using them as compute and storage nodes in a cloud setup is not an easy exercise. The challenges are mainly twofold: (i) updating the provided operating system and libraries so that they integrate the relevant support for virtualization; and (ii) addressing the performance limitations of the single-board devices to use them at the best of their capacity.

A. Virtualization support

The recent ARM processors which power the vast majority of single-board computers include hardware support for virtualization. However, we decided to base ourselves on LXC containers rather than virtual machines. The main reason is memory: single-board computers have very limited main memory size (between 1 and 2 GB), which strongly limits the number of VMs which could be executed simultaneously on a single device. In contrast, containers are much more lightweight in this respect, which proved to be essential for resource-constraint devices such as Raspberry Pis. This however implies that the Linux kernel must be compiled with LXC-specific options enabled, like cgroups or cpuset support, and a libvirt API with full support of LXC. Note that depending on the board used, some recent distributions such as Debian 8 now natively enable those options, contrary to what was available at the time of our experiments. In addition, one must configure OpenStack to make use of the LXC driver installed on every compute nodes. Note that we released MEC-ConPaaS in the form of readymade images 4 that can be directly copied on the intended devices so no specific configuration is required from the MEC-ConPaaS users.

B. Performance tuning

Even though single-board computers are becoming increasingly powerful, they still have many performance limitations. In our experience, the most challenging bottleneck that must be addressed to obtain decent performance is the very slow I/O throughput highlighted in Section IV, together with the limited main memory size. It is therefore essential to carefully customize the default operating system configuration to avoid common pitfalls. The following optimizations enabled us to reduce the duration of a container creation operation from 10 minutes to about 90 seconds on a Raspberry Pi 2.

The first obvious optimization is to strip the Raspberry Pi devices from all the unnecessary software and services. OpenStack services can be very memory-hungry so we installed only the strict minimum on the Raspberry Pi devices: nova-compute (which controls the creation/deletion of LXC containers) and cinder-volume (which controls the creation/attachment/detachment/deletion of storage volumes). All other OpenStack services related to authentication, virtual disk image management and such, are rather installed on a single powerful "master node" which acts as the entry point of the system.

The SD cards which act as the only storage device of all our single-board computers are not meant to store a Linux file system composed of a myriad of small files: SD cards are mostly used in mobile phones and similar devices to store a relatively small number of large files such as photos and videos. As a result, these cards are designed to use relatively large block sizes, in the order of 4 MB. It is therefore essential to align the file system partitions on the SD card's erase block boundaries to avoid generating unnecessary I/O upon any file system operation.

Finally, an important kernel parameter for the overall system performance is the so-called swappiness. This parameter controls the relative weight given to swapping out runtime memory, as opposed to dropping pages from the system page cache. A low value causes the kernel to avoid swapping as much as possible while a higher value causes the kernel to use the swap space much more proactively. In most Linux distributions for single-board computers, SD-card throughput is known to be an important performance bottleneck and, hence, the default swappiness value is set to 1 out of the [0; 100] interval of possible values. This means that the system should swap only when absolutely necessary. For most purposes where the available memory is sufficient to hold the entire runtime memory, this is indeed a valid configuration.

However, executing a few OpenStack daemons and starting a new container consumes a lot of memory, and often temporarily exceeds the available memory on a Raspberry Pi. With a very low swappiness value, the system can page memory only at the time a new container is being created, which considerably slows down this creation.

Another indirect consequence of a low swappiness value is that it leaves little space (if any) to store the file system cache: in Linux, the file system cache occupies the currently unused main memory. Without a disk cache, every single file access is systematically translated in one or more I/O operations addressed to the SD card. A container creation operation accesses many files such as the usual system binaries, the Python runtime, configuration files and such, which therefore produces a sudden burst of I/O operations which considerably delay the container creation.

In our use case, many of the running services are used only for a brief moment during the container creation operation. These memory pages should thus be swapped out as soon as possible, in order to make more room for actual application memory and for the disk cache. We therefore set the swappiness to the greatest possible value (100), which offered major performance improvements. Note that this configuration does not increase the total volume of data which has to be written/read to/from the SD card: in fact, it actually reduces the total number of I/O operations compared to the original swappiness value.

VI. MIDDLEWARE LAYER

Deploying a complex application on a traditional cloud platform is not an easy task; deploying it on an edge cloud will certainly be even less so, as one has to deal with extra concerns such as the geographical location of the end users and the cloud resources supporting their applications. In order to ease this deployment, we leverage the ConPaaS system, which is an open-source multi-cloud run-time management system for elastic applications [START_REF] Pierre | ConPaaS: a platform for hosting elastic cloud applications[END_REF]. ConPaaS lets its users upload simple application code, and takes care of handling the complexity of deploying such applications in cloud environments. It automates the entire life-cycle of an application, including collaborative development, deployment, performance monitoring, and automatic scaling.

In ConPaaS, applications are organized as a collection of services. ConPaaS currently provides ready-made services for a number of commonly-used middlewares: web hosting (PHP and Java), SQL and NoSQL databases (MySQL and Scalaris), data storage (XtreemFS) and for large scale data processing (Task Farming, MapReduce and Apache Flink). Applications making use of these middlewares only need to create the appropriate service and upload the relevant code or data to this service. The system automatically takes care of provisioning one or more containers, deploying the application, implementing horizontal elasticity, etc. Applications which do not fit in this model may make use of the "Generic" service, which enables users to package arbitrary code and data, and deploy it similarly to the other services. The only difference is that application-specific operations such as the dynamic addition and removal of computing resources must be implemented by the application rather than by the ConPaaS system.

The horizontal elasticity properties of ConPaaS are also useful to implement seamless service migration. When a user moves around the area covered by the mobile edge cloud, it may be desirable to migrate the applications serving her such that the application is constantly within very short network distance to the user. If the applications are elastically scalable, this migration may be elegantly implemented by creating a new instance of the application in the desired destination node, followed by removing the original instance in the previous location.

Finally, ConPaaS was originally designed to operate over a variety of public and private clouds such as Amazon EC2, OpenStack and OpenNebula. We extend, in this paper, the underlying cloud infrastructures to include mobile edge cloud environments that may help an application to place its points of presence close to its users, thus performing computations more locally and reducing the latencies.

VII. EVALUATION

We now illustrate the way an application developer can exploit MEC-ConPaaS to create innovative applications supported by mobile edge cloud technologies. To this end, we make use of a simple example application which performs face recognition in a live video stream [START_REF] Tetzlaff | Finding faces[END_REF].

The application is implemented using the Apache Flink stream-processing middleware [START_REF] Alexandrov | The Stratosphere platform for big data analytics[END_REF]. Although the stream processing model was initially designed to handle data analytics applications, we believe it is particularly well-suited for developing mobile edge applications as it provides developers with an easy-to-understand development environment, while being able to harness the full capacity of cloud infrastructures to achieve extremely high performance. In addition, the organization of the application as a workflow of operators offers a simple yet powerful abstraction which facilitates the deployment and run-time management of the application in complex multi-cloud environments.

Several mature stream processing platforms are currently available in open-source, the most notable ones being Apache Storm [START_REF]Apache Storm[END_REF], Apache Spark [START_REF] Zaharia | Resilient distributed datasets: A fault-tolerant abstraction for in-memory cluster computing[END_REF] and Apache Flink [START_REF]Apache Flink project[END_REF]. In this example we chose to rely on the Flink platform as it combines benefits inspired by Storm and Spark: like Storm, Flink provides low-latency stream processing by pipelined data transfers that can deliver high throughput across a wide spectrum of latencies and strong consistency guarantees even in the presence of stateful computations. Like Spark, Flink offers a high-level API. Also, unlike Apache Spark, which breaks down continuous computation into a series of small, atomic batch jobs (micro-batching), Flink is primarily a stream processing framework, which makes it particularly suitable for hyperinteractive applications where low latency is a requirement.

With this example, we show how MEC-ConPaaS offers a new application domain for stream-processing systems in a fog context, as it automatically deploys, migrates and reconfigures applications to maintain their performance close to optimal despite arrivals or departures of users into/from the application, variations in the workload imposed by the users, or end users mobility. This will benefit both application developers who will be able to exploit the full power of fog computing while retaining an intuitive programming model, and the streamprocessing community which will expand their scope to new customers and application scenarios.

The face recognition application is a small Flink program, written in Java, which leverages the OpenCV library 5 to perform image processing. This library unfortunately does not implement any form of parallelism, thus limiting the execution of the face recognition functionality in a single thread. Thanks to the Apache Flink service provided by ConPaaS, a user can simply upload this application to the MEC-ConPaaS system which then automatically deploys the application on the underlying cloud infrastructure.

Figure 4 show the resulting processing times for 5 different videos, and for three computing platforms: the laptop configuration and the two Raspberry Pi versions. Note that we did not include the Pine A64+ in the evaluation, as ConPaaS was not yet fully ported on this platform at the time of writing. These results show that, even though a Raspberry Pi cannot keep up with the performance of a recent laptop, the ratio of execution times between the laptop and raspberries is only 3 or 4. This is remarkable given that the microbenchmarks presented in section IV rather showed an order of magnitude between the two device families. In addition, the Raspberry Pi 3 offers performance improvements up to 30% on some videos when compared to the Raspberry Pi 2, as expected in regards with the microbenchmarks section. We unfortunately could not test the horizontal scalability of the system because the compute-intensive part of the application relies on the single-threaded OpenCV library. However, an improved multithreaded version of the same application should be able to exploit the capabilities of multiple co-located compute node, and to reach comparable levels of performance to that of a high-performance server 6 .

Finally, we evaluated the overhead due to the ConPaaS deployment system on the processing time by comparing performance with that of a traditional deployment with no virtualization nor cloud technologies. We clearly see in Figure 5, that ConPaaS generates a very small overhead both on the Raspberry Pi 3 or the laptop configuration, whereas it considerably eases the application deployment on the computing units.

VIII. CONCLUSION

Cloud infrastructures are extremely flexible and powerful, but their data centers are located very far from the end users. This creates a need for complementing these infrastructures with additional "mobile edge cloud" resources located at the edge of the network, in immediate proximity of the end users. However, deploying a realistic mobile edge cloud remains a challenge, which unnecessarily limits the possibilities for researchers to experiment with various types of mobile edge applications and middlewares.

We presented MEC-ConPaaS, an open-source platform which aims to support further research efforts in the domain of mobile edge cloud applications and middleware. MEC-ConPaaS is designed to be extremely easy to deploy over a university campus or a city center, and to operate using lightweight and inexpensive single-board computers.

Fig. 1 :

 1 Fig. 1: Example of a stream-processing-based mobile edge cloud application

Fig. 2 :

 2 Fig. 2: Geographical distribution of a MEC-ConPaaS deployment.

Fig. 4 :

 4 Fig. 4: Comparison of processing times depending on the different computing units

Fig. 5 :

 5 Fig. 5: ConPaaS overhead evaluation

TABLE I :

 I Hardware specifications.

				RPi2		RPi3	Pine A64+	HP 820 G2
	Machine type		Single-board		Single-board	Single-board	Laptop
		Storage		32 GB microSD card	32 GB microSD card	32 GB microSD card	512 GB SSD drive
				Broadcom		Broadcom	AllWiner	Intel
		CPU		Quad-core 900MHz 32 Bits	Quad-core 1.2GHz 64 Bits	Quad-core 1.2GHz 64 Bits	2 cores -4 Threads 2.6GHz 64 Bits
				ARM Cortex-A7	ARM Cortex-A53	ARM Cortex A553	Intel core i7 5600U
		Memory		1GB 450MHz LPDDR2		1GB 900MHz LPDDR2	2GB DDR3	16GB 1600MHz DDR3L
		Network		100 Mbps		100 Mbps	1Gbps	1Gbps
	Price incl. storage	∼ 82 e		∼ 92 e	∼ 74 e	∼ 1600 e
	TABLE II: Performance comparison between 3 ARM-based single-board computers and
	a reference laptop.
		RPi2	RPi3	Pine A64+	HP 820 G2
	Storage (MB/s)	2.45	2.53	2.42		23.9
	CPU (s)	82	46.5	4.1		2.8
	Memory (MB/s)	272	933	1098		5658
	Network (Mb/s)	94.1	94.2	922		935
	Power when idle (W)	2	2	2		15
	Power under load (W)	3.6	4.4	4.1		24.5

http://www.conpaas.eu

https://www.raspberrypi.org/

https://www.pine64.org/

http://www.conpaas.eu/download/

http://opencv.org/

Single-board computers are also often equipped with one or more GPUs which could also be used to speedup this type of computations.

We demonstrated that single-board computers, if exploited correctly, have enough capacity to process serious mobile edge applications. We based our implementation on Raspberry Pi devices, which have the advantage of being very well supported and easy to purchase. The very fast development of other brands of single-board devices suggest that future generations of single-board computers will deliver even much greater performance, while retaining the same very low cost, volume, and power consumption as the devices available to us today.


Nicolas Maestripieri

published or not. The documents may come     Industrial plantations in southern Chile. Retrospective analysis and development of prospective scenarios spatially explicit (district of San Juan de la Costa -Chile)

Industrial plantations in southern Chile. Retrospective analysis and development of prospective scenarios spatially explicit (district of San Juan de la Costa -Chile)

Nicolas Maestripieri PhD student at the Laboratory of Geography of the Environment (GEODE)

Introduction and/or general background

The first exotic species appeared in the district of San Juan de la Costa (Los Lagos Region -Chile) in the 1990s. Predominantly populated by indigenous Mapuche this district has the highest poverty rate in the country. The arrival of multinational timber generated many environmental problems such as degradation of water resources, the substitution of native forests, biodiversity loss, accompanied by rising unemployment and a rural exodus.

Chile has since the 1970's an exceptional growth of its forest sector fueled by high-yield industrial plantations. The politico-economic orientation taken by the Chilean State, including the promulgation of Decreto Ley 701 (1974) and repeated updating, was the keystone of this forest expansion. He allowed the landowners and pulp industries to build in a few years, a nationwide weighty forest heritage.

The plantations are mainly concentrated in the 8th Region of Bio Bio in the 10th Region de Los Lagos. However, their distribution is not uniform and there is a clear interregional imbalance. Given that business strategy is to expand their forest heritage, the latter actually focus on new areas suitable for afforestation, as the district of San Juan de la Costa.

Objectives/purpose and scope of the study or project

The aim of this research is to arrive then at a future vision of the land and, more specifically, about the possible influence of multinational forest land in a district where the recognition of indigenous lands is lacking.

To answer this question we follow the methodology of scenario building [START_REF] Hatem | La Prospective. Pratiques et Méthodes[END_REF][START_REF] Jouvenel | La démarche prospective. Un bref guide méthodologique[END_REF][START_REF] Houet | Modélisation prospective spatialisée à l'échelle locale : approche méthodologique. Application à la gestion de l'eau en Bretagne[END_REF], offering three contrasting scenarios in order to achieve a representative range of possible futures.

Methodology of the work, research or project

The construction phase scenarios go through a retrospective analysis of the dynamics of land across the municipality. To do this, we use three Landsat satellite images taken in 1986, 1999 and 2008. Analysis of changes in land use will occur in three stages, with (i) quantifying the losses and gains, the analysis (ii) of the spatial distribution of these changes, and (iii) trajectories of evolutions. This phase will be refined by the identification, characterization and weighing of many factors playing this expansion. The spatial allocation of future dynamics will be made via a multi-criteria evaluation (MCE). This will locate areas suitable for establishment of monoculture that rankings of competency units of space (pixels or geographic features) [START_REF] Paegelow | Aide à la décision -Evaluation multicritère et multiobjectif -Note de cours[END_REF] Three scenarios: The first scenario (MCST) is exploratory. This assumption is the continuity of policies to encourage reforestation with forest owners, however, by offering an alternative to exotic plantations to small owners. The growth is continuing. Scenarios 2 (M2E) and 3 (M0P) are prescriptive and suggest future mixed. The first count on a land cover dominated mostly by industrial plantations, while the second, more idealistic, assumes no growth.

Analysis and/or results, conclusions

Exotic plantations occupy only a very small share of the communal area (1% in 1986 and 4.3% in 2008), unlike the native forests (respectively 69.2% and 54%). However over 90% of them are on the Piedmont, on lands accessible, to low slope, and where the property system favored the purchase of thousands of hectares by enterprises. The trajectories of changes are indicative of many modifications, including loss of thousands of hectares of native forests for the benefit of exogenous plantations. The multicriteria evaluation will provide key elements to understanding the future trends of development, based on past dynamics.


C Pean

B Daffos

C Merlet

B Rotenberg

P.-L Taberna

P Simon

M Salanne

Single Electrode Capacitances of Porous Carbons in Neat Ionic Liquid Electrolyte at 100 • C: A Combined Experimental and Modeling Approach

Supercapacitors are promising devices for energy storage. Being able to measure and predict their performances is a key step in order to optimize them. In the present study, we propose an original methodology to calculate the capacitance of a single nanoporous carbon electrode in contact with an ionic liquid, using molecular dynamics simulations. The results are compared to experimental electrochemical measurements conducted on the same systems at high temperature (close to 100 • C). The two approaches are in qualitative agreement and show that, in the case of a butyl-methylimidazolium hexafluorophosphate electrolyte combined with a carbide-derived carbon with an average pore size of 0.9 nm, the positive electrode capacitance is fairly larger than the negative one. DOI: 10.1149/2.0151505jes

Electrochemical Capacitors (ECs), also known as supercapacitors 1 are now mature enough -in terms of power and energy density -to complement or even replace batteries in various applications ranging from power electronics to automotive industry (electric and hybrid electric vehicles, boats, trams. . . ). 2 The fast development of this technology was facilitated by key scientific breakthroughs over the past few years, such as the discovery of capacitance increase in subnanometer pores [3][4][5] or the evidence of the influence of the nanostructure and crystal structure of the materials on the pseudo-capacitive behavior. [6][7][8][9] The development of in-situ spectroscopies [10][11][12] and Electrochemical Quartz Crystal Microbalance (EQCM) 13,14 techniques have recently allowed the measurement of ion fluxes through micropores. In addition, the demonstration that ions could access pores of their size in solvent-free electrolytes 1,4 has attracted the attention of the modeling community. Many theoretical and simulation works have then been devoted to the characterization of the porous carbon / electrolyte interface. [15][16][17][18] In particular, using realistic carbon structures (Carbide Derived Carbons with various pore sizes) in molecular dynamics simulations, it was shown that the capacitance increase in carbon nanopore electrodes with ionic liquid electrolytes is linked to the breaking of the multilayer ion structuration of the adsorbed fluid and to the high confinement enabled in the disordered structure of the pores. 19,20 Unlike planar surfaces of carbon graphite, nanoporous carbons cancel out the charge overscreening effect. 21 As a result, carbon atoms forming highly confined sites can store on average a larger charge than carbon at the surface of larger pores. 20 These results demonstrate the great opportunities offered by molecular simulations to complement the knowledge on supercapacitors. However, no quantitative comparison between experiments and simulations could be made so far in the case of nanoporous carbons, mainly because of temperature limitations. Indeed, ionic liquids are very viscous and simulating them at room temperature requires simulation times that would be too large, even using High Performance Computers. Therefore, elevated temperatures (more than 100 • C) are necessary in simulations to enhance the ion mobility and conductivity, thereby decreasing the equilibration time, 22 whereas electrochemical experiments, for practical reasons, are usually performed at temperatures below 100 • C. A more fundamental difficulty that hinders quantitative comparison is the fact that in molecular dynamics, when nanoporous carbon electrodes are simulated, it is difficult to identify the contribution of each electrode to the total capacitance. Here we propose a simulation methodology that overcomes this limitation.

For supercapacitors made with two planar graphene (or graphite) electrodes located at the two extremities the simulation cell (along an arbitrary axis z), already largely studied in literature, 23,24 it is possible to calculate the electrostatic potential along the z direction, taking into account the charge distribution, thanks to the Poisson equation: 25

ψ(z) = ψ q (z 0 ) - 1 ε 0 z z 0 dz ′ z 0 dz ′′ ρ q (z ′′ ) [1]
where z 0 is a reference point inside the left graphite electrode, ψ q (z 0 ) = ψ + and ρ q (z) is the density of charges along the cell, including both electrode atoms and charges on the sites of the ionic liquid molecules. A typical profile is shown on Figure 1. When the Poisson potential reaches a plateau far from the surfaces, the corresponding value provides the potential of the bulk electrolyte ψ bulk . Experimentally, this can be seen as a reference electrode, so that in the following we will note ψ bulk = ψ ref .

In contrast, in a supercapacitor composed of two disordered porous electrodes such as Carbide derived Carbons (CDCs), the electrostatic potential across the cell cannot be computed from Equation 1 due to the lack of symmetry (no translation invariance along the x and y axes) and because of the heterogeneity of the system (there are ions inside the porous electrodes). There is no reference anymore and only the total capacitance can be obtained.

In this work, we introduce a "hybrid" system consisting of one graphite electrode, which allows for the calculation of the potential in the bulk electrolyte, and one CDC electrode that we want to characterize. We can impose either a positive polarization or a negative voltage to this electrode. This original setup therefore allows us to calculate single electrode capacitances from molecular dynamics simulations. Knowing an individual capacitance can then improve our knowledge on the specific interactions between a given counterion and the electrode, and thus reveal the composition of an ideal electrolyte where we would have the most efficient anion and cation pair among all anions and cations tested individually. In parallel of these simulations, electrochemical characterizations (cyclic voltammetry, impedance spectroscopy) of porous CDCs are recorded in 3electrode cells in neat 1-butyl-3-methylimidazolium hexafluorophosphate ([C 4 mim][PF 6 ]) ionic liquid at 100 • C. The two techniques are used at very close temperatures, so that a direct reliable comparison is relevant.

Figure 1. Typical electrostatic potential along the z-axis calculated between two planar surfaces (for example graphite electrodes) separated by an electrolyte. The left electrode is at 1 V, whereas the right electrode is at -1 V, leading to a potential difference of 2 V between electrodes. When the potential reaches a plateau far from the surfaces, the corresponding value provides the potential of the bulk electrolyte ψ bulk , which can be seen as a reference electrode. The potential drops at each electrode ψ + and ψ -are also shown.

Methods

Hybrid supercapacitor simulation cell.-We design a new simulation setup, starting from a previously used simulation cell 19 consisting of the [C 4 mim][PF 6 ] ionic liquid (600 ion pairs) surrounded by two identical and symmetric complex nanoporous carbon electrodes (CDC with an average pore size of 0.9 nm, 3649 carbon atoms for each electrode). This carbon structure was obtained by Palmer et al. using quenched molecular dynamics. 26 The amount of ion pairs is sufficient to ensure that the electrolyte in the center of the simulation cell has the structure of the bulk ionic liquid.

The hybrid system is built by replacing the left electrode of the full CDC supercapacitor by a planar graphitic electrode composed of three graphene sheets, each made of 700 carbon atoms (see Figure 2). Two-dimensional periodic boundary conditions are used, i.e. there is no periodicity in the z direction. The dimensions of the simulation cell are then L x = L y = 4.37 nm, and the size of the cell in the z direction is adjusted to obtain the correct experimental density in the bulk (1.28 g cm -3 at 400 K 27 ), yielding L z = 15.4 nm.

Simulation details.-Following our previous works, 19,25,28 we used for the ionic liquid the coarse-grained model of Roy and Maroncelli, in which 3 and 1 interaction sites respectively describe the cation and the anion. 27 This model has already been validated for structural, thermodynamic and dynamic properties of [C 4 mim][PF 6 ]. The forces are calculated as the sum of Lennard-Jones and Coulombic interactions. In all the simulations, the Coulombic interactions are calculated through a two-dimensional Ewald summation. 29,30 The simulation technique is Molecular Dynamics, which consists in determining the trajectories of the molecules over time by iterative integration of Newton's equation of motion. This was performed in the NVE ensemble with a time step of 2 fs, consistently with the use of a coarse-grained model.

The final hybrid system was equilibrated at a temperature of 400 K with constant null charges on the carbon atoms during 200 ps, then with a 0 V constant potential difference between the two electrodes during 100 ps. This temperature was chosen in order to enable comparison with our previous work. 19 We checked that the system reached equilibrium by verifying that the number of ions inside the porous electrode does not vary anymore (fluctuations of +/-2 ions are observed along the trajectory, consistently with the size of the system). To initiate the charging of the hybrid supercapacitor, based on the results obtained for simulations with two CDC electrodes, 19 we assigned a fix charge of +0.01 e to each carbon atom of the porous electrode, during 100 ps, rescaling the velocities every 50 steps. On the graphite electrode, the charge is distributed only over atoms on the layer close to the bulk since previous constant potential studies showed that 95% of the charge is located in this layer. The number of charged atoms is therefore 5 times smaller than for the CDC electrode, thus a value of -0.05 e was chosen to ensure the overall electroneutrality of the simulation cell. Similarly, when equilibrating for the opposite polarization, CDC carbon atoms bore a charge of -0.01 e and surface graphite atoms a charge of +0.05 e. After this equilibration procedure, we computed the electrostatic potential from Equation 1. The potential difference between the two electrodes was close to 12.5 V. Such a large value is due to the large potential drop between the graphite electrode and the electrolyte, which reaches values for which electrochemical reactions are supposed to occur. These events cannot occur in our classical simulations, so this does not affect the results. In addition we are not interested in the structure at this interface in the present study. The potential drop at the interface between the CDC and the electrolyte is much smaller.

Finally, the electrodes were set to this constant potential difference of ψ 0 = 12.5 V. 29,31 This methodology is essential to observe a realistic behavior of the system. 32 Two simulations were performed where the graphite electrode was either the positive or the negative electrode. All the simulations were performed for sufficiently long times to reach equilibrium, i.e. until the value of the total charge on each electrode became constant. The total simulation time for these production run was 800 ps.

Electrochemical characterizations.-[C 4 mim][PF 6 ] ionic liquid was purchased from Solvionic company (water content ≤ 0.005%, Cl ≤ 0.0001%, Br ≤ 0.0001%), France, and stored in Ar-filled glove box as soon as received. CDC powders (Y-Carbon, USA) with an average pore size of 0.9 nm were prepared by chlorination of TiC powder as reported elsewhere. 2,4 CDC films were made by mixing 95 wt% CDC with 5 wt% polyTetraFluoroEthylene (PTFE, DuPont, France) binder powders, as previously described. 33 Once laminated/calendered, 8 mm diameter electrodes are cut. The active film thickness ranges from 250 to 300 µm depending on the synthesis temperatures of Ti-CDCs, with a weight loading of 15 mg/cm 2 .

Electrochemical characterizations were performed in a threeelectrode configuration, using a multichannel VMP3 potentiostat/galvanostat (Biologic, France). Cells were assembled in a glove box under an argon atmosphere (< 1 ppm of O 2 and H 2 O content). Active films were laminated onto treated aluminum current collectors and two layers of 25 µm-thick porous PTFE were used as separator. 2 A silver wire was used as a pseudo-reference electrode to monitor the negative and positive electrode potentials separately during the cell cycling while controlling the cell voltage.

Cyclic voltammetry (CV) tests were carried out between 0 and 2.7 V, at a scan rate of 5 mV/s. Electrochemical impedance spectroscopy (EIS) measurements were made at various bias potentials (defined from the CVs), using a sinusoidal signal of ±5 mV from 200 kHz to 10 mHz. The density profiles exhibit maxima corresponding to the structuration of the ionic liquid electrolyte at the interface with graphite (the first maximum close to the planar electrode is not shown for practical purpose). The ionic densities are smaller in the gray area because of the excluded volume due to the electrode atoms (see Figure 2).

Results and Discussion

At null voltage, the electrolyte layer, which is either adsorbed at the surface in the case of graphite or inside the pores for CDCs, contains equimolar amounts of cations and anions. When an electrode is charged positively or negatively, it strongly attracts the counterions of the electrolyte, while co-ions are repelled. 19 The cation/anion ratio changes, allowing the charging of the electrode surface to occur. Nevertheless, due to the strong Coulombic interactions inside ionic liquids, the adsorbed layer still contains both species up to very large electrode potentials. In parallel, the counter-ions are able to reach highly confined sites. 20 For a system with two CDC electrodes, the differences in ionic concentrations and thus the charge stored on each of the two electrodes are the same. From this average charge Q tot , the global capacitance of the full capacitor is computed straightforwardly as

C tot = Q tot ψ , [2]
with ψ = ψ +ψ -. The values of C tot obtained previously for the electrolyte [C 4 mim][PF 6 ] were: 19 C graphite = 29 F/g for planar graphitic electrodes, and C CDCs = 87 F/g for nanoporous realistic ones (CDCs obtained by quenched molecular dynamics), in agreement with the very high capacitances of CDCs, compared to other carbon structures. 2 The fact that both electrodes carry the same charge does not imply that they have the same individual capacitance, defined as

C +/-= Qtot ψ ′ with ψ ′ = ψ +/--ψ ref .
Indeed, the potential drop can be different for the two electrodes. Unfortunately, as explained above, for CDCs, ψ ref cannot be determined.

The use of a hybrid supercapacitor allows the calculation of ψ ref and thus to access the single capacitance of a complex CDC electrode. The average ionic densities along the z direction of the simulation cell are shown in Figure 3. Compared to our previous work on graphite, 25 we observe the presence of very large peaks for the adsorbed species. This is due to the very large potential used in the present work. The electrostatic potential is calculated in the z direction for z < z CDC (see Figure 4) only since Equation 1is not valid inside the porous electrode. A value of ψ ref = -12 V is obtained, from which we deduce the voltage difference between the negatively polarized CDC electrode and the reference bulk potential ψ -= ψ -ψ ref = -0.5 V. Our simulations also provide the total charge on the porous carbons, namely Q - tot = -41.5 e. Using the expression (2) of the integral capacitance and normalizing by the mass of the porous electrode, we finally obtain the capacitance of the CDCs under negative polarization: C -= 183 F/g.

In order to get the CDC capacitance under positive polarization, C + , the same steps are carried out, polarizing the electrodes in the opposite direction. A voltage ψ 0 = 12.5 V is applied between the electrodes, leading to a reference bulk potential ψ ref = + 12 V and an average charge on the electrode Q + tot = + 38.5 e. Consequently, ψ + = ψ + -ψ ref = 0.5 V and finally C + = 169 F/g. Figure 5 shows a snapshot of the cell at the end of the production run, showing the ions of the electrolyte in the porosity of the positive and the negative electrodes under polarization. Compared to our previous work, 19 this time we are able to link the number of species inside the electrode to a known value of ψ + ( ψ -).

The capacitances obtained are not identical for the two electrodes, because the species composing the electrolyte are dissymmetrical in size, shape, and charge distribution. To test the reliability of the newly introduced setup, we compute the global capacitance of a conventional supercapacitor with two CDC electrodes, based on the abovedetermined individual capacitances. The classic relation for capacitors in series reads:

1 C tot = 1 C + + 1 C - [3]
with the result C tot = 88F/g, in very good agreement with the value previously obtained in Ref. 19: C tot = 87F/g. This validates the methodology described here to calculate the single capacitance of an electrode using a hybrid system. In order to validate our simulations, electrochemistry experiments were also performed on similar CDC supercapacitors. Figure 6 shows the opposite of the imaginary part of the impedance -Z ′′ (ω) versus the real part Z ′ (ω) of the impedance plot (Nyquist plot) obtained for a 3-electrode cell assembled with two identical microporous CDC electrodes with a pore size of 0.9 nm, in [C 4 mim][PF 6 ] ionic liquid at 100 • C (which is very close to the 400 K temperature at which the simulations were performed), at the open circuit voltage (OCV).

The Nyquist plot corresponds to a typical capacitive behavior based on ion adsorption at porous carbon electrode with a linear trend for both the real and imaginary part of the capacitance in the medium frequency range, followed by a sharp quasi-vertical increase of the imaginary part of the impedance at low frequency. The real value of the impedance at high frequencies (when the imaginary part is null) stands for the series resistance of the cell. The low value of less than 1 Ohm.cm 2 (associated with the high temperature) evidences that the ohmic drop in the electrolyte does not drive the electrochemical behavior of the cell. This is consistent with previous results. 34 The ionic resistance of the electrolyte inside the porous carbon R PORES is about 2 .cm 2 , which is a value similar to that obtained in a conventional organic electrolyte. 35,36 Figure 7 shows the Cyclic Voltammetry (CV) of the same cell using CDC electrodes with a pore size of 0.9 nm in [C 4 mim][PF 6 ] ionic liquid at 100 • C. The cell shows a capacitive signature with a rectangle-shaped CV that is typical of a charge storage mechanism by ion adsorption in the double layer. 1 The positive and negative electrode signatures recorded during the cell cycling are also shown in Figure 7. Both electrodes show as well capacitive signature, indicating that there is no limitation in the pore accessibility for the ions. This is consistent with previous results reported in ionic liquid based electrolytes. 4,37,38 The negative and positive electrode capacitances are calculated by integrating the charge in the plateau region during the CVs, resulting in values of 90 F/g and 75 F/g for the negative and positive electrode respectively.

Although simulations overestimate the overall capacitance by a factor of two, both techniques allow us to conclude that the charging is more efficient in the positive electrode (C + > C -). This result cannot be linked directly to the ionic size of the adsorbed species. Indeed, the anions and cations have respective average Lennard-Jones diameters of 0.5 nm and 0.6 nm, which are both smaller than the average pore size of the simulated CDC (0.9 nm). It is more likely due to a subtle balance between the volume occupied by the ions in the electrode and the strength of their Coulombic interactions. Additional simulations with different cationic/anionic species would be necessary to uncover the microscopic origin of this difference. However, we note that there is a factor two between absolute experimental and simulated values for the single capacitance. Part of the difference can be explained by the fact that experimental systems and simulated ones are studied at different sizes. Indeed, although simulations involve realistic carbons, their size is limited to a few nanometers while experimental samples have a macroscopic size (typically a thickness in the 100 µm range). It is therefore possible that the latter have some inhomogeneities, non-accessible portions, etc. . . , which are not present in the microscopic model.

The remainder of the difference can be explained by the limitations of the model used to describe the electrode, in particular as a perfect electronic conductor. By definition, in a perfect conductor, there is no energy dissipation and the response of the free charges is instantaneous. Luque and Schmickler recently studied the response of an electric double layer close to a graphitic layer to an external field, 39 using DFT calculations. The capacitance of a graphitic layer is around a few µF.cm -2 , that is to say one order of magnitude smaller than the capacitance given by metallic electrodes. Quantitative explanations for this small capacitance on metallic electrodes have been attempted using the semi-conductor theory, but as graphite does not have a finite density of electronic states at the Fermi level, it is not a semi-conductor. Therefore an agreement with experimental data can be obtained only by adjusting some parameters 40 or by adding an arbitrary capacitance. 41 By precise DFT calculations, Luque and Schmickler 39 showed that the small capacitance is due to the small electronic density of graphite close from the Fermi level, the external field penetrating inside the electrode over several tenths of a nanometer. The discordance between theoretical and experimental capacitances of graphene layers has also been explained in Ref. 42: the theoretical capacitances overestimate experimental ones. The explanation given is that the difference is due to large potential fluctuations when the electrolyte enters inside the electrode which are not included in the theoretical model.

Conclusions

In the present molecular dynamics simulations, with a setup established for a singular purpose, we have shown that it is possible to calculate single electrode capacitances in the case of complex nanoporous electrodes supercapacitors. Thanks to experimental electrochemical characterizations in a 3-electrode configuration achieved at an unusually high temperature (100 • C), we were able to validate the simulation approach. Although our model overestimates the single electrode capacitances compared with experiments by a factor of 2, which is due to the perfect metal model used for the electrodes as shown in previous DFT studies, they are in qualitative agreement with experimental data for evaluating the difference in the capacitance between the positive and negative electrodes. The two techniques show that in the case of the [C 4 mim][PF 6 ] electrolyte, the charging is more efficient in the positive electrode, despite the fact that both ions have a diameter quite smaller than the average dimension of the pores. This shows that it is difficult to predict a priori the performance of a given ionic liquid, which will depend strongly on the interionic interactions. Systematic studies of the single ion capacitance should be performed on many other ionic liquids, such as the 1-ethyl-3methylimidazolium bis(trifluoromethane)sulfonimide which is widely used in experiments, for rationalizing their performances by molecular dynamics simulations.

Figure 2 .

 2 Figure 2. Instantaneous snapshot of the simulation cell used in this work (turquoise: C atoms, green: PF 6-anions, red: C 4 mim + cations). The left electrode is made of graphitic planes while the right electrode has the structure of a carbide-derived carbon. The density of the ionic liquid in the middle of the cell is equal to its bulk value.

Figure 3 .

 3 Figure 3. Ionic density profiles when the nanoporous carbon electrode is polarized negatively (left panel) or positively (right panel). Anions are in green and cations center of mass in red. The zones occupied by the electrodes are in light gray.The density profiles exhibit maxima corresponding to the structuration of the ionic liquid electrolyte at the interface with graphite (the first maximum close to the planar electrode is not shown for practical purpose). The ionic densities are smaller in the gray area because of the excluded volume due to the electrode atoms (see Figure2).

Figure 4 .

 4 Figure 4. Poisson potential along the hybrid system for negative (left panel) or positive (right panel) polarization of the nanoporous CDC electrode. The value of ref is read and then + and -can be deduced, knowing the value of the applied potential difference between the electrodes. The zone occupied by the CDC electrode is in light gray. In this zone, the Poisson potential is meaningless because of the lack of symmetry and homogeneity.

Figure 5 .

 5 Figure 5. Nanoporous carbon electrode (in light blue) polarized either at a negative (left panel) or a positive (right panel) potential. The snapshots correspond to the end of the production runs. Anions are colored in green and cations centers of mass in red. The average number of anions and cations inside the electrode are indicated below.

Figure 6 .

 6 Figure 6. Nyquist plot of a supercapacitor cell assembled with two electrodes using 0.9 nm pore size CDC porous carbon, in [C 4 mim][PF 6 ] at 100 • C. Frequency range: from 200 kHz to 10 mHz at OCV ( E = +/-5 mV). Inset: zoom of the high frequency region.

Figure 7 .

 7 Figure 7. Cyclic voltammetry of a supercapacitor cell assembled with two electrodes based on 0.9 nm pore size CDC porous carbon, in [C 4 mim][PF 6 ] ionic liquid at 100 • C. The potential scan rate was 5 mV/s.

Acknowledgments P. S. acknowledge the support from the European Research Council under the European Union's Seventh Framework Programme (FP/2007-2013) / ERC grant Agreement n.102539 (Advanced grant, Ionaces project). C. P. and B. D. were supported by the ERC-Advanced Grant. We are grateful for the computing resources on JADE (CINES, French National HPC) obtained through the project x2014096728


est destinée au dépôt

The impact of the Decree Law 701 on the timber plantations dynamics in the southern Chile observed by remote sensing

Nicolas Maestripieri, Gilles Selleron

To cite this version:

Nicolas Maestripieri, Gilles Selleron. The impact of the Decree Law 701 on the timber plantations dynamics in the southern Chile observed by remote sensing. Dynamiques environnementales et politiques publiques. Quelles interactions?, Laboratoire GEODE, Jun 2013, Toulouse, France. hal-01446734

The impact of the Decree Law 701 on the timber plantations dynamics in the southern Chile observed by remote sensing.

Nicolas Maestripieri, Gilles Selleron Géographie, GEODE-UMR 5602, Université Toulouse le Mirail, 5, Allée Antonio Machado, 31058 Cedex, maestrip@univ-tlse2.fr, selleron@univ-tlse2.fr

A NATIONAL REFORESTATION POLICY TO FACE WITH THE EROSION RISK

A CONTINUOUS DEFORESTATION SINCE THE 19TH CENTURY: ENVIRONMENTAL AND SOCIAL IMPACTS

The capacitation of the lands for agriculture and cattle breeding has been a practice very widespread during the 19 th century and in the first half of the 20 th century and caused, particularly by an intensive exploitation of wheat, a progressive process of soil erosion. Added to that an irrational management of lands and pasture, the whole factors would have caused the erosion of about 19 million hectares, affecting directly the productive capacity of concerned regions.

THE PROMULGATION OF THE GOVERNMENT DECREE 701 (1974)

The first alarming evaluations of the soil state and the erosion in the sixties forces the State to set up a strategy of soil protection favouring the development of monoculture plantations. The arrival of Pinochet to power in 1973, together with the promulgation of the government Decree Law 701 (D.L. 701), marks the beginning of the neoliberal economic phase and the explosion in the forestry sector.

INCENTIVE FOR REFORESTATION BUT IMPOVERISHMENT OF THE VARIETY OF FOREST

This government decree encourages afforestation on land suitability forest, devoid of tree cover and in most cases highly eroded. It permitted to subsidize 75% to 90% of the plantation cost and to exempt tax from the plantations made on these lands ( [START_REF] Monique | Forêts et développement durable au Chili. Indianité Mapuche et mondialisation[END_REF]). This trend monospecifity tree is the source of many environmental disturbances (loss of biodiversity, soil acidification, etc.)

INCREASE OF FOREST HERITAGE BUT GENERATION OF CONFLICTS AT REGIONAL SCALE

For social, economic and technological reason, this incentive has been assimilated by medium and large landowners, and left margins of the profit smallholders. The figure 1 shows the effect caused by the D.L. 701 and its update on the area of exotic plantations between 1995 and 2007.

The compensation was an increase in conflicts on land (expulsions, detentions, murders, arsons, etc.)

MONITORING AND IMPACT OF THE GOVERNMENT DECREE LAW 701 AT LOCAL SCALE

Interactions are multifaceted processes between the legislative framework and environmental dynamics which are captured by remote sensing.

Situated in the north-east Region of lakes (73°47' and 73°18'' -western longitude and 40°14' and 40°44''-southern latitude), the study area is one of the 25 hotspot for conservation and biodiversity [START_REF] Myers | Biodiversity hotspots for conservation priorities[END_REF]. According to the National Institute of Statistics (INE, 2002), more than 89% of the population live in the countryside (7,929 habitants). 62% of this population is represented by native people "mapuche-huilliche".

MONITORING OF THE FORESTRY DYNAMICS USING REMOTE SENSING

Three landsat images have been chosen in 1986, 1999 and 2008. The result of the multi-temporal supervised classifications permits to quantify and to locate the dynamics of land use at the local level. Even if the native forest recedes, it dominates the landscape with 110,775 ha in 1986 (71%), 104,322 ha in 1999 (68%) and 96,857 ha in 2008 (63%). The second growth forests, grasslands, shrublands and bare land (called "other") show an increase of 44% between 1986 and 1999. Timber plantations present the largest increase with 95% covering almost 10,000 ha in 2008.

CHANGE TRAJECTORIES OF LAND COVER TYPES

But the main change observed is the conversion of 12,700 ha from native forest to "other" (12% of deforestation) between 1986 and 1999; whereas, for the same period, timber plantations regained 1,483 ha from native forest (1% of substitution) and 2,329 ha from "other" (5%). Then, from 1999 to 2008, the substitution process is increasing for the last two categories respectively (1,883 ha and 3,803 ha); a phenomenon also observed by Cristian [START_REF] Echeverria | Rapid deforestation and fragmentation of Chilean Temperate Forests[END_REF].

THE IMPACT AND UPDATES OF "THE D.L. 701" ON THE DIFFERENT OWNERS

The initial objective was to promote the creation of a new law which permits the promotion of timber plantations. Therefore, in 1998, the first updating of the government D.L. 701 showed a new reasoning in the plantations'dynamics: the rural smallholders increased their wooded areas with eucalyptus but in a very low ratio, while the land concentration and capitalization intensified in favour of very important owners.

Treatment results of satellite images fully confirm this trend which is continuing in 2008 with the confirmation of the concentration in the hands of large landowners.

The last updating from 1 st January of 2011 encourages, the native communities to afforest their lands.

Figure 1 .

 1 Figure 1. Evolution of exotic plantations (1915-2007) and political and legislative framework


Alberto Blanc

Konstantin Avrachenkov

Sara Alouf

Georg Post

Flow Aware Traffic Management

niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

I. BACKGROUND AND MOTIVATIONS

When the TCP and IP protocols were first proposed the emphasis was on a simple best-effort service. Later on TCP was modified in order to address the issue of congestion control, that is to make sure that the senders would not overwhelm the network by sending data too fast. Over the years these protocols have shown an excellent scalability and have allowed the Internet to grow from a network connecting a few research centers to one that connects a very large number of computers all over the world. In its simplest form, which is still by far the most widely used, TCP congestion control works by using drop tail queues that simply drop packets whenever there is no more space in the router's buffers. TCP senders react to these losses by reducing their sending window and, hence, their rate.

This mechanism, while simple and scalable, has several well known limitations: 1) often different flows experience synchronized losses, leading to lower link utilization [START_REF] Floyd | Random early detection gateways for congestion avoidance[END_REF], 2) when flows with different Round Trip Times (RTT) share the same bottleneck link, the flows with a smaller RTT will receive a larger share of the capacity [START_REF] Brown | Resource sharing of tcp connections with different round trip times[END_REF]. Not only this allocation of capacity is non-optimal in general, but it cannot be modified as long as only drop tail queues and TCP are used. Over the years several solutions have been proposed to address these limitations, especially the first one. Random Early Detection (RED) [START_REF] Floyd | Random early detection gateways for congestion avoidance[END_REF] was the first, and by far the most widely known and implemented; Active Queue Management (AQM) algorithm aims at improving link utilization by desynchronizing packet losses for different flows, albeit without addressing the fairness issue. Furthermore, while RED can indeed improve performances in some cases, this is not always true [START_REF] May | Reasons not to deploy RED[END_REF] and tuning its parameters is non-trivial, hampering its widespread use. Many other AQM algorithms have been proposed (like REM [START_REF] Lapsley | Random early marking: An optimization approach to internet congestion control[END_REF], Blue [START_REF] Feng | The blue active queue management algorithms[END_REF], Stochastic fair blue [START_REF] Feng | Stochastic fair blue: a queue management algorithm for enforcing fairness[END_REF], just to name a few), but, to the best of our knowledge, none of them is capable of addressing both issues while being easy to configure and supporting different fairness criteria.

Another advantage of using AQM algorithms is that routers can use Explicit Congestion Notification, in order to inform a sender that it needs to reduce its sending rate (that is to cut its sending window). This reduces the number of dropped packets and can improve performances as the sender does not need to rely on timeouts and/or duplicate acknowledgments in order to infer congestion.

We propose a new flow-aware traffic management mechanism that aims at addressing the two aforementioned lim-itations of TCP, while being self-configuring and supporting different fairness criteria. Clearly the fairness criteria has to be explicitly selected (configured) by the user; this corresponds to selecting a specific objective, leaving the optimal tuning of parameters to the system. This mechanism is part of Alcatel-Lucent's "Semantic Networking" paradigm [START_REF] Noirie | Self-* features for semantic networking[END_REF]. Given that several studies indicate that 20% of the flows are responsible for 80% of the traffic, and that the overwhelming majority of these are TCP flows, we propose to concentrate on controlling these long-lived TCP flows, often called "elephants." In so doing it is possible to improve the Quality of Service/Quality of Experience offered to short-lived and streaming flows. By controlling each elephant individually it is also possible to better control the service received by each one and prevent flows from harming each other.

II. FLOW-AWARE TRAFFIC MANAGEMENT: OUR SOLUTION AND A SIMPLIFIED IMPLEMENTATION

In order to offer great flexibility in terms of fairness criteria and service offering we propose to control each long-lived flow individually, decoupling it from all the others. The core idea of the proposed mechanism can be described as a two step process:

1) decide a target rate ( λi ) for each flow;

2) control each TCP flow in order to minimize the oscillations around the chosen target rate. The second point can be formally expressed as: min.

1

T ˆT 0 (λ i (t) -λi ) 2 dt, (1)
where λ i (t) is the instantaneous rate of flow i. Our conjecture is that, in order to minimize [START_REF] Brown | Resource sharing of tcp connections with different round trip times[END_REF], and based on a TCP Reno model, it suffices to send a congestion signal (i.e., mark/drop a packet) whenever the instantaneous rate reaches a peak value

k i 3 λi (1 + β) 2(1 + β + β 2 )
,

where β is the coefficient used by the sender to cut its window for each congestion event, that is, if w is the window size, w = βw. This forces the sending rate to oscillate deterministically between βk i and k i , as shown in Figure 1.

As the TCP window grows linearly (it is incremented by one each RTT) it suffices to mark (drop) packets periodically in order to obtain the behavior depicted in Figure 1. This can be easily implemented using packet counters. In order to compute the number of packets in each period one needs to know the RTT of the flow in question, but this can be estimated using the algorithm presented in [START_REF] Carra | Method for estimating a round trip time of a packet flow[END_REF] that can estimate the RTT of a longlived TCP flow on-line and in real-time by observing only oneway traffic. This algorithm can be efficiently implemented on a network processor using only integer arithmetic. Furthermore successive congestion signals are separated by several RTT, so that control decisions are made at a timescale larger (or at least equal) to the RTT.

Similarly to what has been previously suggested (e.g. [START_REF] Kortebi | Minimizing the overhead in implementing flow-aware networking[END_REF]) we propose to concentrate on controlling only long-lived flows as these carry the overwhelming majority of the traffic. It is reasonable to assume that the number of concurrently active long-lived flows is going to be in the order of hundreds which is orders of magnitude smaller than the total number of active flows. This reduces significantly the needed requirements, in terms of memory and computing power. The only function that still needs to be carried out at wire-speed is packet classification, that is to establish, for each incoming packet, if it belongs to a long-lived flow and if yes to which one. But this is doable with modern hardware, for example by using counting Bloom filters to determine if a packet belongs to the set of long lived flows (counting filters have the advantage that they can be updated so that, as flows terminate, they can be removed from the set of long-lived flows).

So far we have illustrated how we plan to address the second step of our control process. We already have a simplified implementation of this step in ns-3: for the moment, instead of taking the target rate as input, for each flow, the implementation takes the number of packets between two successive marks. This has allowed us to verify that periodic marking is indeed enough to force a periodic behavior in the TCP sending window. It can also be used to analyze the effect of non-linearity in the growth of the window when queueing delays are non-negligible. As an example, Figure 2 shows the evolution of the window for two flows when packets are marked periodically.

In order for our solution to be complete we also need to find a way to compute the target rate for each flow. We describe some possible approaches in the next section.

III. FUTURE WORK

Selecting the target rate for each long-lived flow is not a simple task and we can envisage several possible solutions. Trying to achieve max-min fairness is possibly among the simplest ones. This solution has the advantage that it can be determined with local information only, as long as routers can measure the rate of each flow, in order to determine which flows never reach the allotted rate and then allocate the unused bandwidth among the remaining flows. In other words routers can implement the so-called "water-filling" algorithm.

One natural extension is to consider α-fairness [START_REF] Mo | Fair end-to-end window-based congestion control[END_REF] but we conjecture that this cannot be done by using only local information, requiring the use of distributed solutions. This introduces the problem of signaling overhead. Nevertheless, it could be worth exploring this solution as it would offer great flexibility in terms of available fairness criteria. Another possible solution is to consider a centralized server that, based on the state of the network, computes the target rate for each flow. Clearly this solution is not the most attractive one but it does have the advantage of being easy to implement. Finally solutions involving end-hosts are possible, similarly to what is done in XCP [START_REF] Katabi | Congestion control for high bandwidth-delay product networks[END_REF] and RCP [START_REF] Nandita | Rate Control Protocol (RCP): Congestion control to make flows complete quickly[END_REF].

Figure 1 .

 1 Figure 1. Periodic oscillations of the instantaneous sending rate.

Figure 2 .

 2 Figure 2. The evolution of the sending window with periodic marking.

Acknowledgements: This work was done in the framework of the INRIA and Alcatel-Lucent Bell Labs Joint Research Lab on Self-Organized Networks.