ACKNOWLEDGEMENT

In the first place, I would like to thank my supervisors Anne-Cécile Orgerie and Martin Quinson. They taught me the art of research in Computer Science. During my three years of PhD, they were always present to guide and support me. They were able to quickly identify my personality and then adjust their pedagogical skills in accordance. Therefore, for all of these reasons I will always be grateful to them. I am grateful to all the jury members for reading my manuscript and for being part of my PhD defense. In addition, I would like to thank the reviewers for their constructive comments that allow me to greatly improve my manuscript.

I would like to thank all the Myriads team members for hosting me during my PhD. I spent very nice working hours in your company. I also would like to thank The Anh Pham for being part of PhD journey and sharing his joy and Vietnamese culture with me. I would like to thank Ali Jawad Fahs for accompanying me during my PhD and sharing very nice coffee breaks. By the way, thank you for for the towel. I also want to thank Mehdi Belkhiria and Aymen Jlassi for their company and their support. I am grateful to Onesphore Ndayishimiye for all advices and for the nice conversations that we had together. I want you to know that I have a lot of respect for you and for all you have accomplished.

Then, I am also grateful to all the people who give me the opportunity to discover the research during my master thesis, namely Sylvain Bonhommeau, Nour Mohammad Murad and Richard Lorion. They trusted me on a research subject with a pure engineering background and we achieve very nice work together.

How to not think about my family, my first thanks are for my fantastic parents, my father Bruno Guegan and my mother Sylviane Sinacouty. They always encourage me to pursue my studies as far as I can and they always support me as much as they could. I also would like to thank my sister for her support and the nice moments that we spend together. I am also particularly grateful to my grandmother Luciana Sinacouty, she is an amazing woman and even if she is far away, I know that I can rely on her. I also would like to thank my parents-in-law for the very nice moments that we spend together. Finally, I am grateful of my girlfriend Anais Clayton which has always been present with me during my three years of PhD. She encourages me and support me in all the stressful moments.

And last but not least, I would like to thank all the persons that I forgot to mention.

FRENCH SUMMARY

Contexte

L'informatique géo-distribuée (Fog Computing) est un néologisme attribué à la migration des ressources de calcul et de stockage du nuage (Cloud) vers les utilisateurs. L'objectif de cette migration des ressources est de permettre une réduction des temps de réponse et une augmentation de la bande passante des terminaux des utilisateurs. Cela permet donc de traiter l'information proche de l'utilisateur contrairement au nuage. De plus, cela réduit le nombre de communication entre les terminaux et le nuage, contribuant ainsi la réduction de la charge globale du réseau.

En effet, l'évolution des usages de l'Internet contribue à l'augmentation du nombre de terminaux connectés à Internet mais également à l'augmentation du nombre de communication. De plus, cette tendance tend à s'accélérer avec le développement de l'Internet des objets. Ce paradigme consiste à connecter des objets à Internet par le biais de différentes techniques de communication. Le but étant d'étendre les fonctionnalités primaires des objets en les rendant accessibles sur Internet. Parallèlement à cela, la nature même du trafic est elle aussi en constante évolution avec le développement de service tel que le streaming, utilisant d'énorme quantité de bandes passantes. Ainsi, l'informatique géo-distribuée permet de limiter les effets de cette croissance et d'augmenter les performances du réseau Internet.

De plus, cette révolution des usages de l'Internet a un impact majeur sur sa consommation en énergie. De par le fait que la consommation en énergie du réseau est liée à sa taille et à son taux d'usage, nous faisons face à une augmentation significative de la consommation en énergie des réseaux Internet. Ainsi, en 2010, entre 1.1% et 1.5% de l'énergie consommée par l'Homme est dédiée uniquement aux centres de données [1]. De plus, la gestion de l'énergie consommée par la quantité astronomique d'objets connectés à Internet est un sujet complexe [2]. L'informatique géo-distribuée serait en mesure de réduire cette consommation en énergie des réseaux mais des études approfondies doivent être menées en ce sens afin d'en déterminer la proportion. Afin d'étudier l'Internet, les scientifiques le subdivisent en composants élémentaires appelés plateformes. Ces plateformes sont composées d'un ensemble d'ordinateurs reliés entre eux à l'aide de diverses techniques de communication. Ces techniques de communication peuvent être filaires ou sans fil et assurent l'intégrité des données transférées. La communication entre ordinateurs a permis le développement de plusieurs domaines de recherche tels que les technologies de communication, les protocoles de communication, les services en ligne et la consommation d'énergie des réseaux. Ainsi, afin d'étudier les réseaux et faire progresser ces axes de recherche, les scientifiques ont besoin de réaliser des expérimentations sur des plateformes réseaux. Ces expériences peuvent être menées sur des bancs de tests, à savoir des plateformes réseaux dédiées à l'expérimentation. Ce type d'expérimentation a l'avantage de fournir des résultats réels précis.

Cependant les plateformes réseaux réelles sont larges-échelle et cela augmente les difficultés à déployer des bancs de tests. En effet, le déploiement et la configuration des noeuds à largeéchelle est beaucoup plus compliqué et a un coût en temps et en argent. Les communications sont également plus difficiles à monitorer et la nature imprévisible des grandes plateformes réseaux rend la reproductibilité des expériences plus complexe. De plus, ces plateformes réseaux sont souvent interdépendantes et communiquent entre-elles, particulièrement sur les infrastructures de type informatique géo-distribuée. Ainsi, une simple étude du réseau de bout-en-bout requiert l'usage de plusieurs plateformes telles que les objets connectés, l'informatique géo-distribuée, le réseaux des fournisseurs d'accès à Internet et le nuage.

La simulation est un processus expérimental largement utilisé dans la recherche. Elle est également utilisée lors de l'étude des réseaux. Cette technique consiste à utiliser la capacité de calcul des ordinateurs afin de prédire les états futurs d'une plateforme réseau en fonction de conditions initiales. Ces états du réseaux peuvent représenter divers métriques telles que la consommation d'énergie, le temps etc. Les simulateurs réseaux sont composés de différents modèles en charge de prédire les différents états de la plateforme simulée. Comme présenté sur la Figure 1, un simulateur réseau Acronyms requiert deux entrées: une plateforme et un scénario expérimental. Ainsi, le simulateur est en charge d'exécuter le scénario expérimental sur la plateforme réseau en fonction de ces différents modèles et il produit des résultats scientifiques qui peuvent par la suite être étudiés. La précision des résultats d'un simulateur réseau est donc intimement liée à la précision de ces modèles.

Objectifs de recherche et problématique

La simulation offre de nombreux bénéfices en comparaison aux expérimentations réelles. Premièrement, les scientifiques ne sont pas limités par les plateformes physiques car lors de simulations réseaux, elles sont virtuelles. De façon similaire, comme aucune plateforme réelle n'est déployée, les scientifiques économisent du temps, de l'argent et potentiellement de l'énergie. De plus, comme les simulateurs réseaux sont déterministes, les expériences peuvent être reproduites facilitant ainsi les études. Ainsi, les simulateurs réseaux sont une bonne alternative aux expérimentations réelles pour l'étude de l'Internet de bout-en-bout.

Est-il possible d'étudier la consommation d'énergie du réseau de bout-en-bout d'une platforme large-échelle à l'aide de la simulation ?

L'utilisation de la simulation réseau pour l'étude de leur consommation en énergie peut sembler être une idée attrayante. Cependant, les plateformes modernes étant larges-échelle, la simulation réseau pose des problèmes de scalabilité au niveau des performances sur les ordinateurs actuels. En effet, la plupart des simulateurs existants ne sont pas capables de simuler plus d'une centaine de noeuds. En ce qui concerne les simulateurs qui en sont capables, aucun n'est suffisamment versatile afin de simuler le réseau Internet de bout-en-bout. En effet, cela implique d'être en mesure de simuler les objets connectés, l'informatique géo-distribuée, le réseau des fournisseurs d'accès à Internet et le nuage. En conséquent, l'état de l'art actuel en lien avec la simulation réseau, ne fournit pas de solution nécessaire à l'étude de la consommation d'énergie du réseau Internet de bout-en-bout au sein d'un unique simulateur.

Contribution

Ce manuscrit de thèse propose différents modèles de simulation afin de permettre l'étude de la consommation d'énergie des réseaux de bout-en-bout au sein d'un même simulateur. Les contributions de cette thèse sont:

INTRODUCTION

Context

The Fog computing is a neologism employed to describe the migration of Cloud computing resources to the edge of the network. The goal is to alleviate the load of futur network platforms and to reduce the edge devices response time. Indeed, by bringing computing resources to the edge of the network, data can be processed closer to the end user. This can lead to smaller network communications between Fog nodes and the Cloud, fewer computations in the Cloud and lower latencies. Such a Fog infrastructure is required since future network platforms are growing along with network usages.

In fact, the Internet is continuously evolving. A particular aspect of this evolution is related to its size. Getting access to Internet is now easy and the development of online services has lead to a new generation of large-scale networks. Today's networks can now easily reach thousands of nodes [3] and involve many communications [START_REF]Cisco Annual Internet Report[END_REF]. This trend is powered by the arrival of the IoT which consists in connecting physical objects to the network by mean of numerous technologies involving sensors, wireless communications, network protocols, etc. Therefore the data generated by the objects become available on the Internet. However, the tremendous amount of data generated by these objects will lead to a significant increase of network communications and Cloud data processing. Moreover, the nature of the network traffic is also evolving and the development of high bandwidth applications such as streaming has an unprecedented impact on the Internet network load. Consequently, Fog computing was introduced to mitigate all these effects. Still, these changes of the Internet usage has a non negligible impact on the research domain.

The network energy consumption is a major domain which is directly impacted by this network revolution. Indeed, since the network energy consumption is tied to its size and load, we are facing to an increase of the energy consumed by common networks. As an example, about 1.1% to 1.5% of the energy consumed by the entire world is dedicated solely to Data Centers [1] in 2010. Similarly, sustaining the energy consumed by billion of devices from the IoT is a critical challenge [2]. Fog computing may help to reduce this energy consumption [START_REF] Jalali | Fog Computing May Help to Save Energy in Cloud Computing[END_REF] but studies has to be conduct to quantify in which proportion. Consequently, scientists are working on it, striving to reduce the energy consumed by the Internet.

To study the Internet, scientists usually subdivide it into sub components called network platforms. These network platforms are groups of computers or devices called nodes connected together by mean of various communications technologies. These technologies could ether be wired or wireless and they ensure a resilient information transfer between the nodes that satisfy the performance requirements. Making computers and devices communicating together opened the door to many research domains such as network communication technologies, network protocol, network services, and energy consumption. To conduct research in these domains, scientists has to carry out experiments on network platforms. These experiments can be made on testbeds which are dedicated network platforms used as a research environment. This type of experimentation has the advantage to provide real measurements for accurate research.

However, modern platforms are large-scale. This drastically increase the difficulties to conduct experimentations on testbeds. Deploying nodes becomes time consuming and expensive. Communications are more complicated to track and the natural unpredictability of a large testbeds due to its current state make the experimentations hard to reproduce. On top of that, network platforms are often dependent on each other since they are communicating together specially on Fog infrastructures. Thus, a typical end-to-end network will involved the IoT network, the Fog nodes, the Internet Service Provider (ISP) network and the Cloud.

Simulation is an experimental process widely in engineering and research. It is also used to study networks by computer scientists. This technique consists in using the computational power of computers to predict future states of a network given some initial conditions. The network state could be represented by many characteristics such as time, energy consumption etc.

Figure 1.1: Simulation experimental process.

Research problem and goal

Network simulators are composed of several models which are used to predict the final state of the simulated network. As presented on Figure 1.1 a network simulator require two inputs: a network platform and an experimental scenario. Then, the simulator executes the experimental scenario on the network platform according to its network models and produces scientific results which can be analyzed. Thus, the results accuracy of a simulator is entirely dependent of the models' quality.

Research problem and goal

Simulation offers great benefits compare to real world experiments. First, scientists are not limited by the physical platform since simulators use a virtual platform. Similarly, since no real platform is deployed, scientists save time, money and potentially energy. Another great feature of network simulation is reproducibility. Since simulators are deterministic, experimentations can be reproduced multiple time which facilitates the studies. Thereby, network simulations might be a alternative to testbeds to study the energy consumption of the network from endto-end.

Is it possible to study a large-scale end-to-end network energy consumption using network simulations ?

Using simulation to study the energy consumption of large-scale end-to-end network is an appealing idea. Since today's network energy consumption studies require to simulate multiple large-scale platforms, this push current computers hardware to their limits. In fact, most of current network simulators cannot handle more than hundred of nodes. Regarding the scalable ones, to the best of our knowledge, none of them are versatile enough to simulate networks from end-to-end. This involves the edge devices such as IoT, Fog nodes, the Internet Service Provider network and the Cloud. Consequently, in current state of the art related to network simulations, there is no solution available to study the end-to-end network energy consumption with a single network simulator. In this thesis, we propose different simulation models to enable the study of the end-to-end network energy consumption with a single simulator. A representation of the required models are depicted in Figure 1.2. This figure shows that two models are required for predicting the energy consumption of a task. First, a performance model which predict the task duration. Second, an energy model which predicts its energy consumption. Hence, the contributions of this thesis are the following:

Contribution

1. A preliminary end-to-end network energy consumption study using the available experimentation tools, motivating the development of scalable models.

2.

A scalable wired network energy model to study the energy consumed by large-scale platforms.

3. A scalable Wi-Fi network model towards the study of large-scale Wi-Fi network energy consumption.

Organization of the document

The reminder of this thesis in organized as follows. In Chapter 2, we present the state of the art on network simulations. We start by presenting the existing large-scale platforms that we want to study with detailled applications. Then, an analysis of the challenges raised by these 22 large-scale platforms is addressed. Next, we present the different simulation models used to study them. Then, we introduce the existing network simulators that can be used to study these large-scale platforms. In Chapter 3, we present a motivating study on the end-to-end network energy consumption. We highlight the limits of previously available solutions while proposing future directions towards energy efficient low-bandwidth end-to-end applications. In Chapter 4, we propose a scalable wired network energy model that aims at studying large-scale platform network energy consumption. In this work, we are adapting current wired energy model to coarse-grained network simulator to benefit from their scalability property. In Chapter

Overview of Today's Network Platforms

According to the Internet traffic forecasts [START_REF]Cisco Annual Internet Report[END_REF][START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF], the world network load is continuously increasing along with the number of devices connected to the Internet.

These global Internet connection analysis show that the number of device and network communication are increasing about 4% faster than the population size. This trend can be explained by a raise of the number of connected devices mainly driven by machine to machine communications. They are expected to represent half of the total amount of devices connected to the Internet by 2023. These devices, or machines, can be connected together on a common network to form a platform. Consequently, current platforms are getting larger and complex. This section is organized as follow. Section 2.1.1 present an overview of common large scale network platforms to characterize them. Then Section 2.1.2 introduce use cases related to these platforms. Finally, Section 2.1.3 present the several research challenges raised by large-scale and heterogenous platforms.

Major Platforms Taxonomy

From the beginning of the Internet, Information and Telecommunication Technologies (ICT) platforms has been the support of communication and the processing entity of the human generated data. Recent studies have shown a raise of the global Internet traffic with more and more communicating and computing intensive services [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF]. In response, ICT platforms are growing and evolving proportionally to this demand from end-to-end starting from the Cloud up to the end user. In this section we thus propose to characterize these platforms in terms of their distance from the end user and in therms of their hardware heterogeneity.

Starting by the farthest platform from the end user, data centers were first introduced to address the raise of the network services demand. It consists of thousands of servers grouped together to improve computational and data storage capabilities. Data centers are mainly composed of homogeneous hardware with defined standards [START_REF] Chen | The features, hardware, and architectures of data center networks: A survey[END_REF] and that servers are connected together by hundred of network devices. Since data centers are very large platforms, studying them is challenging. This is why, experimental testbeds were developed to solve this issue. As an example Grid'5000 [8] is a large-scale experimentation testbed located in France. Currently, Grid'5000 composed of 35 clusters spread over 8 different sites. Each cluster has its own hardware specification. This type of platform is used for scientific research related to Cloud, High Performance Computing (HPC), etc. Other large-scale experimentation testbeds have also been developed such as Magellan [START_REF] Ramakrishnan | Magellan: experiences from a science cloud[END_REF] and CloudLab [START_REF] Ricci | Scientific Infrastructure for Advancing Cloud Architectures and Applications[END_REF]. These tools simplify the study of these platforms which still difficult to study.

Between far and near platforms lay ISP platforms. ISP connect together the different computers and devices from various regions of the world [START_REF] Winther | WHITE PAPER Tier 1 ISPs: What They Are and Why They Are Important[END_REF]. ISP platforms are mainly composed network devices such as routers and switches. The different ISP are organized in tiers architecture. Tier 1 ISP form the backbone and are in charge of connecting a given country to remote continents. Tier 2 and tier 3 have smaller network infrastructures and are usually connected to tier 1 ISP. Thus, ISP are very large networks owned by several parties which contains heterogeneous hardware such as routers, switches and servers. Consequently, studying such a large and heterogeneous platform is difficult.

While data centers and ISP networks are large-scale platforms separated from the end user, IoT is expected to directly impact him. In fact, IoT aims at sending or receiving data from objects by mean of sensors and making them available on the Internet. We can expect billions of devices connected to the Internet by the end of 2022 [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF]. Thus, IoT platforms fall in the category of the near user platforms. Since they are in charge of sensing and interacting with the environment they are part of what is called the perception layer of Internet [START_REF] Al-Fuqaha | Internet of Things: A Survey on Enabling Technologies, Protocols, and Applications[END_REF]. The technology used by the connected objects are highly dependent on the use case and, IoT platforms are thus considered as one of the most heterogeneous network platform. A perfect illustration of such heterogeneity is the FIT IoT-Lab testbed [3] which comprise thousand of IoT devices deploy on 6 different sites in France for research purpose. Despite this heterogeneity, IoT devices could be categorize as either a sensors or an actuator. First, sensor nodes are used as data sources to monitor physical phenomenons. The generated data will usually go to an aggregator node in charge of offloading the data and makes it available on the Internet. Second, the actuators are another type of connected object with the capability of being controlled by incoming network requests. Since data can now be generated by objects, IoT supply a new form of network communication called Machine-to-Machine (M2M). While most of the network communications where driven by humans, 31% of future communications will expect to be between machines [START_REF]Cisco Annual Internet Report[END_REF] by 2022. To handle this emerging traffic, a new paradigm called Fog Computing has been created. Its goal is to gather data from the connected objects closer to the end user by deploying geo-distributed devices at the edge of the network [START_REF] Mukherjee | Survey of Fog Computing: Fundamental, Network Applications, and Research Challenges[END_REF]. To this end, data can be processed and filtered from the edge of the network and thus reducing the overall Internet traffic and delay for low latency applications. Similarly to IoT, Fog Computing platforms are near the user and are characterized by heterogeneous devices. Thus IoT and Fog computing introduce many heterogenous nodes to the existing network. This further reinforces the difficulties of experimental studies.

Large-Scale Platform Based Applications

This section presents several non exhaustive use cases that can be impacted by the research on large-scale network platforms along with the difficulties that they raise.

With the explosion of streaming services more than half of the overall downstream traffic is related to video streaming [14]. As an example, Netflix is a popular video streaming provider. A single Netflix server is able to send around 30TB of data at 3Gbps (in average) per day [START_REF] Summers | Characterizing the workload of a netflix streaming video server[END_REF]. To answer to this network resource crisis, video steaming providers heavily rely on data centers and more specially on CDN. It consists in several computers spread over the world and connected together to distribute specific content closer to the end user. This allow to reduce latency and improve the bandwidth. CDN are large-scale platforms and cover very large geographical area such as the Akamai CDN [START_REF] Akamai | Akamai facts and figures[END_REF][START_REF] Nygren | The Akamai network: a platform for highperformance internet applications[END_REF] which comprise around 300 thousands servers spread over 136 countries. Netflix relies on CDN to place and replicate its video content. Its catalogs contains petabytes of data. It is therefore impossible to synchronize the complete catalog over the entire world, for network performance and data storage reasons. To this end, during off-peak hours, Netflix strives to predict which title is more likely to be used on a given region. In this way, only sub-parts of the catalog is present at a given location and network traffic is reduced. But other strategies are also implemented by Netflix to limit its impact on the network. Indeed, Netflix CDN called Open Connect, provides its own type of servers located at strategical points over the world as depicted on Figure 2.2. These servers can be present inside ISP to reduce the load but also between ISP on points called Internet eXchange Point (IXP). Other data placement strategies are also considered in research, such as moving data cache to the edge of the network can be envisioned [START_REF] Banerjee | Sharing Content at the Edge of the Network Using Game Theoretic Centrality[END_REF]. This modern use case shows that current network usage implies high bandwidth applications with many nodes connected to a common network. This tendency to make the end user more and more connected along with its environment is the essence of Smart Building and Smart Home. In current Smart Home, smart speakers are common connected objects. As a matter of fact, Google claims that it is selling 1 Smart Speaker every seconds [START_REF] Bentley | Understanding the Long-Term Use of Smart Speaker Assistants[END_REF]. Smart Speakers are voice-based virtual assistants which allow the user to retrieve informations or manipulating actuators [START_REF] Caputo | Are you (Google) Home? Detecting Users' Presence through Traffic Analysis of Smart Speakers[END_REF]. Their network platform are composed of three components: 1) The Smart Speaker 2) The actuators (IoT devices) 3) The Cloud. The Smart Speaker is in charge of collecting the vocal commands and it is connected to the Internet usually via 802.11 (Wi-Fi). Then, the commands are sent to the Cloud and processed by the service provider' servers. Thanks to this architecture, the Smart Speaker can benefits from many services available on the Internet. Most of connected objects rely on this architecture and numerous of them are available on the market. Smart Bulbs [START_REF] Dikel | Evaluating the standby power consumption of smart LED bulbs[END_REF] actuators which allow the user to switch on and off the light from anywhere in the world. In the same domain Smart Plugs allow to monitors and control the energy consumption of home devices. This constitutes a very promising solution to energy efficiency [START_REF] Suryadevara | Smart Plugs: Paradigms and Applications in the Smart City-and-Smart Grid[END_REF] and research in this domain proposed interesting feature: Device Identification, Voltage Control, Thermal and Overload Protection, etc. Other energy saving solutions such as Google Nest Thermostat [START_REF]Google Nest Thermosta Datasheet[END_REF] allow to regulate the home temperature using several sensors which comprises temperature sensors and ambient light or near field activity sensors. Since it is meant to be autonomous, it sends data periodically to a distant server in contrary to Smart Speaker. Thus, the network footprint for a given connected object seems to be highly dependent of its use case [START_REF] Sivanathan | Characterizing and classifying IoT traffic in smart cities and campuses[END_REF][START_REF] Borges | Survey on the Characterization and Classification of Wireless Sensor Network Applications[END_REF] and varying from sporadic to high bandwidth streaming communications. These use cases demonstrate that a common usage of IoT involve different platforms such as Cloud or ISP network. Thus, it is difficult to study them separately since their are closely interacting together.

In addition, the IoT paradigm is also the building block of the concept of Smart Cities where this ecosystem of connected objects allow for improving citizen life comfort. As an example, Smart Grid [START_REF] Kabalci | A survey on smart metering and smart grid communication[END_REF] has promising impact on reducing the energy consumption. In fact, Smart Grid is adding a network layer above the actual electrical grid. It allows for fine grain energy consumption monitoring. Consequently, it improves the forecasting abilities of energy providers. Moreover, this communication layer makes the grid more resilient by improving issues detection and prevention. In addition to Smart Grid, Wireless Sensors Networks (WSNs) [START_REF] Kouche | Towards a wireless sensor network platform for the Internet of Things: Sprouts WSN platform[END_REF] will play an important role in Smart Cities at sensing the environment. It consists in deploying numerous of nodes working in harmony with the aim of sensing physical phenomenons. Hence, the analysis power resulting from the combination of hundred of devices make them suitable for many applications involving large field coverage. For instance, air pollution monitoring [START_REF] Fioccola | Polluino: An Efficient Cloud-based Management of IoT Devices for Air Quality Monitoring[END_REF][START_REF] Pavani | Real time pollution monitoring using Wireless Sensor Networks[END_REF] based on WSN allows wide-range air quality monitoring. Sensors placed on the nodes are in charge of collecting the air quality data and sending them to a database. Thanks to the diversity of the measurements and their location, the air quality can be analyzed more precisely. Moreover, WSN are not limited to Environmental Monitoring. Thanks to there versatility, WSN can be applied to various domains [START_REF] Kandris | Applications of Wireless Sensor Networks: An Up-to-Date Survey[END_REF] such as: military (battlefield surveillance, combat monitoring, intruder detection), health care (motion sensors, position sensors), urban (transportation, acoustic monitoring), industrial (corrosion, heat, vibration and position sensors). WSN contains numerous nodes which are targeting energy efficiency. Thus, WSN mainly rely on low power wireless communications. Consequently, we expect that the deployment of Smart Cities such as the SmartSantander testbed [START_REF] Sanchez | SmartSantander: IoT experimentation over a smart city testbed[END_REF] will lead to a new generation of dense platforms composed heterogeneous nodes based on various communication technologies.

Large-scale platforms are involved in many domain of applications in which we can extract 3 critical properties. First, they can involve high bandwidth application. Second, they can be closely linked since they can communicating together from end-to-end. Finally, these platforms can be very large and dense. This reinforce the difficulties to study these networks and raise new research challenges which will be addressed in the next section.

Challenges

In the last section, we have seen that large-scale platforms offer great solutions for a variety of applications. Nonetheless, they raise a lot of challenges in many different area of research: security, wireless technology, network protocols, energy consumption, etc. In this section, we will skim over some of these areas to provide a general view of the research challenges raised by these platforms.

In ICT, security is based on three principles namely Confidentiality, Integrity and Availability also known as the CIA triad. As details previously, connecting hundred of nodes close to the end user has several benefits in terms of delivered services. Still, such a node deployment has an impact on the security and affects the following layers of the IoT architecture [START_REF] Frustaci | Evaluating Critical Security Issues of the IoT World: Present and Future Challenges[END_REF]: 1) Perception layer (nodes themselves) 2) Transportation layer (network between the nodes and the data recipients) 3) Application layer (customers service provider). First, the perception layer is the most vulnerable point since the nodes and the network it belongs is potentially accessible by the attacker. Indeed, nodes can be damaged, malicious code can be injected and data can be stolen or corrupted. In addition, current IoT networks suffer from identification problems. Thus, they can be targeted by spoofing attacks (impersonation) where malicious nodes behave such as a normal node as part of the network. Next, transportation layer is vulnerable to integrity and confidentiality attacks and also to more esoteric attacks such as routing attacks where malicious nodes are able to modify the routing path of the data being transferred. Finally, the application layer can be subject classical ICT attacks such as Denial Of Service (DoS) or data leakage.

But IoT security problems are also driven by the lack of standardization. As a matter of fact, the development of IoT cover a very large research area involving tremendous technologies as depicted on Figure 2.3. On the network layer of the TCP/IP model, nodes can communicate in various way involving different type of technologies: Low Power Wide Area Network (LPWAN), Wireless Body Area Network (WBAN), Low Rate Wireless Personal Area Network (LR-WPAN), etc. In addition, the Internet layer uses addressing and routing mechanisms whereas the application layer includes complex end-to-end protocols. This diversity prevents interoperability between IoT platforms [START_REF] Aftab | Analysis of identifiers on IoT platforms[END_REF][START_REF] Liu | Efficient naming, addressing and profile services in Internet-of-Things sensory environments[END_REF]. Indeed, since there is no standard way to identify and communicate with different IoT platforms, we cannot rely on profiling to make these platforms available on the application side. Consequently, applications are often tied to a specific type of IoT platform.

Connecting numerous of nodes together imply to deal with scalability issues [START_REF] Gupta | Scalability in Internet of Things: Features, Techniques and Research Challenges[END_REF]. Starting from the deployment, nodes should be easy to setup and configuring each node individually is not an option. Thus, automated bootstrapping solutions which can involve network communications [START_REF] Garcia-Carrillo | Lightweight CoAP-Based Bootstrapping Service for the Internet of Things[END_REF] should be provided to configure the IoT platform automatically. On the network level, communication technologies used in the platform should be able to handle massive concurrent medium access while maintaining good performance. With this aims, Wi-Fi 802.11ax was developed to achieve better performance in dense scenario [START_REF] Khorov | A Tutorial on IEEE 802.11ax High Efficiency WLANs[END_REF] especially with the adoption of Orthogonal Frequency-Division Multiple Access (OFDMA). Apart from the edge side, the large amount of data generated by these new devices also impact Cloud environment. Current databases technologies has to deal with query on massive data [START_REF] Phan | Cloud Databases for Internet-of-Things Data[END_REF] and servers should maintain sufficient computational performance to ensure good Quality of Service (QoS) [START_REF] Dhirani | Can IoT escape Cloud QoS and Cost Pitfalls[END_REF]. Consequently, all these scalability issues should be addressed by researchers. However, con- ducting such experimentations requires to deploy numerous node which is expensive and time consumming. Similarly, as detailed in Section 2.1.2, a common network architecture involves connecting IoT devices to the Cloud which leads to even more complexity.

Another big challenge encountered on large-scale platforms is the energy consumption. As an example, the energy consumed by data centers in the United States represent 1.8% of the total amount of energy consumed by the country [START_REF] Shehabi | United States data center energy usage report[END_REF]. Since data centers contain thousands of ICT devices they require dedicated cooling systems which generate additional energy cost. Thus, as depicted on Figure 2.4 the energy consumed by the ICT devices represents around 50% of the total data center energy consumption. Hence, reducing the energy consumed by the cooling systems is espected to provides more energy efficient data centers. To measure this efficiency, a metric called the Power Usage Effective (PUE) has been introduced [START_REF] Grid | The Green Grid Data Center Power Efficiency Metrics: PUE and DCiE[END_REF]:

PUE = E DataCenter E ICT with PUE ∈ [1, +∞[
Besides cooling systems, servers are the next energy-hungry components. To improve their energy efficiency, multiple solutions as been proposed [START_REF] Shuja | Survey of Techniques and Architectures for Designing Energy-Efficient Data Centers[END_REF]. First, servers can use better computer architecture. In fact, it has been demonstrated that the Reduced Instruction Set Computer (RISC) architecture consumes 3 to 4 times less energy compare to the common Complex In-Figure 2.4: Data center energy consumption repartition according to an air conditioning study [START_REF] Ni | A review of air conditioning energy performance in data centers[END_REF].

struction Set Computer (CISC) architecture [START_REF] Aroca | Towards green data centers: A comparison of x86 and ARM architectures power efficiency[END_REF]. Next, techniques based on Dynamic Voltage and Frequency Scaling (DVFS) allows to regulate CPU frequency to better control their energy consumption [START_REF] Laszewski | Power-aware scheduling of virtual machines in DVFS-enabled clusters[END_REF][START_REF] Samual | Analysis of DVFS Technique for Efficient -Energy Management in Cloud Data Center[END_REF][START_REF] Krzywda | Powerperformance tradeoffs in data center servers: DVFS, CPU pinning, horizontal, and vertical scaling[END_REF]. Other works introduce Power Capping which allows to define power consumption limits on servers [START_REF] Al-Hazemi | Minimizing Data Center Uninterruptable Power Supply Overload by Server Power Capping[END_REF]. Finally, research on turning off servers are also conducted [START_REF] Ranjbari | A learning automata-based algorithm for energy and SLA efficient consolidation of virtual machines in cloud data centers[END_REF]. Thus, data center energy saving cover several research domain and conducting real experiments require access to dedicated testbeds.

Regarding IoT platforms for power constraint applications, hardware energy consumption is often related to communication [START_REF] Yick | Wireless sensor network survey[END_REF]. Indeed, various phenomenons can modify the communications' energy consumption [START_REF] Haimour | Energy Efficient Sleep/Wake-up Techniques for IOT: A survey[END_REF] such as: Radio transmission and reception, collisions, overhearing (receiving packets while being the wrong recipient), control packet overhead, idle listening, over-emitting. Thus, many wireless technologies is dealing with the trade-off energy/performance and strive to offer the best of both optimization axes. Energy harvesting [START_REF] Garg | Energy harvesting in IoT devices: A survey[END_REF] is also a good solution to extend battery life and implement autonomous nodes. Energy can be extracted from various (and sometimes surprising) sources: solar energy, radio frequencies, wind, motions, temperature or even breathing. Nonetheless, focusing only on hardware energy consumption is not the right way to go. In fact, up to 80% of the hardware energy consumption can be driven by the software [2]. But achieving software energy efficiency is really challenging since various layer of abstraction has been added between the software and the hardware to simplify softwares development [START_REF] Georgiou | Energy Transparency for Deeply Embedded Programs[END_REF]. For example, software energy profiling solutions should be able to deal with multi-threading which is highly tied to hardware. Additionally, source code compilers may generate different binary depending on its version. Thus, the same application can have a totally different impact on performance and energy consumption according to the compiler in use.

Still, different methods exist to obtains software energy footprint. For example, code instrumentation allows to extract execution traces at runtime and hardware Performance Measuring Counters (PMC) [2] allows for performance measurements. Other measurement techniques exist such as wattmeters [START_REF] Hackenberg | Quantifying power consumption variations of HPC systems using SPEC MPI benchmarks[END_REF] but it relies on dedicated platform. Moreover, all these solutions are difficult to employ for large-scale platform studies. It requires to monitor multiple nodes at runtime and implies hundred of network communications.

Today's and future large-scale platforms introduce a lot of challenges in the research domain. The energy consumption account for major part and are tied to all the large-scale platforms. But conducting real experiments becomes more and more difficult since it involves many nodes and technologies. Additionally, these large-scale platforms are often interracting with each other from end-to-end. This call for a convenient experimentation solution to study large-scale networks energy consumption from end-to-end.

Simulation Models

Modern network platforms are very large and consume a lot of energy. They raise many research challenges and are difficult to study by mean of real experimentations. As stated in the Introduction, network simulation is a great alternative to real experimentation. They allow for time, money and energy saving specifically on large-scale platforms. These large-scale platforms are often interacting together to form the end-to-end network which comprise the IoT, the Fog, ISP and the Cloud. Hence, studying them together is very convenient from the research point of view but it is even more challenging. Thus, our goal is to propose a scalable simulation solution to study the end-to-end network energy consumption with the aims of reducing its environmental impact. This goal implies to be able to predict the time and the energy consumption of three physical tasks namely the CPU computations, the wired communications and the wireless communications. Both time and energy models are closely related. Energy models are based on their counterpart time prediction models (or performance models). This close relation between energy and time prediction is explained by the following formula:

E(T ) = T 0 P (t)dt (2.1)
In this section, we focus on the state of the art of the models which are involved in the contributions of this thesis: the wired performance model, the wired energy model and the Wi-Fi performance model. This stack of models are summarized on Figure 1.2. We now detail how these models work in network simulators with the aim of providing the required background.

Wired Performance Models

The primary goal of a network simulator is to predict network communication durations with potentially multiple computers. At the beginning of the Internet, most of the communications where wired and current platforms which require high bandwidth and low latencies connections are still using wired connection such as data centers and ISP networks. Consequently, the majority of network simulators usually propose a wired performance model.

A network link can be modeled by two properties. The first one is called latency. It represents the delay from end-to-end on the wire. The second metric is the bandwidth. It represents the amount of information that the link is able to carry for a given duration. Considering a single network communication between two hosts to transmit N bytes of data on a wire with a latency L (in seconds) and a bandwidth BW (in bit per seconds). We can deduce the communication duration T with the following formula:

T = L + N × 8 BW (2.2)
Thus, knowing the link characteristics, the next step is to deduce the data size N . This data size depends on the protocol stack used by the transmitting machine. Considering a simple Transmission Control Protocol (TCP) socket communication, one possible protocol stack is proposed on Figure 2.5. Note that, this network stack was chosen because it is massively used by today's wired platforms and it is commonly present in networks simulators. The data link and physical layer are implementing the Ethernet features which allow for communications over the wire. These features include the Ethernet protocol and the physical signal properties. The network layer implements the IPv4 protocol in charge of identifying the machine on the network. Finally, the transport layer implements the TCP protocol in charge of connection management and flow control. Thus, knowing this protocol stack and the payload P that we want to transmit, network simulators are able to compute the effective amount of transmitted bytes over the wire. Since the payload P pass through each layer of the stack before being sent over the wire, N can be computed by summing P with the overhead induced by each layer of the stack.

Once we can estimate communication's duration, the next step is to provide bandwidth sharing mechanism. This allows to simulate scenarios with multiple machines that communicate over the same wire. On real networks, this task is handled by the current TCP protocol implementation and the different network devices between the sender and the receiver [START_REF] Abbas | Fairness-Driven Queue Management: A Survey and Taxonomy[END_REF]. Regarding TCP, the protocol strives to provide fairness among the communications. Its implementation contains a congestion control mechanism in charge of using the right amount of bandwidth according to the network conditions. This algorithm comes with several flavors such as: Tahoe, Reno, New Reno, Westwood, Vega, BIC or CUBIC (the most common one on recent Linux operating systems) and many others. Consequently, the fairness index [START_REF] Rajendra | A Quantitative Measure of Fairness and Discrimination for Resource Allocation in Shared Computer Systems[END_REF] of each implementation is different. To solve this issue, network simulators can choose to implement a full TCP version (or several) to model its sharing impact over the network. Nonetheless, some network simulators have the strong assumption that on a given link, TCP is perfectly fair [START_REF] Giuli | Narses: A Scalable Flow-Based Network Simulator[END_REF][START_REF] Casanova | Versatile, scalable, and accurate simulation of distributed applications and platforms[END_REF]. This assumption provides multiple benefits such as a reduced complexity and performance improvements. Still, each network protocol converges toward a specific fairness equilibrium. Modeling other protocols such as User Datagram Protocol (UDP) thus requires a careful study of their behavior [START_REF] Abbas | Fairness-Driven Queue Management: A Survey and Taxonomy[END_REF].

Wired Network Energy Model

This section introduces wired network energy model based on the time predictions presented in previous section. Indeed, communicating through a wire require energy which depends on several factors. Let's first introduce how ICT devices are consuming energy.

Generally, an ICT device (CPU, router, switch, etc.) is not subject to a constant load. As an example, CPU usage may vary over time. This variation of load has an impact on the power consumption. Thus, an ideal ICT device should not consume any nergy when no load is applied to it, and should consume its peak power when working at maximum performance. This would be the ideal model. Nevertheless, in reality any ICT device consumes energy even when it is idle. Thus the energy consumption of ICT devices can be decomposed in two parts:

• Static: Power consumed by the device when it is idle (noted P static )

• Dynamic: Additional power consumed while the device is under load (noted P dyn ) Depending on the considered device, the static part of the energy consumption might turns out to be significant. As an example, a server can consume more than half of its full power when idleing [START_REF] Barroso | The Case for Energy-Proportional Computing[END_REF]. On the other hand, the dynamic energy consumption is often considered to be proportional to the load of the device (noted S load ) in many models, and thus P dyn ∝ S load . But this is not true on real devices. For example, CPU power levels are discrete and thus, a better approximation P dyn for such a system must be discrete. More formally, considering a system with n power levels. Let's define p 1 , ..., p n the dynamic power generated by each power level associated with their respective load intervals {I 1 , ..., I n }. In reality, the total power of the system P total is express as follow:

P total (S load ) = P static + n k=1 p k × Indicator Function 1 I k (S load ) Dynamic Power
The ideal, proportional and real model are represented on Figure 2.6.

A similar approach can be followed regarding network devices. First, P idle corresponds to the power consumed by the network device while no communications occur on the wire. However, P dyn varies from device to device depending on the number of port and their respective performance. Hence, we usually employ the term "port power consumption" in reference to the dynamic power of a network device. The dynamic energy consumption of a network device can be decomposed in several parts: Thus, considering a network device with a packet processing rate R p and n ports, each of them working at an effective byte processing rate of R b k . The entire device power consumption can be written as follows:

P netdev = P static + packet R p (E prx + E ptx ) + ports n k=1 +R b k (E brx k + E btx k ) dynamic (2.3)
Note that each port has its own byte energy consumption. This is due to the fact that each port can have different characteristics (100Mbps, 1Gbps, 10Gbps, etc.) and consequently different energy consumption values. These energy values are difficult to measure. It requires specific hardware and high precision measurements tools [START_REF] Sivaraman | Profiling per-packet and perbyte energy consumption in the NetFPGA Gigabit router[END_REF][START_REF] Mahadevan | A Power Benchmarking Framework for Network Devices[END_REF]. That is why, using energy measurements from the literature along with network simulations provides and efficient solution to study the energy consumption of network devices.

Wi-Fi Performance Model

Wi-Fi is a common wireless technology used mainly at the edge of the network. Simulating Wi-Fi communications at fine-grain requires to account for the Wi-Fi Medium Access Control (MAC) layer, the physical layer and the communication channel. In this section, we present the Wi-Fi MAC layer based on 802.11n standard [START_REF]telecommunications and information exchange between systems : local and metropolitan area networks-specific requirements. Part 11, Part 11[END_REF] since its features are implemented by most simulators and available on today's implementations. It is followed by a brief introduction to communication channel models used in common network simulators.

Wi-Fi MAC Layer

The Wi-Fi MAC layer has two operating modes: Ad-Hoc and Infrastructure. Figure 2.7 presents these two operating modes. In this thesis, we focus essentially on the Infrastructure mode, that happens to be the most commonly used mode. In this mode, Stations (STAs) are connected to an Access Point (AP). The STAs use the AP as a gateway to the Internet and to the other stations.

According to the IEEE 802.11 Specification [START_REF]telecommunications and information exchange between systems : local and metropolitan area networks-specific requirements. Part 11, Part 11[END_REF], the MAC layer of the 802.11 standard is using a Distributed Coordination Function (DCF) based on Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to access to the medium. In the context of Wi-Fi in Infrastructure mode, this medium access mechanism provides a way for the stations to initiate a communication to the access point. To transmit a packet, a given station first has to sense the channel before transmitting and for a given period of time called Distributed InterFrame Space (DIFS). If the channel is sensed idle during a time DIFS (Carrier Sense), then the station can send its packet to the access point. However, if the channel is sensed busy (Collision Avoidance) then the station wait for a random time called backoff time before attempting for another transmission. The backoff time is increasing exponentially according to the number of transmission failure and decrease in a similar fashion. Next, to ensure that a successful packet transmission, the access point sends an acknowledgment (ACK) to the station after a Short InterFrame Space (SIFS). It is important to note than T DIF S > T SIF S + T ACK Propagation Delay . In this way, data can be transmitted during a DIFS without impacting the performance since the stations are able to sense the channel idle even during the transmission of the ACK. Then, to ensure fairness among the stations, after a successful transmission a station has to wait for a random backoff time to avoid channel capture.

Besides basic wireless medium access, CSMA/CA reveals some drawbacks when it comes to interferences. The first problem is known as the hidden node problem, and the second as the exposed node problem (Figure 2.8). The former arises when two STAs are trying to communicate with the same AP while being mutually out of range. Thus, each station cannot sense the channel idle. Consequently, they start their transmission and their respective signal interfere on the AP resulting in communication failures. The latter problem occurs when two stations in their respective cell are interfering with each other. Thus, each of them could sense the channel busy even if their respective AP could perfectly receive the signal. To solve these issues, an optional handshaking mechanism based on Request To Send (RTS) and Clear To Send (RTS) messages can be trigger by the DCF. Thus, if a station do not received CTS response from its destination, it can deduce that the receiver can face to interferences (hidden node) and delay its transmission. On the other hand, if a station receive a RTS from its neighboring nodes and do not receive their corresponding CTS, it can infer that it is an exposed node. In this way, RTS/CTS mechanism help to achieve higher throughput, particularly on dense scenarios. As an example, a communication between a STA and an AP based on RTS/CTS is depicted on Figure 2.9.

Wi-Fi Physical Layer

Simulating Wi-Fi involves numerous physical parameters. Regardless of the communication channel profile, Wi-Fi communication performance are determined by 5 parameters: 1) Modulation 2) Bandwidth 3) Coding Rate (CR) 4) Number of Spacial Stream 5) Guard Interval size (GI) (NSS). A specific combination of the first 4 parameters is known as a MCS. Each MCS has its own index which can be used to refer to a specific physical configuration. Lets first introduce the meaning of these five parameters.

1)

A single Wi-Fi data sub-carrier is using phase and amplitude modulation to carry the data. Modulations range from pure phase modulations such as Binary Phase-Shift Keying (BPSK) or Quadrature Phase-Shift Keying (QPSK) up to 64 Quadrature Amplitude Modulation (QAM). Each of these modulation produces a constellation diagram as shown on Figure 2.10. This figure shows that higher granularity modulation will improve performance (higher symbol rate) but at the same time reduce the EVM box size. Thus, the signal will get more subject to error on poor channel conditions.

2) The bandwidth of a signal determines the frequency spectrum range of that signal. Wi-Fi is using Orthogonal Frequency-Division Multiplexing (OFDM) which makes the performance very sensitive to the bandwidth. Indeed, OFDM allows to send multiple signals in parallel. This is possible as long as the signals are orthogonal to each other which allows to separate them on the receiver side. To this end, doubling the Wi-Fi bandwidth allows to use two times more data sub-carrier and thus double the throughput. The 802.11n standard is using 20MHz channels and comes with a feature called channel bonding which allows to combine two 20MHz channels and reach the performance of a 40MHz channel.

3) The coding rate account for the proportion of useful data that is actually transferred during a communication. As an example, a communication with a CR = 7 8 sends 8 bits to transfer 7 useful bits of data. This additional data sent, add error correction bits to the data. It improves thus the communication resilience and ensure data correctness.

4)

Most of Wi-Fi standards offer Multiple Input Multiple Output (MIMO) communications. This feature allows to send multiple signal at the same time on different antennas. This technique called spacial multiplexing exploits the receiver signal diversity (several antennas) to separate the interfering signals. Thus, a Wi-Fi communication with a NSS of 2 is going to be twice as efficient as a one with a NSS of 1 which improves the spectral efficiency.

5)

Adding Guard Intervals to a signal reduces its probability to be corrupted by another one. In the case of OFDM, a GI is added before each symbol that is transmitted. To this end, as long as an interfering signal fall into this interval, the data will still be unaffected by the interferences. Thus, increasing the GI improves the signal resilience but reduce the overall throughput (lower spectral efficiency).

Wi-Fi Communication Channel

During Wi-Fi communications, the signal get affected by the wireless channel which can lead to a significant variation of performance. Thus, communication channel models allow to account for these variations. The communication channel models are composed of a propagation delay model, a propagation loss model, an error rate model and an interference model. The propagation delay model is usually based on the light speed in vacuum c = 2.99e8ms -1 . The propagation loss model account for the signal power loss during its propagation. It can be based on the Friiz propagation loss model for line of sight communications or log distance model for indoor scenarios. The error rate model takes into account the modulation resilience to the thermal (such as the Johnson-Nyquist model [START_REF] Budi | Thermal Noise as Electromagnetic Polutan in Wireless Communication System[END_REF]) and background noise. Finally, the interference model account for wireless communications that occur concurrently. They are based on a simple additive power model [START_REF] Fuxjaeger | Validation of the NS-3 Interference Model for IEEE802.11 Networks[END_REF].

Estimating the end-to-end network energy consumption requires to combine multiple models which comprise performance and energy models. Performance models predict the tasks' durations such as wired and wireless communications. These models are based on low-level properties of the network such as packets, medium access protocols and physical channel properties. On the other hand, energy models predict the energy consumed by these tasks. They are based on their counterpart performance model. Estimating the energy consumed by wired communications involved low-level properties such as packet and byte energy consumption. Since the performance and the energy models of common network simulator are fine-grain, they fail to scale on large-scale platforms and high bandwidth application scenarios.

Experimentations and tools

Scientific experiments are vital to understand our world. They allow to build models for complex systems and potentially predict their evolutions. Models can be built inductively. This imply to study a particular case by mean of experiments and then constructing a model by generalization. On the other hand, models can be constructed by deduction. In this case, several hypothesis are proposed for a system. Then, these hypothesis can be accepted or rejected by mean of experiments. Thus, experimentation is essential in the process of research since it is the cornerstone of the models.

Regarding Computer Science, experimentations can be conduct by following different approaches. Each of them has advantages and drawbacks as we will see in this section. Since our work is based on network simulations this section also tackle the two types of network simulator namely Packet-Level Simulator (PLS) and Flow-Level Simulator (FLS).

Computer Science Experiments

In Computer Science research, there are many ways to conduct experiments. They can be categorized into three types: in vivo, in vitro and in silico experiments. First, in vivo experiments consists in studying a system by mean of observations. This allows to avoid the alteration of the system by the observer and it is considered has the most trustful type of experiment. Then, in vitro experiments strive to reproduce the system in a controlled environment such as virtual machines. Consequently, experiments can be reproduce (not necessarily identically). Thus, it offers more flexibility than in vivo experiments. Finally, in silico experiments is a neologism employed to designate experiments that occur on computers. This type experiment can be used to study many system from various field of research. It offers even more flexibility than in vitro experiments, but requires to construct solid models. The rest of the section (and the entire manuscript) focus on in silico experiments.

In silico, or computers experiments can be categorized as ether Emulations, Simulations Hybrid or Hardware In the Loop (HIL). Emulation consists in reproducing a complete system on a computer to study it. This category, mainly applied to Computer Science systems since natural phenomenon cannot be perfectly modeled. On the other hand, simulations consist in constructing models which are accurate enough to fully represent the original system. For example, many physical systems such as the n-body problem can be simulated offering sufficient environment to conduct studies [START_REF] Portegies Zwart | High-performance direct gravitational N-body simulations on graphics processing units[END_REF]. Next, hybrid experiments strive to use the best of both categories (emulation and simulation) on a single experiment [START_REF] Tazaki | Direct code execution: revisiting library OS architecture for reproducible network experiments[END_REF]. Finally, HIL experiment is at the frontier between in vivo and in silico experiments. It consists in making hardware devices interacting with the simulation environment. In this way, systems which are complex to model could be added to the experiment loop while saving time and having better accuracy [START_REF] Amoozadeh | VENTOS: Vehicular Network Open Simulator with Hardware-in-the-Loop Support[END_REF][START_REF] Lauss | Characteristics and Design of Power Hardware-in-the-Loop Simulations for Electrical Power Systems[END_REF][START_REF] Bacic | On hardware-in-the-loop simulation[END_REF].

In this thesis, we are focusing on in silico simulations meaning that our work do not involve hybrid or HIL experiments. In fact, since were targeting large-scale platform simulations, restricting our work to simulation allows to benefit from the scalability property.

In addition to scalability, we are interested in experiment reproducibility. In Computer Science, this feature allows to reproduce scientific works by making all the experiment process publicly available. Reproducibility increase the reader confidence in a work and can even help him/her in their own research. However, many work which claim to be reproducible are in reality hardly reproducible because of many factors [START_REF] Scheitle | Towards an Ecosystem for Reproducible Research in Computer Networking[END_REF] such as author unavailability, artifacts unavailability, unclear documentation or are only partially reproducible. But reproducibility is not a trivial task to achieve due to several factors [START_REF] Boettiger | An introduction to Docker for reproducible research[END_REF]. First, reproducibility cannot be achieve if it is not possible to reproduce the exact same binary file(s) which has generated the results. Since common executable has a wide dependency tree, this problem is be difficult to address. Several package managers such as Guix [START_REF] Courtès | Reproducible and User-Controlled Software Environments in HPC with Guix[END_REF] or Nix [START_REF] Devresse | Nix based fully automated workflows and ecosystem to guarantee scientific result reproducibility across software environments and systems[END_REF], aims at solving this issue. They can ensure to provide the exact same dependency tree used during for the experiment. In this way, we ensure that compilers could generate the exact same binary files. Still, learning these tools is time consuming and can restrain authors [START_REF] Boettiger | An introduction to Docker for reproducible research[END_REF].

In this the thesis, we claim our models to be scalable and accurate and hence these two properties should be verifiable. Thus, we strive to provide reproducible experiments with available artifacts along with all the steps to reproduce them. Our experiments are using simulators of networks and distributed applications as a core. The remaining of this section describe and compare such simulators.

Application-Level Simulators

Application-Level Simulator (ALS) is a type of network simulator oriented towards the simulation of distributed applications. ALSs propose convenient interfaces to represent distributed applications. They allow to study the interactions between the different distributed components of the application. Altough prediction accuracy is often presented as an important ideal goal, the tools presented in this section put a greater emphasis on the modeling of the application than on the accuracy of the network performance prediction. Most of them rely on simple latencies/bandwidth models as presented in Equation 2.2. Network protocol (TPC, UDP, etc.) overhead are thus not taken into account. In this section we detail several ALSs to evaluate their applicability for end-to-end network energy consumption studies.

CloudSim DES written in Java [START_REF] Calheiros | CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms[END_REF]. It provides a Java framework to setup and simulate Cloud networks. Since it provides packets as transmission unit. Yet, it does not provide any protocols stack implementation such as TCP or UDP. CloudSim proposes federated Clouds model which consists in orchestrating interconnected data centers to share the resources for the end users. CloudSim is representing the applicative part by means of a Cloudlet interface which encapsulate the application resource profile. Since CloudSim target essentially cloud simulations it used for different purpose such as economical study, provisionning policies, service delivering policies and energy consumption. Regarding energy consumption, CloudSim is limited to servers and VMs studies. Moreover, it suffers of network bandwidth aberrations as stated in [START_REF] Velho | On the validity of flow-level tcp network models for grid and cloud simulations[END_REF]. Consequently, to overcome the main issues of CloudSim, DartCSim+ where proposed [START_REF] Li | DartCSim+: Enhanced CloudSim with the Power and Network Models Integrated[END_REF]. DartCSim+ is an extension of CloudSim. It allows for wired network energy estimations and improves the VMs migration network model. Still, CloudSim and DartCSim+ cannot be used outside of the Cloud context to simulate various types of network topologies. To this end, they could not be used as an end-to-end energy consumption framework.

To simulate Fog environment, iFogSim has been proposed [START_REF] Gupta | iFogSim: A toolkit for modeling and simulation of resource management techniques in the Internet of Things, Edge and Fog computing environments: iFogSim: A toolkit for modeling and simulation of internet of things[END_REF]. It is an extension of CloudSim which provides Fog applications simulation. New entities such as sensors, actuators and Fog devices has been added. Communication between sensors and Fog nodes occurs by means of mtCloudSim is a flow-level DES designed for multi-tenant Cloud simulations [START_REF] Xie | mtCloudSim: A Flow-Level Network Simulator for Multi-Tenant Cloud[END_REF]. Multitenant Cloud consists in sharing the same application instance among different tenants (users) [START_REF] Karatas | Multi-tenant architectures in the cloud: A systematic mapping study[END_REF] to optimize resource sharing. Classical PLSs requires to mark each packets to identify each Cloud user while in mtCloudSim, user can be identify simply by marking flows. mtCloudSim proposes an energy model for network switches only and seems tied to Cloud studies. Thus it cannot be used for end-to-end energy consumption studies.

ALSs offer versatile distributed application network simulation. Taken separately, they cover a large part of today's network platforms. However, there is no ALS which covers the network from end-to-end with accurate network performance predictions. Indeed, ALSs network model suffer from a lack of validation. Consequently, existing ALSs cannot be used for end-to-end network energy consumption studies.

Packet-Level Simulators

Packet-Level Simulator (PLS) is a type of network simulators providing fine-grained network models [START_REF] Bonaventura | FLUID-FLOW AND PACKET-LEVEL MODELS OF DATA NETWORKS UNIFIED UNDER A MODULAR/HIERARCHICAL FRAME-WORK: SPEEDUPS AND SIMPLICITY, COMBINED[END_REF]. They strive to model every aspect of common networks such as packets, protocols (TCP/IP,UDP, routing, etc.) and Physical layers (interferences, buffering, etc.). The Figure 2.11 shows a network platform as represented in PLS. Thanks to their faithful representation of real networks, PLSs are often considered to be the reference in terms of predictions accuracy [START_REF] Liu | A study of networks simulation efficiency: fluid simulation vs. packet-level simulation[END_REF]. As presented in Section 2.2, although they provide accurate predictions, there are also harder to instantiate since they come with many parameters to setup [START_REF] Velho | On the validity of flow-level tcp network models for grid and cloud simulations[END_REF]. Regarding performance (execution time and memory usage), PLSs suffer from scalability issues on large-scale platforms [START_REF] Liu | Fluid Simulation of Large Scale Networks: Issues and Tradeoffs[END_REF][START_REF] Barrachina-Munoz | Komondor: a Wireless Network Simulator for Next-Generation High-Density WLANs[END_REF]. In fact, as they name suggest, PLSs simulate every packet that flows through the network. This has two major consequences on the performance. First, increasing the number of nodes in the network can potentially leads a to larger number of communication and thus decreasing the simulation performance. Second, on scenarios involving high bandwidth applications, the number of generated packets increase drastically which leads to bad performance. Nevertheless, despite these drawbacks PLSs are still widely used in research [START_REF] Sharma | An Inclusive survey of Network Simulators[END_REF][START_REF] Patel | Survey on Network Simulators[END_REF] for their fine-grained properties [START_REF] Nizzi | Protocol Prototype Implementation Using ns-3: a Use-Case[END_REF][START_REF] Iskounen | WiFi-Direct Simulation for INET in OMNeT++[END_REF][START_REF] Gangadhar | TCP Westwood(+) Protocol Implementation in ns-3[END_REF]. The remaining of this section is dedicated to the review of recent open source PLSs.

CupCarbon is a WSN network simulator [START_REF] Mehdi | CupCarbon: A Multi-agent and Discrete Event Wireless Sensor Network Design and Simulation Tool[END_REF] written in Java. It falls in the category of Discrete-Event Simulator (DES). DES are the most common network simulators where the system state (simulated time, energy consumption, etc.) is changing according to a discrete event list resulting from the initial conditions [START_REF] Schriber | How Discrete-Event Simulation Software Works[END_REF]. CupCarbon is also agent based, meaning that each sensors are considered to be independent agents. These agents can be programmed in the CupCarbon Domain Specific Language (DSL) called SenScript [START_REF] Lopez-Pavon | Evaluation of CupCarbon Network Simulator for Wireless Sensor Networks[END_REF]. Sensors can communicate through three communications technologies namely 802.15.4 (Zigbee, 6LoWPAN), Wi-Fi and LoRa. In addition, CupCarbon offers sensors mobility features and energy consumption predictions. CupCarbon targets WSN algorithms development, testing and debugging prior to real sensors deployment [START_REF] Bounceur | CupCarbon: A New Platform for Designing and Simulating Smart-City and IoT Wireless Sensor Networks (SCI-WSN)[END_REF]. It is able to simulate hundred of nodes but still, is is tied to the WSN domain and it is not possible to use it outside of this context. Thus, CupCarbon is not suitable for end-to-end network energy consumption studies.

Komondor is a Wireless Local Area Network (WLAN) simulator written in C++ [START_REF] Barrachina-Munoz | Komondor: a Wireless Network Simulator for Next-Generation High-Density WLANs[END_REF]. It is dedicated to simulate recent Wi-Fi standards. Currently, it implements the 802.11ax and support many of its features such as: 1) DCF 2) Aggregation 3) Dynamic Channel Bounding 4) MCS selection 5) RTS/CTS handshaking 6) Spacial Reuse. Komondor is dedicated to dense Wi-Fi communications study [START_REF] Barrachina-Muñoz | To overlap or not to overlap: Enabling channel bonding in high-density WLANs[END_REF] and do not provide any energy consumption models. Consequently, it cannot be used for Cloud, ISP or IoT studies.

OMNET++ is a versatile discrete-event library written in C++ [START_REF] Varga | AN OVERVIEW OF THE OMNeT++ SIMULATION ENVI-RONMENT[END_REF]. It is usually combined with the INET library [START_REF][END_REF] which proposes a complete network simulation environment. INET gives the different building blocks to simulate various network scenarios involving several wireless communication technologies such as Wi-Fi or 802.15.4. Additional frameworks could be added to integrate Bluetooth Low Energy (BLE) or LoRa communication models. Moreover, INET provide a fine-grained protocol stack implementations for various network protocol. Regarding energy consumption, INET provides the building blocks for nodes and radio components power measurements [START_REF] Ksimi | Minimizing energy consumption in IPv6 for Small Objects Network[END_REF] but it has no wired energy model. Despite their flexibility, OMNET++ and INET are not suitable for large scale experiment such as the end-to-end energy consumption simulation. In fact, simulations are slow and could not met the requirement of today's large-scale platforms.

Finally, ns-3 is a DES written is C++ [START_REF] Riley | The ns-3 Network Simulator[END_REF]. It proposes a complete C++ framework to simulate classical networks involving wired and Wi-Fi communications. Ns-3 implements a complete network protocol stack with a POSIX-like socket interface. In addition, ns-3 allows for power consumption measurement on node which take into account radio communications [START_REF] Wu | An Energy Framework for the Network Simulator 3 (ns-3)[END_REF]. Wired energy consumption models are provided by an external ns-3 module called ECOFEN [START_REF] Cornea | Studying the energy consumption of data transfers in Clouds: the Ecofen approach[END_REF][START_REF] Orgerie | ECOFEN: An End-to-end energy Cost mOdel and simulator For Evaluating power consumption in large-scale Networks[END_REF]. This module allows for wired network energy predictions based on the static, packet and byte energy values. ECOFEN has been validated in the literature [START_REF] Orgerie | Simulation Toolbox for Studying Energy Consumption in Wired Networks[END_REF] which makes it suitable for scientific studies. Thus, ns-3 provide great network simulation capabilities however, simulation performance are very bad on large-scale scenarios. Moreover, ns-3 does not provide CPU performance models. Thus, it cannot be used as an end-to-end energy consumption framework.

As presented in this section, many network simulators propose great features for network communication and energy simulations. However, none of them meet the requirements for end-to-end energy consumption study related to large-scale platforms. Table 2.2 summarizes this PLS analysis. In addition, a common weakness of PLSs is related to performance. In fact, all of them fail to scale considering a large-scale platform scenario with high bandwidth application. To this end, investigating another type of network simulator may gives us this scalability properties as we will see in the next section.

Flow-Level Simulators

To improve simulation performance beyond packet-level simulators presented in previous section, it is possible to follow three different approaches [START_REF] Liu | A study of networks simulation efficiency: fluid simulation vs. packet-level simulation[END_REF]. The first approach consists in using better hardware but PLSs already push current hardware to their limits [START_REF] Velho | Flow-level network models: have we reached the limits?[END_REF]. The second approach, consists in improving current simulations technologies towards efficient events processing such as better event-list algorithms [START_REF] Brown | Calendar queues: a fast 0(1) priority queue implementation for the simulation event set problem[END_REF]. Finally, the last approach proposes to improves simulations performance by using more efficient models. This is the approach used by Flow-Level Simulator (FLS), and consists in using coarse-grain network models for their efficiency property.

Instead of modeling each packet involved in communications, FLS models communications as a continuous flow of data as depicted on Figure 2.12. This has three major consequences. Firstly, since one communication generates a single event, the simulation performance are now independent from the number of packets generated during the simulation. Instead, performance depends on the number of communications occurring during the simulation which is much lower. Secondly, considering that a communication is a continuous flow of data is an approximation and thus, leads to uncertainty regarding the communication duration. Thirdly, a continuous flow of data on a single communication channel prevents from using time multiplexing such as in real networks. Thus, two communications cannot occur at the same time. Thus, a medium resource sharing model should be used to allow for concurrent communications. Still, despite these downside, FLSs are very efficient but a close attention should be given to model validity [START_REF] Velho | On the validity of flow-level tcp network models for grid and cloud simulations[END_REF]. In the remaining of this section, we will discuss about the existing FLSs to evaluate whether they can be used for end-to-end network energy consumption studies. Narses is a FLS written in Java [START_REF] Giuli | Narses: A Scalable Flow-Based Network Simulator[END_REF]. It proposes to simulate large-scale platforms such as peer-to-peer networks for applicative studies. Its resource sharing model is based on minimum share allocation. Narses makes the strong assumption that the Internet is following a strict hierarchical topology without internal bottlenecks. Thus, communications between a local and a distant node is only limited ether by the first or the last hop link involved in the communication. In this way, the ISP network could be ignored which improves the simulation performance. In addition, narses is definitely not designed for energy consumption studies and do not propose energy consumption models. Thus it is not suitable for end-to-end energy consumption studies.

DeSiNe is a another FLS written in C++ [START_REF] Kleiberg | De-SiNe: a flow-level QoS Simulator of Networks[END_REF]. It is designed for application Quality of Services (QoS) and routing algorithm studies. Currently, DeSiNe do not provides any energy models which makes it unsuitable for end-to-end energy consumption studies.

FLEO is another flow-level DES based on OMNET++ [START_REF] Anggono | A Flow-Level Extension to OMNeT++ for Long Simulations of Large Networks[END_REF]. FLEO proposes an efficient solution to simulate large-scale platforms such as CDN in an efficient way. Since it is a recent FLS it doesn't provide as many features as the other simulators. FLEO targets only application performance evaluation. Thus, it cannot be used for end-to-end energy consumption studies.

Finally, SimGrid is a flow-level DES written in C++ [START_REF] Casanova | Versatile, scalable, and accurate simulation of distributed applications and platforms[END_REF]. The main strength of SimGrid lies in its scalability and versatility. It is used in many research domains such as Grid Computing [START_REF] Casanova | WRENCH: A Framework for Simulating Workflow Management Systems[END_REF], Cloud Computing [START_REF] Michon | Schlouder: A broker for IaaS clouds[END_REF], Fog Computing [START_REF] Alonso-Monsalve | Fog computing through public-resource computing and storage[END_REF] and HPC [START_REF] Heinrich | Predicting the Energy-Consumption of MPI Applications at Scale Using Only a Single Node[END_REF]. It proposes a CPU model that support for applications times execution prediction for simple application but also more complex distributed applications such as Message Passing Interface (MPI) [START_REF] Heinrich | Predicting the Energy-Consumption of MPI Applications at Scale Using Only a Single Node[END_REF]. This CPU performance model comes along with a CPU energy model based on the CPU load. Additionally, SimGrid offers a VM simulation environment [START_REF] Hirofuchi | SimGrid VM: Virtual Machine Support for a Simulation Framework of Distributed Systems[END_REF] which can be used for Cloud platforms. Regarding network communications, SimGrid gives different coarse-grain network TCP models for wired communitations. Additional bindings with the ns-3 PLS allows for easily trigger ether flow-level or packet-level simulations. Nevertheless, SimGrid lack for network energy models such as wired and wireless. Thus, SimGrid is not currently suitable for end-to-end network energy studies. However, SimGrid does provide many features compared to the other FLSs tackled in this section. This makes it a good candidate for end-to-end energy simulations.

FLS are a very interesting alternative to PLS. They propose scalable network simulations by means of coarse-grained models. Nevertheless, current state of the art FLS do not provides the required features for end-to-end energy consumption studies as shown in Table 2.3. Most of current FLS are directed towards the applicative side and lack for energy models. Consequently, to achieve end-to-end energy consumption study using a single simulation framework, we propose to extends the SimGrid FLS to benefits from its scalability, versatility (not tied to a particular use case), its CPU performance and energy models and finally its VMs model for Cloud simulations.

Conclusion

This section presented the state of the art concerning the platforms which are part of today's Internet. This taxonomy reveal that modern network platforms are composed of many nodes with a variety of hardware characteristics. Some of these platforms are composed of nodes with high computational power and data storage capabilities while some others are essentially sensors with low-power requirements. Similarly, this diversity of characteristics (or heterogeneity) is correlated to their distance to the end user. Despite this diversity, all these platforms have a common point: They are large-scale. To better understand these platforms, we presented concrete applications in which they are involved. These use cases revealed significant diversity in terms of network footprint. Thus combining this heterogeneity in terms of hardware and network footprint raise multiple challenges related to security, scalability and above all energy consumption. In fact, we showed that connecting numerous nodes together have a major impact on the energy consumption. Thus, to improve the energy efficiency of those platforms, scientists need to study them experimentally. But this task is very difficult because of their scale.

Consequently, we choose to use the simulation approach to study large-scale platforms energy consumption. This approach has several benefits such as time, money saving and reproducibility. However, network energy simulations requires to use two types models: performance and energy. The performance model allows to estimate the duration of a given task while the energy model estimates its energy consumption. Thus, combining performance and energy models in a single simulation framework could be a good solution to study the end-to-end network energy consumption starting from the IoT up to the Cloud. However, current existing network simulators do not provide a convenient solution for endto-end network energy consumption studies. The first category of network simulator called packet-level, suffers from performance issues related to large-scale platforms and high bandwidth applications. The other category, named flow-level, suffers from a lack of features. Thus, current state of the art related to network simulators do not offer a framework for end-to-end network energy studies. To this end, we proposed to extends a FLS called SimGrid with the required models (from Table 2.3) to provide this framework. First, in Section 4 we propose an efficient wired network energy model for flow-level simulators. Then, in Section 5 we propose the first Wi-Fi performance model designed for flow-level simulators with the aim of building a Wi-Fi network energy model as a future direction. All the models are thus implemented into SimGrid towards a unique simulation framework to study the end-to-end network energy consumption. Current network simulators face scalability and versatility issues regarding modern largescale platforms. However, conducting end-to-end network experiments is still possible. In this chapter, we propose an end-to-end energy consumption study involving IoT, Internet Service Provider and cloud platforms on a low bandwidth use case. It uses current state of the art tools to conduct the experiments. This study aims to demonstrate that existing tools raised pratical issues while trying to study end-to-end network platforms. Additionnaly, we derive an end-to-end energy consumption model that can be used to assess the consumption of other IoT devices.

The chapter is organized as follows. Section 3.1 presents the context of the work. The low-bandwidth IoT application is characterized in Section 3.2. Details on its architecture are provided in Section 3.3. Section 3.4 provides our experimental results combining real measurements and simulations. Section 3.5 discusses the key findings of the end-to-end energy model. Finally, Section 3.6 concludes the study.

Context

Some IoT devices such as smart vehicles produce a lot of data while many others such as smart meters generate only a small amount of data. Heven so, the scale matters: many small devices can produce big data volumes. As an example, according to a report published by Sandvine in October 2018 [START_REF] Sandvine | The Global Internet Phenomena Report[END_REF], the Google Nest Thermostat is the most significant IoT device in terms of worldwide connections. It represents 0.16% of all connections and it is ranked 55th on the list of the worlwide connections. As a comparison, the voice assistants Alexa and Siri are respectively 97th and 102nd with 0.05% of all connections [START_REF] Sandvine | The Global Internet Phenomena Report[END_REF]. This example highlight the growing importance of low-bandwidth IoT applications on the Internet infrastructures, and consequently on their energy consumption.

In this chapter, we focus on low-bandwidth applications related to IoT devices such as smart meters or smart sensors. These devices send few data periodically to cloud servers, either to store them or to get computing power and take decisions. This is a first step towards a comprehensive characterization of the global IoT energy footprint. While few studies address the energy consumption of high-bandwidth IoT applications [START_REF] Li | Endto-end energy models for Edge Cloud-based IoT platforms: Application to data stream analysis in IoT[END_REF], to the best of our knowledge, none of them targets low-bandwidth applications, despite their growing importance on the Internet infrastructures.

Low-bandwidth IoT applications such as the Nest Thermostat often rely on sensors powered by batteries. For this type of sensors, reducing their energy consumption is a critical target. Yet, we argue that end-to-end energy models are required to estimate the overall impact of IoT devices, and to understand how to reduce their complete energy consumption. Without such models, one could optimize the consumption of on-battery devices at a heavier cost for cloud servers and networking infrastructures, resulting on an higher overall energy consumption. Using end-to-end models could prevent these unwanted effects.

This chapter aims at evaluating the existing experimental tools for end-to-end network energy consumption study. Still, it also yields the following contributions:

• A characterization of low-bandwidth IoT applications.

• An energy consumption analysis of a low-bandwidth IoT application, including the energy consumption of the Wi-Fi IoT device and the consumption induced by its utilization on the Cloud and telecommunication infrastructures.

• An end-to-end energy model for low-bandwidth IoT applications relying on Wi-Fi devices.

vary from one to several packet per minute [START_REF]Cisco, Cisco Visual Networking Index: Forecast and Trends[END_REF].

We consider that the link between the AP and the Cloud is composed of several network switches and routers using Ethernet as shown in Figure 3.1b. The number of routers on the path depends on the location of the server, either in a Cloud data center or in a Fog site at the edge of the network.

We assume that the server hosting the application data for the users belongs to a shared cloud facility with classical Service Level Agreement (SLA). The facility provides redundant storage and computing means as VM. A server can host several VMs at the same time.

Experimental setup

The used experimental setup aims at evaluating the limits of the available tools in terms of end-to-end energy consumption study. The IoT and the network parts are modeled through ns-3 simulations which is a well known simulator used for network studies and detailed in Section 2.3.3. However, since no simulator are versatile enough to include Cloud simulations, we have to add an additional layer of experiment. Thus, to model the Cloud part we used real servers connected to wattmeters. By combining these tools, it is possible to evaluate the end-to-end energy consumption of the whole system.

IoT Part

In the first place, the IoT part is composed of several sensors connected to an AP which form a cell. In the experimental scenario, we setup between 5 and 15 sensors connected to the AP using Wi-Fi 5GHz 802.11n. The nodes are placed randomly in a rectangle of 400m 2 around the AP which corresponds to a typical use case for a home environment. All the cell nodes employ the default Wi-Fi energy model provided by ns-3. The different energy values used by the energy model are provided in Table 3.1. These parameters were extracted from previous work [START_REF] Halperin | Demystifying 802.11n Power Consumption[END_REF][START_REF] Li | Endto-end energy models for Edge Cloud-based IoT platforms: Application to data stream analysis in IoT[END_REF] on IEEE 802.11n. Besides, we suppose that the energy source of each node is not limited during the experiments. Thus each node can communicate until the end of all the simulations.

As a scenario, sensors send 192 bits packets to the AP. These packets are composed of:

1) A 128 bits sensors id 2) A 32 bits integer representing the temperature 3) An integer timestamp representing the temperature sensing date. They are stored as time series. The data are transmitted immediately at each sensing interval I that we vary from 1s to 60s. Finally, the AP is in charge of relaying data to the cloud via the network part.

Network Part

The network part represents the a network section starting from the AP to the Cloud excluding the server as depicted on Figure 3.1b. We consider the server to be 9 hops away from the AP with a typical round-trip latency of 100ms from the AP to the server [START_REF] Li | Endto-end energy models for Edge Cloud-based IoT platforms: Application to data stream analysis in IoT[END_REF]. Each node from the AP to the Cloud is a network switch with static and dynamic network energy consumption. The first 8 hops are edge switches and the last one is considered to be a core router as mentioned in [START_REF] Jalali | Fog Computing May Help to Save Energy in Cloud Computing[END_REF].

We leverage the ECOFEN energy model of ns-3, that is presented in Section 2.3.3. The Table 3.1 shows the differents parameters used to instantiate the ECOFEN energy model. These values were extracted from previous works [START_REF] Cornea | Studying the energy consumption of data transfers in Clouds: the Ecofen approach[END_REF].

Cloud Part

Finally, to measure the energy consumed by the Cloud part, we use a real server from the large-scale test-bed Grid'5000 describe in Section 2.1.1. Grid'5000 provides clusters composed of several nodes which are connected to wattmeters. The wattmeters provide 50 instantaneous power measurements per second and per server. This way, we can benefit from real energy measurements. The server used in the experiment embeds two Intel Xeon E5-2620 v4 processors with 64 GB of RAM and 600GB of disk space on a Linux based operating system. This server is configured to use KVM as virtualization mechanism. We deploy a classical Debian x86_64 distribution on the VM along with a MySQL database. We use different amounts of allocated memory for the VM namely 1024MB/2048MB/4096MB to highlight its effects on the server energy consumption. The server only hosts this VM to easily isolate its power consumption. One drawback of using this second experimentation process for the Cloud part is that the IoT devices cannot directly communicate with the server. Thus, the data sent by the IoT devices are simulated using another server from the same cluster. This server is in charge of sending the data packets to the VM hosting the application to fill its database. In the following, each data packet coming from an IoT device and addressed to the application VM is called a request. Consequently, it is easy to vary the different application characteristics namely: 1) The number of requests, to virtually add/remove sensors 2) The requests interval, to study the impact of the transmitting frequency. Figure 3.2 presents this experimentation setup.

Evaluation

IoT and Network Power Consumption

In this section, we analyze the experimental results. We first study the impact of the sensors' transmission frequency on their energy consumption. To this end, we run several simulations in ns-3 with 15 sensors using different transmission frequencies. The results are shown on Table 3.2.

These results show that the transmission frequency has a very low impact on the energy consumption and on the average end-to-end application delay. The impact exists, but remains very limited. This due to the fact that in such a scenario with very small number of communications Previous work [START_REF] Li | Endto-end energy models for Edge Cloud-based IoT platforms: Application to data stream analysis in IoT[END_REF] on a similar scenario shows that increasing application accuracy impacts strongly the energy consumption in the context of data stream analysis. In our case, application accuracy is driven by the sensing interval and thus, the transmission frequency of the sensors. It is characterized by small and sporadic network traffic. Results show that with a reasonable transmission interval, the energy consumption of the IoT and the network parts are almost not affected by the variation of this transmission interval. In fact, transmitted data are not large enough to leverage the energy consumed by the network.

We then vary the number of sensors in the WiFi cell. Figure 3.3 represents the energy consumed by the sensor and the network (from the AP to the cloud) parts according to the number of sensors. Similarly to the results of Table 3.2, the network part is almost not affected by the number of sensors as their traffic is negligible compared to the network devices capacities. Consequently, sensors energy consumption is dominant, as each sensor adds its own consumption.

Cloud Energy Consumption

In this end-to-end energy consumption study, cloud accounts for a huge part of the overall energy consumption. According a report [START_REF] Shehabi | United States Data Center Energy Usage Report[END_REF] on United States data center energy usage, the average PUE of an hyper-scale data center is 1.2. Thus, all our energy measurements on the cloud server will account for the PUE in our analysis. It means that the power consumption of the server is multiplied by the PUE to include the external energy costs such as server cooling and data center facilities [START_REF] Ahvar | Estimating Energy Consumption of Cloud, Fog and Edge Computing Infrastructures[END_REF].

Firstly, we analyze the impact of the memory allocated by the VM on the server energy consumption. Figure 3.4 depicts the server energy consumption according to the memory allocated by the VM for 20 sensors sending data every 10s. Note that the horizontal red line represents the average energy consumption for the considered sample of energy values. We can see that at each transmission interval, the server faces to spikes of energy consumption. However, the amount of allocated memory to the VM does not significantly influence the server energy consumption. In fact, simple database requests do not need any particular heavy memory accesses and processing time. Thus, the remaining experiments are solely based on VM with 1024MB of allocated memory.

Next, we study the effects of increasing the number of sensors on the server energy consumption. Figure 3.5a presents the results of the average server energy consumption when varying the number of sensors from 20 to 500. Figure 3.5b presents the average server energy cost per sensor according to the number of sensors. These results show a clear linear relation between the number of sensors and the server energy consumption. Moreover, we can see that the more sensors we have per VM, the more energy we can save. In fact, since the server's idle power consumption is high (around 97 Watts), it is more energy efficient to maximize the number of sensors per server. As shown on Figure 3.5b, a significant amount of energy can be save when passing from 20 to 300 sensors per VM. Note that these measurements are not the row measurements taken from the wattmeters: they include the PUE but they are not shared among all the VMs that could be hosted on this server. So, for the studied server, its static power consumption (also called idle consumption) is around 83.2 Watts and we consider a PUE of 1.2 (this value is taken from [START_REF] Shehabi | United States Data Center Energy Usage Report[END_REF]).

A last parameter can leverage server energy consumption, namely sensors transmission interval. In addition to increasing the application accuracy, sensors transmission frequency increases network traffic and database accesses. Figure 3.6 presents the impact on the server energy consumption when changing the transmission interval of 50 sensors to 1s, 10s and 30s. We can see that, the lower the sensors transmission interval is, the more server energy consumption peaks (≈ 150W) occur. Therefore, it leads to an increase of the server energy consumption. An end-to-end analysis is mandated to fully understand this tradeoff.

End-to-end Consumption Model

To have an overview of the energy consumed by the overall system, it is important to consider the end-to-end energy consumption. We detail here the model used to attribute the energy consumption of our application for each part of the architecture:

1. For the IoT part, the entire consumption of the IoT device belongs to the system's accounted consumption.

2. For the network part, the data packets generated by the IoT device travel through network switches, routers and ports that are shared with other traffic.

3. For the cloud part, the VM hosting the data is shared with other IoT devices belonging to the same application and the server hosting the VM also hosts other VMs. Furthermore, the server belongs to a data center and takes part in the overall energy drawn to cool the server room.

Concerning the IoT part, we include the entire IoT device power consumption. Indeed, in our targeted low-bandwidth IoT application, the sensor is dedicated to this application. From Table 3.1, one can derive that the static power consumption of one IoT sensor is around 0.9 Watts. Its dynamic part depends on the transmission frequency.

Concerning the sharing of the network costs, for each router, we consider its aggregate bandwidth (on all the ports), its average link utilization and the share taken by our IoT application. For a given network device, we compute our share of the static energy part as follows:

P netdevice static =
P device static × Bandwidth application AggregateBandwidth device × LinkU tilization device where P device static is the static power consumption of the network device (switch fabrics for instance or gateway), Bandwidth application Is the bandwidth used by our IoT application, AggregateBandwidth device is the overall aggregated bandwidth of the network device on all its ports, and LinkU tilization device is the effective link utilization percentage. The Bandwidth application depends on the transmission frequency in our use-case. The formula includes the link utilization to charge for the effective energy cost per traffic and not for the theoretical upper bound which is the link bandwidth. Indeed, using such an upper bound leads to greatly decrease our energy part, since link utilization typically varies between 5 to 40% [START_REF] Hassidim | Network utilization: The flow view[END_REF][START_REF] Zhang | Energy-Efficient IP Core Network Configuration Under General Traffic Demands[END_REF].

Similarly, for each network port, we compute the share attributable to our application: the ratio of our bandwidth utilization over the port bandwidth multiplied by the link utilization and the overall static power consumption of the port. Table 3.3 summarizes the parameters used in our model, they are taken from [START_REF] Mahadevan | A Power Benchmarking Framework for Network Devices[END_REF][START_REF] Hassidim | Network utilization: The flow view[END_REF]. These parameters are used in our formula to compute the values used in the simulations. They are presented in left part of Table 3.1.

Concerning the Cloud costs, we take into account the number of VMs that a server can host, the CPU utilization of a VM and the PUE. For a given Cloud server hosting our IoT application, we compute our share of the static energy part as follows:

P Cloudserver static = P server static × P U E DataCenter HostedV M s server
Where P server static is the static power consumption of the server, P U E DataCenter is the data center PUE, and HostedV M s server is the number of VMs a server can host. This last parameter should be adjusted in the case of VMs with multiple virtual CPUs. We do not consider here overcommitment of Cloud servers. Yet, the dynamic energy part is computed with the real dynamic measurements, so it accounts for VM over-provisioning and resource under-utilization.

In our case, the Cloud server has 16 cores, which corresponds to the potential hosting of 16 small VMs with one virtual CPU each, with each vCPU pinned to a server core. We consider that for fault-tolerance purpose, the IoT application has a replication factor of 2, meaning that two cloud servers store the database.

The Figure 3.7 represents the end-to-end system energy consumption using the model described above while varying the number of sensors for a transmission interval of 10 seconds. The values are extracted from the experiments presented in the previous section.

Note that, for small-scale systems, with Wi-Fi IoT devices, the IoT sensor part is dominant in the overall energy consumption. Indeed, the IoT application induces a very small cost on Cloud and network infrastructures compared to the IoT device cost. But, our model assumes that a single VM is handling multiple users (up to 300 sensors), thus being energy-efficient. Conclusions would be different with one VM per user in the case of no over-commitment on the Cloud side. For the network infrastructure, in our case of low-bandwidth utilization (one data packet every 10 seconds), the impact is almost negligible. Another way of looking at these results is to observe that only for a high number of sensors (more than 300), the power consumption of Cloud and network parts start to be negligible (few percent). It means that, if IoT applications handle clients one by one (i.e. one VM per client), the impact is high on cloud and network part if they have only few sensors. The energy efficiency is really poor for only few devices: with 20 IoT sensors, the overall energy cost to handle these devices is almost doubled compared to the energy consumption of the IoT devices themselves. Instead of increasing the number of sensors, which would result in a higher overall energy consumption, one should focus on reducing the energy consumption of IoT devices, especially Wi-Fi devices which are common due to Wi-Fi availability everywhere. One could also focus on improving the energy cost of Cloud and network infrastructure for low-bandwidth applications and few devices.

Conclusion

The presented experiment combines simulations and real measurements to study the energy impact of IoT devices. In particular, we analyze the energy consumption of Cloud and communication infrastructures induced by the utilization of connected devices. Through the fine-grained analysis of a given low-bandwidth IoT device periodically sending data to a Cloud server using Wi-Fi, we propose an end-to-end energy consumption model. This model provides insights on the hidden part of the iceberg: the impact of IoT devices on the energy consumption of Cloud and network infrastructures. On our use-case, we show that for a given sensor, its larger energy consumption is on the sensor part. But the impact on the Cloud and network part is huge when using only few sensors with low-bandwidth applications. The simulations and the experiments presented in this chapter are available online [START_REF] Guegan | Estimating the end-to-end energy consumption of lowbandwidth IoT applications for WiFi devices[END_REF].

This experiment is also interesting on the methodological aspect, because it highlights the difficulties faced for such studies. First, we had to split our experimentation in two part to model the energy consumption of the whole system. Consequently, we had to simulate the IoT traffic on the servers side. Moreover, the fact that we did not used a unified framework leads to a lack of experimental flexibility. Indeed, we were not able to easily integrate several IoT platforms along with multiple servers connected to a common ISP network. The lack of scalability on the simulation part prevents us from simulating more than 50 devices in a resonable amount of time. Thus, we had to extrapolate the data to obtain energy consumption predictions up to 300 hundred sensors. Then, the fact that we had to simulate the IoT traffic on the server part add more complexity for horizontal scaling. The following chapters will alleviate some of these difficulties.

Chapter 4 Chapter 2 and 3, demonstrate that the use of simulation is a good way for scientists to develop, improve and assess models that predict the network energy consumption. However, as stated in Section 2.3.3, packet-level simulators start to reach their limits in terms of performance. This calls for a new solution to study the wired network energy consumption of largescale platforms. In this chapter, we propose two energy models for wired networks adapted to flow level simulation to estimate the energy consumption of large-scale platforms. An evaluation of these models is proposed to demonstrate their applicability and their accuracy. This chapter is structured as follows. Section 4.1 introduces the context of the contribution along with the problem. Section 4.2 presents the proposed energy models. Section 4.3 details our evaluation methodology. Then, an evaluation of the energy models in terms of validity, scalability and applicability is proposed in Section 4.4. Finally, we conclude in Section 4.5.

EFFICIENT WIRED NETWORK ENERGY MODEL

Context and Problem

Current network platforms are getting larger. The Section 2.1.3 details the different challenges and use cases raised by these platforms. In particular, we are facing to an increase of the energy consumed by wired network platforms such as data centers and ISP networks. To study and improve their energy efficiency, network simulators can be used as a experimental framework. In addition, providing a scalable solution for wired network energy simulation pushes a step towards the end-to-end network energy simulation as presented in Figure 1.2.

The energy consumption of wired networks can be estimated by several types of simulators. However, they work at a fine grain -simulating each packet exchange -and thus are not scalable enough for modern research purposes which involves large network platforms and potentially huge network traffic volumes. Indeed, their fine-grained network models are not compatible with efficient simulations. Nevertheless, scalable simulators such as FLSs exist but to the best of our knowledge, none of them provide network energy consumption models while not being limited to a specific network domain (such as Cloud or Fog). FLSs operate at a communication flow level and do not simulate each packet. Thus, this approach allows to reduce simulation execution time and memory footprint. In practice, FLSs constitute a nice compromise between network abstraction and scalability. But their coarse-grained nature makes current wired network energy model not directly applicable to FLSs. Therefore, to the best of our knowledge there is no efficient network simulator with a scalable wired energy model to study the energy consumption of large-scale platforms. Consequently, in this work we propose to extend the existing flow-based simulator SimGrid with a wired network energy model. We show that modeling the network energy consumption into a flow-level simulator leads to predictions that are in line with the predictions of packet-level simulators. We also show that simple linear models are sufficient on realistic settings to obtain accurate values, while more complex models were proposed in literature. Additionally, we will demonstrate the applicability of our models on large-scale platforms.

Contribution

A Link based Wired Network Energy Model

Simulators are able to abstract the complexity of network devices energy consumption. As explained in Section 2.2.2, even if a network equipment is not subject to any network traffic, it consumes energy. Indeed, the different components involved in network devices should be maintained powered on to ensure a fully functional network communication in case of packet arrival. This energy consumption part, called the idle or static part can represent 85% of the device peak power [START_REF] Fiandrino | Performance Metrics for Data Center Communication Systems[END_REF]. Classically, the energy consumption is estimated using the energy definition presented in the Equation 2.1. Considering a network device, its energy consumption varies over time according to the network traffic. Since its power is composed of two parts: one static and one dynamic, we can define its overall power consumption such as in the Equation 2.3. Existing energy models in the literature are based on this equation that involves energy cost per network packet. Thus, they are not directly compatible with flow-level simulators. Indeed, flow-level simulators do not provide any notion of port in their models nor packets. These energy models should be adapted to this network representation.

SimGrid does not include Network Interface Controllers (NICs) and routers. Instead, the paths between two hosts are represented by routes. Each route is composed of several entities, called links that represent both, the wire and the NICs at each end. A route between two hosts can be composed of multiple links but not necessarily of multiple hosts. To this end, there is no notion of port in flow-level simulators. In spite of this, we can attach the energy consumption of ports on the links. Thus, we propose to define the instantaneous power of the overall network platform using the following equation:

P total (t) = i∈L P i static + P i dynamic × Load i (t) (4.1)
with L representing the set of links on the simulated network platform, P i static the static power of the link i, P i dynamic the dynamic power of the link i and Load i the load (usage) of the link i. As stated previously, wired network energy models are using low-level instantiation parameters such as the energy consumption per byte and per packets which are not available in FLS. Hence, we propose to use a wired network energy model using a linear equation with an intercept equal to the idle port power consumption and a maximum power consumption defined as follow:

P max = P idle + BW × E ByteCons + E P ktCons M T U Dynamic Part (4.2)
In this equation, BW represents the maximum port rate in Bps, E ByteCons its energy consumption per byte in Joules, E P ktCons represents the network device energy consumption needed for handling a packet in Joules. Finally, the MTU (Maximum Transmission Unit) is used as an over-approximation of the packet size. Given this equation, we are able to estimate the energy consumed by a single port using a link. However, in every real networks, each link is connected to two different ports with potentially different energy consumption schemes. This represents another difficulty for transposing packet-level energy models into FLSs due to their coarse-grain nature. To solve this issue, we propose to define two energy models based on the Equation 4.2. The first one is dedicated to platforms with ports that have the same energy consumption characteristics (called homogeneous energy platforms). The second model is dedicated to heterogeneous energy platforms.

Homogeneous model for flow-based simulators

Firstly, we introduce an energy model for network topologies that uses homogeneous network devices. As said previously, links will hold the energy consumption for each of their ports. In addition, links should ensure the bandwidth sharing. To achieve this goal in SimGrid, we propose to use one split-duplex link between each end-node. In SimGrid, a split duplex link creates two physicals links. One is dedicated to the upward traffic and the other one for the backward traffic. Thus, each of these two links carries an energy consumption model (one for each port). However sending to an upward or backward link should involve the energy consumption of 2 ports namely the source and the destination. Thus, to overcome the lack of port representation into SimGrid, we double the dynamic energy consumption of the upward and backward link to account for the energy consumption of the two ports (one at each end of the link). This operation is possible since both ports have the same energy consumption characteristics (homogeneous platform). Figure 4.1 depicts this homogeneous energy model for both PLS and FLS. Using the Equations 4.1 and 4.2 the port power consumption of the overall platform at any time t can be express as follow:

P total (t) = i∈L P idle + 2 × BW i × (E ByteCons + E P ktCons M T U ) × Load i (t) (4.3)
This energy model has multiple advantages. First, it is very easy to instantiate because there is only one energy cost per link. Consequently, this makes it easier to implement on flow-level simulators since these simulators use at least links for communications (but not necessarily ports). Finally, this model provides low computational overhead. However, many real topologies use heterogeneous networking devices. Thus, the energy consumption from one NIC to another varies according to its specifications. Consequently, this heterogeneity cannot be explicitly represented using the homogeneous model. Hence, we decide to introduce another model to overcome this limitation.

Heterogeneous model

In SimGrid, routes from one host to another can be composed of multiple links. Therefore, we can take advantage of this feature to build the heterogeneous model. To model two ports with different energy consumption values on a single link, we introduce routes made of 3 links. The first link models the energy consumption of the first port, the second link handles the bandwidth sharing and finally, the third link models the energy consumption of the second port. However, we are using split-duplex links, thus two links will be created by SimGrid and consequently the idle power will be multiplied by two. To overcome this issue, we simply divide by two the idle power of each energy link. Thus, this energy model follows a linear behavior with a minimum value equals to idle /2 and a maximum value defined as:

P max = P idle 2 + BW × E ByteCons + E P ktCons M T U DynamicP art (4.4)
The Figure 4.2 depicts this heterogeneous energy model for both PLS and FLS. An XML platform example for the heterogeneous energy model is provided on Listing 4.1. Using the Equations 4.1 and 4.2 the port power consumption of the overall platform at any time t can be express as follow:

P total (t) = i∈L P idle i 2 + BW i × (E ByteCons i + E P ktCons i M T U ) × Load i (t) (4.5)
Now we have defined both energy models, the next step is to assess them in terms of prediction accuracy and scalability. < link id = " Link12 " bandwidth = " ${ BWPAR } " latency = " ${ LATPAR } ms " sharing_policy = " SPLITDUPLEX " > < prop id = " watt_range " value = " 0 :0 " / > </ link > < link id = " Link13 " bandwidth = " ${ BWPAR } " latency = " 0 ms " sharing_policy = " SPLITDUPLEX " > < prop id = " watt_range " value = " ${ NODE1 -MIN } : ${ NODE1 -MAX } " / > </ link > < route src = " Node0 " dst = " Node1 " symmetrical = " NO " > < link_ctn id = " Link11_UP " / > < link_ctn id = " Link12_UP " / > < link_ctn id = " Link13_UP " / > </ route > < route src = " Node1 " dst = " Node0 " symmetrical = " NO " > < link_ctn id = " Link11_DOWN " / > < link_ctn id = " Link12_DOWN " / > < link_ctn id = " Link13_DOWN " / > </ route > </ AS > </ platform > Listing 4.1: Example of a SimGrid XML platform involving two hosts with the heterogenous energy model.

The evaluation of the two energy models is divided in two steps. The first step is dedicated to assessing the models by means of microbenchmark simulations. Hence, the experiments are launched using small platforms to achieve simulations on a simple and controlled environment. The second step of the evaluation is focused on testing the energy models on a real large-scale scenario. In this way, we can demonstrate that the models are suitable for real research purposes and thus, are useful for the scientific community. In addition, it demonstrates that the energy models are scalable regardless of the simulated platform and the workload size. It is important to note that our evaluation focuses on the network energy consumption estimation and not on the network performance model. Yet, it is mandatory to have accurate time estimations to get accurate energy consumptions.

To conduct the validation experiments, we decided by lack of real large-scale platforms, to do simulations. In fact, validating these energy models using test-beds requires to measure the energy consumption per byte and per packet on each network device. However, these measurements require high-precision instruments. Nevertheless, these energy measurements results are proposed in the literature [START_REF] Sivaraman | Profiling per-packet and perbyte energy consumption in the NetFPGA Gigabit router[END_REF][START_REF] Cornea | Studying the energy consumption of data transfers in Clouds: the Ecofen approach[END_REF]. Therefore, we based our experiments on these works.

To validate the two energy models, the experiments are done in parallel on a packet-level simulator that acts as a trusted party. We choose to use ns-3 and ECOFEN for this purpose. It is a logical choice since ECOFEN has been assessed as accurate in the literature [START_REF] Orgerie | Simulation Toolbox for Studying Energy Consumption in Wired Networks[END_REF]. Moreover, ns-3 is a PLS. Thus it will be useful for the scalability experiments to compare its simulation performance to SimGrid. It is important to mention that all the simulations ran on Grid'5000, a large-scale test-bed for experiment-driven research in computer science. In fact, microbenchmark scenarios require 96 unique simulations for only one experiment point (4 data transfer scenarios, 3 topologies with 2 energy instantiation, 3 models are tested including one which is an optimization). Overall it represents 1 440 simulations. Moreover, the real use case experiment is also computationally intensive for ns-3 and ECOFEN.

All the experiments presented in this work are available online [START_REF] Guegan | A Large-Scale Wired Network Energy Model for Flow-Level Simulations[END_REF]. We did our best to provide reproducible experiments that can be launch with different parameters and require the least possible amount of user interactions for the reader desirous of reproducing our experiments.

Experimental setup

To conduct microbenchmark simulations, we designed different experimental scenarios. These scenarios are built to account for the effects on the energy consumption of the following parameters: 1) The number of nodes and their connections in the network 2) Different flow configurations, and thus different bandwidth sharing patterns 3) The heterogeneity of the devices in terms of energy profile. For this, we define three platforms. The first one is composed of two hosts connected by one link. The second platform is an extension of the first one where we add two hosts and two links. Finally, the last platform, called Dogbone, is composed of six hosts connected together to form a bottleneck on the two central hosts. Furthermore, the platforms can be set up with homogeneous or heterogeneous energy consuming devices.

Thanks to these two variants, the ability of each model to predict the overall energy consumption of platforms with homogeneous and heterogeneous devices is highlighted. These scenarios are summarized on Figure 4.3. Then, each platform is running with different TCP flow configurations. Other classical network parameters are also defined. These parameters are equals for all the microbenchmark scenarios: the latency is set to 10ms and the bandwidth to 1Gbps for each link since the energy value for such a NIC is available in the literature [START_REF] Sivaraman | Profiling per-packet and perbyte energy consumption in the NetFPGA Gigabit router[END_REF][START_REF] Cornea | Studying the energy consumption of data transfers in Clouds: the Ecofen approach[END_REF]. Thus according to these works, the energy values used in our microbenchmarks for 1Gbps links are 1.12 Watts for idle power consumption, 3.4nJ for energy consumed per byte and 197.2nJ for the energy consumption per packet. Regarding the heterogeneous platform instantiation, we also use additional energy values for 10Gbps links namely 0.53 Watts for idle power consumption, 14nJ and 1 504nJ respectively for energy consumption per byte and per packet. All these energy parameters are summarized in Table 4.1. Finally, the data flow size is varying randomly between 10MB to 100MB (x-axis) to build a power profile of the network platforms. We used random data flow size values in order to avoid bias that could occur with evenly distributed samples.

Evaluation: validity, scalability and real use case

Validity of the proposed models

As a first step, we simulate the microbenchmark scenarios on homogeneous energy consumption platforms. The amount of data sent by the hosts varies according to the parameters defined in Section 4.3.2. The results for the different platforms are shown on Figure 4.4. The flow configuration used for these scenarios is the following: 3 flows overall (2 up and 1 down) between the extreme nodes of each platform. The results for the other scenarios (not displayed) are similar.

These first results show the ability of each model to predict the overall platform' ports (Total Energy) energy consumption (static and dynamic) with homogeneous network devices. The results show a linear relation between the amount of data sent between hosts and the overall energy consumption. One interesting phenomenon to note is that both SimGrid energy models predict the exact same amount of energy. Their energy relative error is close to 0, which means they have the same energy prediction ability. In fact, it is not surprising since the first energy model is a subset of the second one. Thus, they show similar predicting abilities on homogeneous platforms. To measure the energy prediction accuracy of our models we used the Average Relative Error (ARE) metric. More specifically we based the ARE on the logarithmic error metric borrowed from [START_REF] Velho | On the validity of flow-level tcp network models for grid and cloud simulations[END_REF]:

MeanLogErr = |log 10 Êtotal E total | with MeanLogErr ∈ ]0, +∞[ (4.6)
were Ê is the estimated energy consumption (SimGrid predictions) and E is the reference energy consumption (ns-3). Then the ARE can be deduced with the following formula:

MeanRelErr = exp 10 (MeanLogErr) -1 (4.7)
The measured ARE between both energy models (homogeneous and heterogeneous) and the ECOFEN ns-3 module shows a very high prediction accuracy with MeanRelErr < 1%.

Next, to demonstrate the ability of each model to predict the energy consumption on heterogeneous platforms, we run similar microbenchmark experiments using the scenarios with heterogeneous devices in terms of energy consumption. Thereby, we expect the homogeneous model to have a lower prediction accuracy since it is not designed to handle heterogeneous energy platforms.

The simulation results are shown on Figure 4.5. As expected, the homogeneous model is less accurate than the heterogeneous model. In fact, we can clearly see that the heterogeneous model energy estimation corresponds to the energy predicted by ns-3 and ECOFEN. However, the homogeneous model is doing wrong approximations. This phenomenon is explain by the fact that the granularity of the first energy model is not fine enough to fully capture the dynamic energy consumption of the network devices.

Nonetheless, we decided to modify the instantiation of the homogeneous model to improve its prediction capability. Hence, for each link we attach energy values that are equal to the average values between the two ports at each end of the link. The results of these simulations are also visible on Figure 4.5 under the "Optimized Homogeneous Model". Surprisingly, by using this simple optimization we observe that the homogeneous model produces very accurate results almost equal to the heterogeneous model. This improvement can be explained by the fact that on real platforms, the traffic going through each port of a link is almost the same (when there is no packet loss) and thus, taking the mean has a limited impact on the overall energy consumption. Obviously, the relative error between ECOFEN and the homogeneous model will increase if this difference becomes larger. Hopefully, in real platforms this difference remains reasonable. Still, the heterogeneous energy model multiplies by three the number of links used in the SimGrid simulation. This is not negligible in terms of runtime on large-scale platforms. This is why, by following the Occam's razor Principle, we decide to use the homogeneous energy model with the arithmetic mean instantiation in the remaining experiments.

Realistic use case

To evaluate the scalability of our approach, we propose to simulate a data center network which is a classical large-scale platform widely used in research [START_REF] Kliazovich | GreenCloud: a packet-level simulator of energy-aware cloud computing data centers[END_REF][START_REF] Calheiros | CloudSim: a toolkit for modeling and simulation of cloud computing environments and evaluation of resource provisioning algorithms[END_REF][START_REF] Krzywda | Powerperformance tradeoffs in data center servers: DVFS, CPU pinning, horizontal, and vertical scaling[END_REF]. Therefore, this final experiment has two main goals. First, it demonstrates that our optimized homogeneous energy model scales up in terms of execution time and memory usage. Secondly, it shows that this energy model is usable for real experiments and thus it is interesting for the scientific community. The data center platform is based on a classical three-tier architecture used in the Greencloud experiments [START_REF] Kliazovich | GreenCloud: A Packet-Level Simulator of Energy-Aware Cloud Computing Data Centers[END_REF]. It is composed of 8 core routers that provide access to the data center. The core nodes are linked to 16 aggregation switches by 10Gbps links. Note that each core nodes are linked to every aggregation switches. Then, these aggregation nodes are linked to 512 access switches by 1Gbps links that provide access to 1 536 servers by mean of 1Gbps links. Totally, this platform comprise 2 696 links. A scale down version of the platform is depicted on Figure 4.6. The latency of each link is fixed to 0.2ms which is the average latency measured between two Grid'5000 internal nodes. The platform is set with the energy consumption of 1Gbps/10Gbps links referenced in the literature [START_REF] Sivaraman | Profiling per-packet and perbyte energy consumption in the NetFPGA Gigabit router[END_REF][START_REF] Cornea | Studying the energy consumption of data transfers in Clouds: the Ecofen approach[END_REF].

The simulation scenario is defined as follows. To avoid bias, we generate randomly between 10 to 400 external client requests. Each request is modeled using a 1MB TCP flows. The requests are generated and arrived simultaneously to the data center by the 8 core nodes. Next, the flows are spread randomly among the different aggregation switches and then reach the servers. Finally, the servers handle the requests and answer the clients. The experiments are launched on both simulators, SimGrid and ns-3 to compare their energy consumption estimation and also their performance in terms of execution time and memory usage. For each point of the simulation, we run 10 different experiments using different random seeds to better estimate the accuracy of our proposition.

The energy and scalability results are shown in Figure 4.7. The energy consumption results show that we have similar predictions on both simulators. The homogeneous model provides similar results to ns-3 with ECOFEN. Even in the worst cases, it still predicts energy values in the ECOFEN confidence interval. Using the same method provided by the Equation 4.7, we computed the ARE between SimGrid and ECOFEN. The homogeneous model exhibits an ARE lower than 4%, which is a reasonable accuracy regarding its level of granularity. Performance and scalability results are also shown on Figures 4.7b higher on ns-3 than on SimGrid. In fact, for 258 requests, ns-3 takes more than 12 hours against only 6 minutes for 897 requests on SimGrid. This is why we stopped ns-3 experiments earlier than SimGrid ones. On this example, SimGrid is more than 120 times faster than ns-3 with ECOFEN. Similarly, the memory usage is also reduced: for 258 requests ns-3 requires 3GB of memory whereas SimGrid uses at most 169.08MB. It is logical since flow level simulators do not model every packets that are transferred from one host to another. Hence, their memory footprint and their computational overhead are drastically reduced. In this case, SimGrid uses 17 times less memory than ns-3.

Conclusion

In this chapter, we proposed a network energy model for flow based simulators. We showed that classical models have to be adapted for flow-based simulators due to their coarse-grained nature.

To evaluate these energy models, we performed microbenchmark experiments. Their results show that FLSs can estimate the wired energy consumption with an accuracy close to PLSs. Additionally, we demonstrated that a fine grain modeling of platforms energy heterogeneity is not required to have accurate energy estimations. We also conduct data center network simulations which comprise 2 696 links. We were able to obtain accurate results with less than 4% of error and with a simulation duration 120 times smaller. This realistic use case highlighted how the model can be used by the scientific community on large-scale platforms. However, even if our model provides accurate predictions for large-scale platforms and high bandwidth applications, it has some limitations. Indeed, it cannot be used for high precision measurements related to low-bandwidth applications. First, we assumed that every packets has a size equal to the MTU. Yet, in reality Ethernet packets size can range from 64 bytes up to the MTU. This can leads to inaccurate energy consumption predictions. Second, since our model is dedicated to FLS, it inherits from their accuracy and thus could not be used for high precision measurements such as bit flip effects or scenario with small variation of packet exchange (accurate protocol comparison, etc.). Still, the model can be used for wide variety of large-scale wired network platforms. Its implementation is open-source and available online [START_REF] Guegan | A Large-Scale Wired Network Energy Model for Flow-Level Simulations[END_REF].

This contribution allows to get closer to the end-to-end network energy consumption simulation. Since this model allows for wired energy consumption estimations, it is possible to use it for data center and ISP simulations. The logical next step towards our goal is to provide a scalable wireless performance model that could be used by devices located at the edge of the network. As discussed in Section 2.1.1, future IoT platforms will be composed of thousands of nodes communicating over the network. A large part of these nodes are using wireless technologies and Wi-Fi is one of the most used in today's terminals [START_REF]Cisco Visual Networking Index: Global Mobile Data Traffic Forecast Update[END_REF]. Moreover, its usage is expecting to become more and more intensive. In the last chapter, we proposed a wired network energy model suitable for large-scale experiments. The goal was to provide a model to study various parts of the end-to-end network such as Cloud, ISP and edge. In this chapter, we propose a scalable Wi-Fi performance model to study the wireless communications at the edge of the end-to-end network. As presented in Section 2.2, this work is a required step to study the Wi-Fi energy consumption. model and presents the Wi-Fi model along with its integration into SimGrid. Next, we evaluate the proposed model in Section 5.3 followed by a discussion in Section 5.4. Finally we will conclude in Section 5.5.

Context and Problem

Conducting efficient Wi-Fi network simulations is not a trivial task. We have seen in Section 2.3.4 that current Flow-Level Simulator (FLS) do not propose wireless performance models. Indeed, FLS target efficient wired network simulation and to the best of our knowledge, no Wi-Fi models have been proposed for FLS. Still, Wi-Fi simulations are possible using Packet-Level Simulator (PLS) such as ns-3, Komondor, OMNET++, etc. These Wi-Fi models are designed for accurate simulated time predictions. They implement many features of the Wi-Fi standards such as Ad-Hoc and Infrastructure models, accurate Distributed Coordination Function (DCF) function, rate adaptation, etc. Additionally, these Wi-Fi models are coupled to different physical models to account for wireless channel conditions as presented in Section 2.2.3. Consequently, the fine-grained nature of existing Wi-Fi models leads to scalability issues. Hence, current network simulators are not scalable enough to simulate Wi-Fi for large-scale platforms [START_REF] Barrachina-Munoz | Komondor: a Wireless Network Simulator for Next-Generation High-Density WLANs[END_REF]. Most of them could not simulate more than a hundred of Wi-Fi nodes in a reasonable amount of time. As an example, in our end-to-end network study in Section 3 we faced scalability issues in ns-3 related to Wi-Fi simulations for a low-bandwidth application. Still, current use cases can involve high bandwidth scenarios as presented in Section 2.1.2. This pushes the scalability of current PLS to their limits even on simple network platforms.

In this chapter, to fill this gap between existing network simulators and real Wi-Fi network scenarios, we propose an efficient Wi-Fi model for large-scale platform simulations. This model aims at predicting the performance of a Wi-Fi cell in infrastructure mode. Thus, this model strives to account for the overall effects of the Distributed Coordination Function (DCF) allocation mechanism on the Stations (STAs) communication performance. However, to achieve efficient simulations, we neglect the following features of the actual Wi-Fi models:

• Ad-hoc mode • Wireless channel models (path-loss, multi-path fading, etc.)

• Fine Distributed Coordination Function (DCF) behavior (RTS CTS mechanism)

• Modulations and signal properties (bandwidth, Coding Rate, etc.)

Similarly to the wired energy model detailed in Section 4, we propose to implement this Wi-Fi model into SimGrid. By doing so, we are extending the capabilities of SimGrid towards the end-to-end network energy framework as depicted on Figure 1.2.

An Efficient Flow-Level Wi-Fi Model

Our development of a coarse-grained Wi-Fi performance model suitable for flow-level network simulation is divided in two steps. First, a full understanding of the targeted simulation environment is required to clearly identify the scope of the final model. Then knowing this scope, it is possible to start defining the model. Thus, this section introduces the foundations of the Sim-Grid bandwidth sharing model. Next, the Wi-Fi bandwidth sharing model is proposed based on this preliminary study. Finally, an integration of the Wi-Fi model in the SimGrid bandwidth sharing model is given.

The core of SimGrid LMM Solver

The bandwidth allocation model is the heart of a flow-level network simulator. It ensures accurate time predictions. Since many predicted metrics are based on time predictions, the bandwidth allocation model of a FLS should be correctly designed. In SimGrid, this job is achieved by the Linear MaxMin (LMM) solver in charge of allocating the bandwidth for each communication that occur during the simulation [START_REF] Robert | Scheduling for Large Scale Distributed Computing Systems: Approaches and Per-formance Evaluation Issues[END_REF]. The LMM solver is composed of an inequation system with variables and constraints. In this system, let C r be the constraint associated with the inequation r, ρ i be the variable i and finally a r,i the coefficients of the inequation r associated to the variable i. Then, the inequation system can be written as follows:

                                           i using link 1 a 1,i × ρ i ≤ C 1 . . . . . . i using link r a r,i × ρ i ≤ C r . . . . . . i using link m a m,i × ρ i ≤ C m
Thus, each link is represented by an inequation. The variables ρ i represents the effective bandwidth (also called flows) to be allocated and the constraints C r represents the capacity (bandwidth or allocable data rate) of each links. In addition, the coefficients a r,i can be applied to each variable. In classical network simulations, these coefficients can be used to model backward acknowledgments. Otherwise, they are equal to 1. Finally, each variable can be associated with a weight w i . Weights prioritize flows among others and provide a way to model phenomenons such as RTT-Fairness. To solve the system, we have to maximize the bandwidth allocation starting from the most constrained inequation until we reach the less constrained one. Thus, to characterize how constrained an inequation is, we should introduce the load r = Cr i using r a r,i w i associated with the inequation n. Consequently, the next inequation to be solved is the one who minimizes r . Finally, to solve a given inequation, each flow will have a resource allocation value of ρ i = r w i . However, when a given ρ i is already fixed, the constraint C r of every inequation where ρ i is involved should be updated with C r = C r -a r,i × ρ i . A complete overview of the LMM solver is proposed by Arnaud Legrand in [START_REF] Robert | Scheduling for Large Scale Distributed Computing Systems: Approaches and Per-formance Evaluation Issues[END_REF]. Knowing these internals related to the SimGrid LMM solver, we are able to understand the conceptual choices behind the following Wi-Fi model.

The Flow-Level Wi-Fi Model

In a real wireless system, there is a lot of parameters that leverage communication performance. In fact, stations throughput highly depends on the communication channel. Several phenomenons such as signal-to-noise, interferences, path loss, multi-path fading have an impact on the communication performance. Our Wi-Fi model aims at neglecting all these physical phenomenons while keeping good prediction capabilities and achieving high performance simulations. The goal is to have a good representation of the Distributed Coordination Function (DCF) behavior on ideal channel conditions. To this end, out of any physical phenomenons, there is mainly two factors that leverage the Wi-Fi bandwidth allocation. The 802.11 specify that Wi-Fi stations transmit signal at a given rate r i . This rate is defined by the physical layer capabilities of the stations and the access point. To communicate, each STA accesses the medium for a given duration called communication slot. Thus on a given time period called time slot, when a station is not using its communication slot, its resources should be redistributed among the other stations for the current time slot. . However, as explained in Section 2.2.3, DCF tends to share the medium equally among the stations by forcing them to wait a random backoff time after each packet transmission. Since the backoff time is uniformly chosen [START_REF] Bianchi | Performance analysis of the IEEE 802.11 distributed coordination function[END_REF] for all the stations, this leads to a fair sharing of the medium by the stations in terms of the amount of data d i . Thus, we can have ∀i, j ∈ (1, ..., n), d i = d j = d and thus ∀i ∈ (1, ..., n), ρ i = cste. Therefore, system behave as if it had a virtual capacity C fairly shared between the n flows such that:

C = n i=0 ρ i = n × d T = n × d n i=0 d r i = n n i=0 1 r i = 1 1 n n i=0 1 r i (5.1)
This equation allows to easily embed the Wi-Fi sharing characteristics into the max-min sharing implemented in SimGrid for wired networks.

However, as said previously, depending on the simulation platform and scenario, many flows can be already fixed by other constraints. Lets suppose that the STA1's flow (noted ρ f ) represented in Figure 5.1 is fixed such that ρ f < C n . Such a scenario can occurs if the receiver of the STA1's flow is not able to received as fast as STA1 can transmit. This scenario is represented on Figure 5.2. In that case, the non-fixed flows have a greater time to communicate and from their perspective, the antenna will behave as if it had a new capacity C fairly shared among the remaining flows. Let us define d f as the amount of data sent by the fixed flow such that

d f = d. Since t f = d f r f and ρ f = d f
T we have:

T = T + t f = T + d f r f = T + T × ρ f r f hence T = T 1 - ρ f r f
Let us define d as the amount of data that can be sent by the remaining STAs. Since we have:

C = n i=0 ρ i = ρ f + C = d f + (n -1)d T
From the perspective of the remaining flows, this capacity is such that:

C = n i=0 i =f ρ i = (n -1)d T = (n -1)d T 1- ρ f r f = (n -1)d T × 1 - ρ f r f = 1 1 n-1 n i=0 i =f 1 r i × 1 - ρ f r f
In the general case, if we define I as the set of flows that remain to be fixed and F the set of fixed flows, we can generalize the expression above to any number of fixed flows with:

C = 1 1 |I| i∈I 1 r i ×   1 - f ∈F ρ f r f   (5.2)
This last equation explains how the remaining virtual capacity of the antenna should be updated in the max-min algoritm of SimGrid whenever the bandwidth of some flow are fixed by contention on other resources. As expected, this model is easy to instantiate compared to packet-level Wi-Fi models. As expected, this model is easy to instantiate and expected to be very fast compared to packet-level Wi-Fi models. This model only requires few parameters which are the rate of each STA (r i ).

Integration Wi-Fi model into SimGrid

The last section defines the Wi-Fi model in terms of physical rate r i and fixed flows. In this section we propose an integration of the model expressed by the Equation 5.2 into SimGrid. An elegant way to fulfill this goal is to reuse the actual SimGrid LMM solver detailed previously instead of creating a dedicated Wi-Fi LMM solver. This has several benefits. First, it minimizes the amount of additional source code introduced by the model. Second, it allows for easier multi-model simulations by combining wired and Wi-Fi models in the same simulation. Lets define ρ i as the effective bandwidth allocated to the station i. According to the Equation 5.2, ρ i can be expressed as:

ρ i = C × 1 |I| = 1 i∈I 1 r i ×   1 - f ∈F ρ f r f  
Using the notations of Section 5.2.1 and define C as the constraint used by the Wi-Fi cell inequation, we can impose that ∀i ∈ (1, ..., n), w i = 1, C = 1, a i = 1 r i . In the case of a fair share of this constraint, we will get:

ρ i = C × 1 a i = 1 i∈I 1 r i
Which is what we want. If there are fixed flows, meaning F = {∅}, the new sharing is computed as follows:

ρ i = C × 1 a i =   1 - f ∈F a f ρ f   × 1 i∈I 1 r i =   1 - f ∈F ρ f r f   × 1 i∈I 1 r i = C × 1 |I|
The modification to integrate the WiFi model with the Wired model is thus minimal as it only requires to change the instanciation (the a i , w i and the C) and the way the residual capacity is updated. Actually, in this model, the C represents the fraction of channel time that can be shared between the flows. This implementation method suggests that Wi-Fi cells are modeled by a specific type of links called Wi-Fi links. A given link has an associated range of communication rates available to the STAs that corresponds to the differents MCS configurations. Then, each STA that are part of the same Wi-Fi cell shares the same link and uses one of the available rates to communicate. Thus, this integrated model requires to initialize two parameters namely the list of communication rates for the Wi-Fi cell and the actual communication rate of each STA.

Validation

In the previous section, we presented the coarse-grained Wi-Fi model implemented into Sim-Grid. In this Section, we propose a validation process to assess the model in terms of accuracy and scalability. First, we present the methodology used for the validation. Then, a calibration step is proposed prior to the experiments. Finally, we conduct an analysis of the results.

Methodology

As presented in Section 2.3.3, several packet-level network simulators are able to simulate Wi-Fi communication. In particular, ns-3 is well known for its 802.11 wireless models which have been used in numerous of scientific works [START_REF] Maity | TCP Download Performance in Dense WiFi Scenarios: Analysis and Solution[END_REF][START_REF] Barrachina-Munoz | Komondor: a Wireless Network Simulator for Next-Generation High-Density WLANs[END_REF][START_REF] Arbabi | Highway mobility and vehicular ad-hoc networks in ns-3[END_REF]. To this end, we propose to use a similar approach than the one used in Chapter 4 by comparing our Wi-Fi performance model to the one of ns-3. In fact, this procedure is also used in similar work [START_REF] Barrachina-Munoz | Komondor: a Wireless Network Simulator for Next-Generation High-Density WLANs[END_REF] related to Wi-Fi simulations.

To achieve this comparison, we develop two sets of experiments. The first set relies on an extension of SimGrid that implements the Wi-Fi model proposed in Section 5.2 by extending the SimGrid LMM with the method presented in Section 5.2.3. The second set of experiments is based on ns-3 which implements the IEEE 802.11n standard. We choose to validate our model against this standard since it is one of the most used and experienced by current network simulators such as ns-3 [START_REF] Ravindranath | Performance Evaluation of IEEE 802.11ac and 802.11n using NS3[END_REF], OMNET++. Still, current IEEE 802.11ax remains compatible with the IEEE 802.11n which ensure its applicability in future networks. To validate our model, we compare the following metrics of each simulator:

• Simulation Time to compare time prediction on given data volumes to transmit (accuracy)

• Throughput to ensure bandwidth sharing consistency (accuracy)

• Execution Time to measure simulation efficiency (scalability)

• Memory Usage to compare both simulators memory footprint (scalability)

Experiment Settings

Prior to the validation process, it is important to carefully instantiate both network simulators. In particular, packet-level simulators comes with numerous parameters that are important to consider to have meaningful validation results. Lets first focus on the ns-3 simulator. At the physical and MAC layer, IEEE 802.11n can be configured in many different ways as stated in Section 2.2.3. Thus, what matters in our case is that:

Are we able to predict IEEE 802.11n performance for a given configuration ?

To answer this question, we choose a reasonable IEEE 802.11n configuration which is described in Table 5.1. First, we use the IEEE 802.11n at 5GHz with a channel bandwidth of 40MHz (with channel bonding) such as in [START_REF] Abu-Tair | Impact of Cell Load on 5GHz IEEE 802.11 WLAN[END_REF] along with a guard interval of 800ns. Second, we choose a Modulation Coding Scheme of 3 which gives a theoretical throughput of 54Mbps. This implies the use of 1 spacial stream with a 16-QAM modulation at a coding rate of 1/2. In addition, to avoid any rate change during simulations, we disable the rate adaptation algorithm by using a constant rate model. For the same reasons, we also set the QoS to best effort. Then, to ensure stable communication throughputs, we enable RTS/CTS mechanism to mitigate the effects of hidden/exposed nodes. Finally, we keep the default aggregation mechanisms [START_REF] Bhanage | AMSDU vs AMPDU: A Brief Tutorial on WiFi Aggregation Support[END_REF] which implies no MAC Service Data Unit (MSDU) aggregation (AMSDU) aggregation but provides MAC Protocol Data Unit (MPDU) aggregation (AMPDU) up to 65 535 bytes. rate according to the rate delivered by ns-3 with the actual configuration. With this in mind, the next step is to pursue with the microbenchmarks simulations to examine the validity of our model.

Microbenchmarks description

The validation process consists in simulating several network scenarios (microbenchmarks) and compare both simulators outcomes on several metrics. Thus, we design 3 parametric platforms with different communication schemas (or flows). These platforms are depicted on Figure 5.4.

The first platform is noted P1. It is composed of several Wi-Fi stations communicating with an AP. Stations are distributed in circle, homogeneously (the angle formed with the AP and two consecutive stations is always the same) around the AP at a distance of 15 meters as used in the calibration process. This platform can be used with 1 to n stations as shown on Figure 5.4a. We use this platform as reference point. The idea is that, as long as simulations give valid results for this scenario, we can consider that our simulators are correctly instantiated. Thus, if for any reason, P2 or P3 experiments failed, it will not be the result of a wrong model configuration but rather due to a wrong scenario implementation or an invalidation of the model. The second platform is noted P2. Spacial location and distribution of the stations and AP are similar to P1 but stations are now communicating by pairs. Thus P2 can be configured to be used with 2 to 2×n stations as shown on Figure 5.4b. Communication between 2 stations occurs through the AP. These communications can be configured in two ways. Either unidirectional (STA A to STA B) or bidirectional (STA A to STA B and STA B to STA A). This scenario introduces more channel accesses and challenge the model bandwidth sharing capabilities.

Finally, the third platform P3 is an hybrid platform mixing P1 and P2. Similarly to P2, stations are communicating by pairs. But, for each pair of station, an additional station is added which communicate with the AP (as P1). Thus, P3 is using 3×n stations as depicted on Figure 5.4c.

Totally, these three platforms lead to 5 differents configurations:

• P1 unidirectional (P1U) • P2 unidirectional (P2U) • P2 bidirectional (P2B) • P3 unidirectional (P3U) • P3 bidirectional (P3B)
For each of these 5 configurations simulations run with 4 different numbers of station. Each station is sending data ranging from 10Mb to 50Mb. In addition, each simulation on ns-3 is running with 20 random seeds (used in the loss models) to increase the results diversity. All these simulation parameters are summarized in Table 5.2. By combining all the parameters, we reach a number of 12 000 simulations. Since these simulations involve 6 000 packet-level simulations with wireless communications, the microbenchmarks cannot be run on a single machine. Thus, all the simulations were run on Grid'5000 which is an experimental test-bed detailed in Section 2.1.1. The simulations are spread on 50 machines on the Rennes Grid'5000 site. The results gathered from this simulation campaign are analyzed and interpreted in the remaining of this section.

Accuracy Analysis on microbenchmarks

The results related to time and throughput predictions for the P1U platform are shown on Figure 5.5. The Figure 5.5a shows the simulated time predictions according to the amount of data sent by 1, 2, 5 and 15 stations. This figure shows a linear relation between the simulated time and the amount of data sent by each station. This linearity is possible thanks to the homogeneous positions of the stations around the AP. In fact, this station distribution allows for a fair sharing of the wireless channel since each station is in the same transmission conditions. In addition, the signal emitted by the stations reaches the access point with the same theoretical power. To measure the accuracy of the model, we used the metric presented in Section 4.4 called the Average Relative Error (ARE). The time prediction results show that our model does accurate predictions on the scenario with a single STA in the Wi-Fi cell. In this scenario, generated data shows an ARE of 0.18% for time prediction. This allows to conclude that our calibration process was well conducted. However, while the number of station is increasing, our model begins to diverge from the ns-3 model. The Table 5.3 presents the time and throughput ARE between SimGrid and ns-3. The results show that ARE reaches up to 26% with 15 stations. The Figure 5.5b shows the overall Wi-Fi cell applicative throughput predicted by each simulator. These results confirmed the inaccuracies related to time predictions. Our model has difficulties in predicting the right throughput. Indeed we can see that the throughput is clearly overestimated by our model which leads to inaccurate simulated time predictions. The Table 5.3 shows similar trends for the other scenarios. Assuming that our model is valid, since we know that it is correctly instantiated it means that an additional model in ns-3 leverages the Wi-Fi throughput and impact our results. The data provided by Figure 5.6 shows the total amount of dropped packets in ns-3 during the Transmission (Tx) and the Reception (Rx) for the P1U scenario. receiver side which leads to an over-approximation of the bandwidth by SimGrid. Since, our model accuracy seems to be inversely proportional to the number of stations, we can deduce that this issue is caused by interferences. Consequently, the interference model of ns-3 has a non negligible impact on the predicted bandwidth.

Thus, we run the exacts same scenarios while inhibiting the additive power interference model of ns-3 with the aims of isolating the effects of the Wi-Fi DCF. By doing so, the signal transmitted by the STA will not appear to interfere together on the receiver side which leads to an increase in the overall Wi-Fi cell bandwidth. Thus, we can expect to reach the bandwidth estimated by our model. These results for the P1U scenario are depicted on Figure 5.7. They show a significant improvement in the predictions accuracy. The P1U scenario has an ARE lower that 6% with 15 stations. The results for all the scenarios are provided in Table 5.5. All the microbenchmarks scenarios have improved in terms of time and throughput prediction accuracy. Nevertheless, it is difficult to fully characterize the evolution of the accuracy on very high bandwidth applications. Indeed, Figure 5.8 shows the evolution of the average relative error on both scenarios P1U and P3U. The results show that we cannot exhibit a clear tendency regarding the evolution of the accuracy on very large data transfers. But still, since both simulators have a linear time prediction, we can be confident that the accuracy will still be reasonable. In addition to predictions accuracy, the Figure 5.9 shows a significant reduction of packet drop for the P1U scenarios while using multiple stations. The Table 5.4 provides numerical results related to this reduction of packet drop. We can conclude that our model is able to predict the Wi-Fi bandwidth sharing mechanism with good accuracy while neglecting the interferences on the receiver side.

Scalability Analysis on microbenchmarks

To demonstrate the scalability of our model, we keep track of the execution time and the peak memory usage of both simulators for every simulation. is independent of the amount of data sent during the simulation. Indeed, since the network capacity is fixed by the initial platform, the amount of data exchange over the network cannot exceed this limit for a given simulation.

Discussion

The results for the microbenchmarks experiments show that our model is able to predict the Wi-Fi DCF bandwidth allocation mechanism on various scenarios without interferences. In addition, this model offers better scalability in terms of execution time and memory usage compared to packet-level Wi-Fi models. Still, several validation scenarios and research axes should be investigated:

Fixed flows scenarios: Our microbenchmarks did not validate scenario involving fixed flows. Indeed, fixed flows occur while a station communication rate is not limited by the Wi-Fi cell capacity itself (for example if the station communicates with a node located outside of the cell). In that case, the overall cell bandwidth allocated to the other stations should increase. Thus, experimentations with fixed flows should highlight this phenomenon.

Large scale experiment: Despite that our model were validated on several microbenchmarks scenarios, it could be interesting to validate it against more realistic scenarios. This could involves multiple Wi-Fi cells along with wired communications and realistic network traffic. In this way, it will reinforce the confidence in the model and provide better insight on its scalability capabilities.

Rate adaptation:

In a real Wi-Fi deployment, the Access Point could handle stations with heterogeneous communication rates. Moreover, common operating systems such as Linux offer Wi-Fi rate adaptation algorithms such as Minstrel to optimize the communication performance. These heterogeneous rates and rate adaptation scenarios were not considered in our experiments since we used a fixed IEEE 802.11n configuration (using a given MCS). Thus, extensive validation experiments should be conducted in this regards.

Interference model: These microbenchmarks experiments pinpoint that an additional coarse-grained interference model is needed to predict the Wi-Fi performance correctly. In reality all the Wi-Fi cells are subject to interferences and thus this point should be considered in the future.

Conclusion

Today's Wi-Fi simulation models lack for scalability. Thus they cannot be used for large-scale end-to-end network energy studies. As a response, we proposed a scalable Wi-Fi bandwidth sharing model to approximate the Wi-Fi DCF bandwidth sharing mechanism in infrastructure mode. Next, we proposed an implementation of the model into the SimGrid LMM solver. Then we validated the model against microbenchmarks scenarios. The results show good predictions capabilities with a average relative error less than 6% for all the considered scenarios. Additionally, our model offers great scalability features and outperforms the performance of the common packet-level simulator ns-3 in terms of execution time and memory usage. As discussed previously, an additional validation campaign should be conducted regarding rate adaptation, large-scale experiments, fixed flows and interferences.

This Wi-Fi performance model was proposed with the aim of studying the end-to-end networks energy consumption. This model can be used as a wireless communication model for the edge part of the network as presented on Figure 3.1b but it is currently limited to ideal channel with no interferences. To estimate the energy consumed by the Wi-Fi devices, an additional energy model is required. By combining our performance and Wi-Fi energy model, we should be able to predict the energy consumed by Wi-Fi communications as expressed in the Equation 2.1. This perspective opens up new avenues for studying IoT scenarios on very large-scale. Regarding large-scale networks energy consumption studies of Fog infrastructures, simulators offer a great alternative to real experimentations. Simulation-based studies are common in the literature. However, current simulators and models were not scalable and versatile enough for large-scale studies. Our solution is to propose scalable models in a single simulator to make these network energy studies possible at large-scale, from the IoT devices to the Cloud servers hosting their applications.

Conclusion

Fog computing and IoT paradigms lead to an increase in complexity of network platforms. Indeed, modern network platforms are composed of many heterogeneous nodes located at the edge of the network with a variety of network footprints and nodes located at the core. Moreover, the network traffic is increasing with the development of high bandwidth applications such as video streaming. This evolution of the Internet usage impacts the energy consumption of networks. These additional connected objects and Fog processing nodes are new ICT devices energy consumers. With the aim of reducing their energy consumption and their impact on the overall network, scientists have to study these large-scale platforms. However conducting real experiments remains difficult since platforms are very large. The approach chosen in this thesis was to study large-scale platforms by mean of simulations which offer several benefits such as time, money saving and experiments reproducibility.

In the first place, we proposed an end-to-end energy study. Besides providing an interesting end-to-end energy analysis, this study revealed multiple flaws raised by current experimentations tools. First, none of them is able to cover the range of platforms deployed in today's Internet such as IoT, Fog, ISP networks and Cloud. Hence, the experimentation protocol has to be divided in several parts (one for each platform). Then, each of these platforms has to be studied separately using differents experimentation tools. Morever, in real networks these platforms are interacting together. This leads to difficulties studying the interactions between the platforms and having continuous communication flows between the IoT platforms up to the Cloud servers on a common ISP network. Consequently, network communications have to be piped between each part of the experimentation protocol to obtain consistent results. Regarding network simulations, our study used a common PLS called ns-3 which suffers from scalability issues. Thus we were not able to pursue our end-to-end study on large-scale IoT scenarios.

To solve all these issues, we proposed to extend a FLS called SimGrid by providing scalable network models for energy and wireless communication studies. Our first model was a wired network energy model dedicated to wired large-scale network platforms. This model can be instantiated with classical packet-level model parameters such as the energy consumption values per processed byte and per packet. We validated this model by mean of simulations. We compared our model to the results from the ECOFEN module of ns-3. These results showed that our model has accurate predictions along with high scalability capabilities. With this model we are now able to study the energy consumption of large-scale network platforms which involve wired communications such as ISP networks and data centers in a single simulation tool.

To extend the studies up to the edge of the network, we proposed a coarse-grained Wi-Fi performance model for SimGrid. This model strives to estimate the performance of Wi-Fi in Infrastructure mode where stations can communicate through an AP. Common packet-level Wi-Fi models require to setup many parameters while our model can be configured by specifying only the communication rate of the STA (known as MCS). This reduction of complexity has led to a highly scalable Wi-Fi model. We also proposed a first validation step by mean of network simulations. We compared the results given by the 802.11n model of ns-3 to our model. These first results showed accurate performance predictions under ideal wireless communication channel conditions (without interferences). Still, our model does not take into account the rate adaptation feature of common Wi-Fi devices. In addition, our study was limited to microbenchmarks and requires more intensive validation scenarios. Yet, it is a first step toward efficient Wi-Fi simulations and we are now able to simulate Wi-Fi cells under ideal conditions at large-scale and in an efficient manner.

These contributions allow for larger network energy studies and we are now close to propose a complete end-to-end network energy simulation framework. Cloud and ISP network energy consumption can be studied using a single network simulator. With an additional Wi-Fi model validation regarding fixed-flows and the development of an interference model we will be able to study the entire network from the IoT, the Fog, the ISP network and the Cloud. Still, our work also leads to many future work in the domain.

Future Directions

Wi-Fi Enhancement

Our current Wi-Fi model faces limitations. The experiments conducted in our study showed that the Wi-Fi model is inaccurate on scenarios with interferences. To this regard, proposing an interference model for Wi-Fi in Infrastructure mode is an interesting future direction to consider. Indeed we have seen that the accuracy of our model is correlated with the number of stations that communicate through the wireless channel. Thus, grounding the interference model on the number of stations would be a good starting point toward accurate performance predictions.

In addition, Wi-Fi energy consumption prediction is an interesting feature to introduce. Indeed, currently our simulation framework proposes CPU and wired network energy model but lack of a wireless energy model. Similarly to the wired network energy model, this new model would be based on packet-level parameters which involve byte and packet energy consumption values. Then, based on performance predictions of our Wi-Fi model it would be possible to predict the energy consumption of Wi-Fi communications and thus provide a complete end-toend network energy framework.

Support for mobility

In today's networks it is common that wireless technologies involve mobility. In typical PLS, this feature is insured by the propagation loss model and rerouting mechanisms. Depending on the distance from the STA to the AP, the propagation loss model will modulate the strengh of the signal received on the receiver side accordingly. However, due to their coarse-grained nature FLSs do not provide such a model. One way to approach flow-level mobility would be to leverage the STA communication rate according to its distance from the AP. Thus, the farest not subject to validation. Indeed, wireless communications are usually modeled by a delay function while the wired energy consumption is often neglected. Thus, providing an end-toend simulation framework would speed up their experimental process while providing validated models and increasing their simulations flexibility. Still, S. Tahir et al. [START_REF] Tahir | An energy-efficient fog-tocloud Internet of Medical Things architecture[END_REF] used iFogSim as an experimental tool in an end-to-end scenario that involved Bluetooth communications. Thus, the accuracy of such study can be greatly improved with an end-to-end simulation framework that provides the proper models. S. Sarkar et al. [START_REF] Sarkar | Serverless Management of Sensing Systems for Fog Computing Framework[END_REF] proposed a real experimentation deployment with accurate measurements to study Fog infrastructure latencies. A similar approach can be used to instantiate simulations. Using an end-to-end network simulation framework to study the energy and the performance could greatly benefits to the research community. Ideally, on the long term such a framework should meet the following requirements:

• Accuracy (containing validated performance and energy models)

• Scalability (handling large-scale platforms and high bandwidth scenarios in a reasonable amount of time)

• Versatility (suitable for IoT, ISP networks and Cloud)

• Adaptability (including Ethernet, Wi-Fi, 802.15.4, LoRa, etc. with easy means to extend for future technologies)

• Simplicity (models should be simple to use and to instantiate) Title: Scalable end-to-end models for the time and energy performance of Fog infrastructures Keywords: simulation,network,energy,model,simulator,SimGrid,Wi-Fi,packet,flow Abstract: Fog Computing designates the migration of the computing and storage resources of the Cloud towards the edge of the network. This resources migration allows to reduce the user's nodes latency to answer to the evolution of the Internet usages. In parallel, the number of terminal is increasing with the development of the Internet Of Things. This infrastructures growth leads to an increase of the global energy consumption related to network infrastructures. However, this energy consumption is distributed and involved many actors such as: connected objects, local network, Internet Service Providers, Fog and Cloud infrastructures. Thus, it is difficult to study the impact of the connected objects growth on the infrastructures that composed the Internet of Things. The goal of this thesis is to propose models to study the energy consumption of large-scale Fog infrastructures in an efficient and reproducible manner. The proposed models have been integrated in the SimGrid simulation framework in order to be validated and spread.

2. 12

 12 Difference between a packet-level and flow-level communication. . . . . . . . . . 3.1 Overview of the complete Internet Of Things (IoT) network architecture. . . . . 3.2 Grid'5000 experimental setup. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Analysis of the variation of the number of sensors on the IoT/Network part energy consumption for a transmission interval of 10s. . . . . . . . . . . . . . . .3.4 Server power consumption multiplied by the Power Usage Effectiveness (PUE) (= 1.2) using 20 sensors sending data every 10s for various Virtual Machine (VM) memory sizes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.5 Server energy consumption multiplied by the PUE (= 1.2) for sensors sending data every 10s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 Server energy consumption multiplied by the PUE (= 1.2) for 50 sensors sending requests at different transmission interval. . . . . . . . . . . . . . . . . . . . . . 3.7 End-to-end network energy consumption using sensors interval of 10s. . . . . . . 4.1 Homogeneous model on packet/flow level simulators. . . . . . . . . . . . . . . . 4.2 Heterogeneous model on packet/flow level simulators. . . . . . . . . . . . . . . . 4.3 Overview of the microbenchmarks scenarios. . . . . . . . . . . . . . . . . . . . . 4.4 Microbenchmarks energy consumption on platforms with homogeneous devices. .4.5 Microbenchmarks energy results on heterogeneous energy platforms. . . . . . . . 4.6 The three-tier data center platform used for the realistic use case simulations. The figure represents 1/8 of the original platform that contains 8 core routers and overall 192 × 8 servers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Real use case energy and scalability simulations results. . . . . . . . . . . . . . . 5.1 Example of a Wi-Fi communication time period T involving 3 Station (STA) communication slots. Each STA is communicating using its own data rate (r i ) according to its Modulation Coding Scheme (MCS) index such that r 1 = r 2 2 = r 3 4 . 5.2 Similar scenario than Figure 5.1 but with STA1's flow limited. t f represents the total communication slot duration of the STA1 while T represents the remaining duration on the time period T for the other STAs. . . . . . . . . . . . . . . . . . 5.3 Calibration experimentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Microbenchmarks parametric platforms. . . . . . . . . . . . . . . . . . . . . . . 5.5 Microbenchmarks results for P1U platform. . . . . . . . . . . . . . . . . . . . . . 5.6 Analysis of packet dropped during P1U simulations. . . . . . . . . . . . . . . . . 5.7 Microbenchmarks results for P1U platform without ns-3 additive power interference model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.8 Microbenchmarks average relative error evolution for P1U and P2U scenario without ns-3 additive power interference model. . . . . . . . . . . . . . . . . . . 5.9 Analysis of packet dropped during P1U simulations without the ns-3 additive power interference model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4. 1

 1 Overview the energy parameters used in the simulation. . . . . . . . . . . . . . . 5.1 Parameters of the ns-3 IEEE 802.11n performance model. . . . . . . . . . . . . . 5.2 Microbenchmarks simulation parameters. . . . . . . . . . . . . . . . . . . . . . . 5.3 Time prediction and throughput average relative error between SimGrid Wi-Fi model and ns-3 for each scenario. . . . . . . . . . . . . . . . . . . . . . . . . . . 5.4 Comparison of packet dropped during the P1U platform simulations in ns-3. . . 5.5 Time prediction and throughput average relative error between SimGrid Wi-Fi model and ns-3 for each scenario while disabling the ns-3 additive power interference model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.6 Scalability analysis of the P3B scenario. . . . . . . . . . . . . . . . . . . . . . . 6.1 Exemple of studies that can benefits from an end-to-end simulation framework. . ACRONYMS ALS Application-Level Simulator AP Access Point ARE Average Relative Error CDN Content Delivery Network CR Coding Rate DCF Distributed Coordination Function DES Discrete-Event Simulator DSL Domain Specific Language FLS Flow-Level Simulator HIL Hardware In the Loop HPC High Performance Computing ICT Information and Telecommunication Technologies IoT Internet Of Things ISP Internet Service Provider LMM Linear MaxMin MCS Modulation Coding Scheme MPDU MAC Protocol Data Unit MSDU MAC Service Data Unit MTU Maximum Transmission Unit OSI Open Systems Interconnection PLS Packet-Level Simulator PUE Power Usage Effectiveness Rx Reception STA Station TCP Transmission Control Protocol Tx Transmission UDP User Datagram Protocol VM Virtual Machine WLAN Wireless Local Area Network WSN Wireless Sensors Network

Figure 1 :

 1 Figure 1: Processus expérimental de la simulation.

Figure 1 . 2 :

 12 Figure 1.2: Simulation models required for end-to-end network energy consumption. The contributions of this thesis are labeled «Contrib ».

Figure 2 . 1 :

 21 Figure 2.1: IoT, Fog and Cloud.

Figure 2 . 2 :

 22 Figure 2.2: Netflix Open Connect deployment inspired by a recent publication [19]. ISP are Internet Service Provider deployment whereas IXP are Internet eXchange Point.

Figure 2 . 3 :

 23 Figure 2.3: Non-exhaustive representation of network IoT communication technologies using the TCP/IP model. This Figure is inspired from [36].

Figure 2 . 5 :

 25 Figure 2.5: Simple TCP connection based on the 4 last layers of the OSI Model.

Figure 2 . 6 :

 26 Figure 2.6: Ideal, real and proportional model of ICT devices power consumption.

Figure 2 . 7 :

 27 Figure 2.7: Wi-Fi 802.11 operating modes. Stations (STA) and Access Point (AP).

Figure 2 .

 2 Figure 2.8: Basic CSMA/CA medium access problems.

Figure 2 . 9 :

 29 Figure 2.9: Wi-Fi communication diagram between a station (STA) and an access point (AP) using the RTS/CTS handshaking mechanism.

  (a) BPSK. (b) QPSK. (c) 16-QAM.

Figure 2 . 10 :

 210 Figure 2.10: Constellation diagram of different Wi-Fi modulations with their Error Vector Magnitude (EVM) box.

Figure 2 . 11 :

 211 Figure 2.11: Example of a network platform as represented in typical PLS.

Figure 2 . 12 :

 212 Figure 2.12: Difference between a packet-level and flow-level communication.

" 3 . 1 49 3. 2 50 3. 3 51 3. 3 . 1 52 3. 4 53 3. 4 . 1 55 3. 5 58 3. 6

 3149250351315245341555586 If a simulator already does what you want it to do, there's a good chance you aren't asking the right questions." --Christos Kozyrakis [114] Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Characterization of low-bandwidth IoT applications . . . . . . . . Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . IoT Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.3.2 Network Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.3.3 Cloud Part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IoT and Network Power Consumption . . . . . . . . . . . . . . . . . . 53 3.4.2 Cloud Energy Consumption . . . . . . . . . . . . . . . . . . . . . . . . End-to-end Consumption Model . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

Figure 3 . 2 :

 32 Figure 3.2: Grid'5000 experimental setup.

Figure 3 . 3 :

 33 Figure 3.3: Analysis of the variation of the number of sensors on the IoT/Network part energy consumption for a transmission interval of 10s.

Figure 3 . 4 :

 34 Figure 3.4: Server power consumption multiplied by the PUE (= 1.2) using 20 sensors sending data every 10s for various VM memory sizes.

  (a) Average server energy consumption multiplied by the PUE (= 1.2). (b) Average sensors energy cost on the server hosting only our VM.

Figure 3 . 5 :

 35 Figure 3.5: Server energy consumption multiplied by the PUE (= 1.2) for sensors sending data every 10s.

Figure 3 . 6 :

 36 Figure 3.6: Server energy consumption multiplied by the PUE (= 1.2) for 50 sensors sending requests at different transmission interval.

Figure 3 . 7 :

 37 Figure 3.7: End-to-end network energy consumption using sensors interval of 10s.

Contents 4 . 1 63 4. 2 63 4. 2 . 1 A 63 4. 2 . 2 65 4. 2 . 3 66 4. 3 68 4. 3 . 1 68 4. 3 . 2 69 4. 4 70 4. 4 . 1 74 4. 5

 41632632163226523663683168326947041745 Context and Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Link based Wired Network Energy Model . . . . . . . . . . . . . . . Homogeneous model for flow-based simulators . . . . . . . . . . . . . . Heterogeneous model . . . . . . . . . . . . . . . . . . . . . . . . . . . . Methodology and Experimental Setup . . . . . . . . . . . . . . . . . Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Experimental setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Evaluation: validity, scalability and real use case . . . . . . . . . . Validity of the proposed models . . . . . . . . . . . . . . . . . . . . . . 70 4.4.2 Realistic use case . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

  (a) Homogeneous model on packet level simulators.(b) Homogeneous model on flow level simulators.

Figure 4 . 1 :

 41 Figure 4.1: Homogeneous model on packet/flow level simulators.

  (a) Heterogeneous model on packet level simulators.(b) Heterogeneous model on flow level simulators.

Figure 4 . 2 :

 42 Figure 4.2: Heterogeneous model on packet/flow level simulators.

Figure 4 . 3 :

 43 Figure 4.3: Overview of the microbenchmarks scenarios.

(a) 2

 2 hosts 1 link platform power profile (b) 4 hosts 3 links platform power profile (c) Dogbone platform power profile

Figure 4 . 4 :

 44 Figure 4.4: Microbenchmarks energy consumption on platforms with homogeneous devices.

  and 4.7c. The execution time is clearly

Figure 4 . 6 :

 46 Figure 4.6: The three-tier data center platform used for the realistic use case simulations. The figure represents 1/8 of the original platform that contains 8 core routers and overall 192 × 8 servers.

  (a) Overall data center power profile. (b) Simulations execution time.(c) Simulation memory usage.

Figure 4 . 7 :

 47 Figure 4.7: Real use case energy and scalability simulations results.

5 . 1 79 5. 2 81 5. 2 . 3 84 5. 3 85 5. 3 . 1 85 5. 3 . 2 86 5. 3 . 3 88 5. 3 . 4 90 5. 3 . 5 93 5. 4 99 5. 5

 51792812384385318532863388349035934995 Context and Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . An Efficient Flow-Level Wi-Fi Model . . . . . . . . . . . . . . . . . 80 5.2.1 The core of SimGrid LMM Solver . . . . . . . . . . . . . . . . . . . . 80 5.2.2 The Flow-Level Wi-Fi Model . . . . . . . . . . . . . . . . . . . . . . . Integration Wi-Fi model into SimGrid . . . . . . . . . . . . . . . . . . Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Experiment Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . Microbenchmarks description . . . . . . . . . . . . . . . . . . . . . . . Accuracy Analysis on microbenchmarks . . . . . . . . . . . . . . . . . Scalability Analysis on microbenchmarks . . . . . . . . . . . . . . . . Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

Figure 5 . 1 := r 3 4 .

 514 Figure 5.1: Example of a Wi-Fi communication time period T involving 3 STA communication slots. Each STA is communicating using its own data rate (r i ) according to its MCS index such that r 1 = r 2 2 = r 3 4 .

Figure 5 . 2 :

 52 Figure 5.2: Similar scenario than Figure 5.1 but with STA1's flow limited. t f represents the total communication slot duration of the STA1 while T represents the remaining duration on the time period T for the other STAs.

Figure 5 . 3 :

 53 Figure 5.3: Calibration experimentation.

  (a) Platform 1 (P1) with 4 STAs. (b) Platform 2 (P2) with 4 STAs. (c) Platform 3 (P3) with 3 STAs.

Figure 5 . 4 :

 54 Figure 5.4: Microbenchmarks parametric platforms.

( a )

 a Simulated time prediction of ns-3 and SimGrid for 4 different numbers of stations. (b) Overall Wi-Fi cell throughput prediction of ns-3 and SimGrid for 4 different numbers of stations.

Figure 5 . 5 :

 55 Figure 5.5: Microbenchmarks results for P1U platform. 96

Figure 5 . 6 :

 56 Figure 5.6: Analysis of packet dropped during P1U simulations.

  (a) Simulated time prediction of ns-3 and SimGrid for 4 different numbers of stations. (b) Overall Wi-Fi cell throughput prediction of ns-3 and SimGrid for 4 different numbers of stations.

Figure 5 . 7 :

 57 Figure 5.7: Microbenchmarks results for P1U platform without ns-3 additive power interference model. 99

  (a) Average relative error evolution on the P1U scenario. (b) Average relative error evolution on the P2U scenario.

Figure 5 . 100 Figure 5 . 9 :

 510059 Figure 5.8: Microbenchmarks average relative error evolution for P1U and P2U scenario without ns-3 additive power interference model. 100

Figure 5 . 10 :

 510 Figure 5.10: Analysis simulation duration of the P3B scenario.

Figure 5 .Figure 5 . 11 :

 5511 Figure 5.11: Analysis simulation peak memory usage of the P3B scenario.

6 . 1

 61 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 6.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.2.1 Wi-Fi Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.2.2 Support for mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 6.2.3 Support for other wireless technologies . . . . . . . . . . . . . . . . . . 104 6.2.4 Future research impact . . . . . . . . . . . . . . . . . . . . . . . . . . 104

6 Conclusion and Perspectives

  6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Wi-Fi Enhancement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.2 Support for mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Support for other wireless technologies . . . . . . . . . . . . . . . . . . . 6.2.4 Future research impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . Processus expérimental de la simulation. . . . . . . . . . . . . . . . . . . . . . . 1.1 Simulation experimental process. . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Simulation models required for end-to-end network energy consumption. The contributions of this thesis are labeled «Contrib ». . . . . . . . . . . . . . . . . .

	LIST OF FIGURES
	1
	Bibliography

2.1 IoT, Fog and Cloud. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Netflix Open Connect deployment inspired by a recent publication [19]. ISP are Internet Service Provider deployment whereas IXP are Internet eXchange Point. 2.3 Non-exhaustive representation of network IoT communication technologies using the TCP/IP model. This Figure is inspired from [36]. . . . . . . . . . . . . . . . 2.4 Data center energy consumption repartition according to an air conditioning study [42]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 Simple TCP connection based on the 4 last layers of the Open Systems Interconnection (OSI) Model. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Ideal, real and proportional model of ICT devices power consumption. . . . . . . 2.7 Wi-Fi 802.11 operating modes. Stations (STA) and Access Point (AP). . . . . . 2.8 Basic CSMA/CA medium access problems. . . . . . . . . . . . . . . . . . . . . . 2.9 Wi-Fi communication diagram between a station (STA) and an access point (AP) using the RTS/CTS handshaking mechanism. . . . . . . . . . . . . . . . . 2.10 Constellation diagram of different Wi-Fi modulations with their Error Vector Magnitude (EVM) box. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Example of a network platform as represented in typical PLS. . . . . . . . . . .

  5.10 Analysis simulation duration of the P3B scenario. . . . . . . . . . . . . . . . . . 97 5.11 Analysis simulation peak memory usage of the P3B scenario. . . . . . . . . . . . 98 LIST OF TABLES 2.1 Application-Level network simulators review. . . . . . . . . . . . . . . . . . . . . 2.2 Packet-level network simulators review. . . . . . . . . . . . . . . . . . . . . . . . 2.3 Flow-level network simulators review. . . . . . . . . . . . . . . . . . . . . . . . .

3.1 Simulations Energy Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Sensors transmission interval effects with 15 sensors. . . . . . . . . . . . . . . . . 3.3 Network Devices Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

  [START_REF] Jalali | Fog Computing May Help to Save Energy in Cloud Computing[END_REF], we propose the first scalable Wi-Fi communication model to estimate Wi-Fi communication durations on large-scale platform. We achieve this work by modeling the Wi-Fi bandwidth sharing allocation mechanism at a coarse-graine level. Finally, we conclude in Chapter 6 and provide future research directions.

	Chapter 2
	STATE OF THE ART

Contents 2.1 Overview of Today's Network Platforms . . . . . . . . . . . . . . . 18 2.1.1 Major Platforms Taxonomy . . . . . . . . . . . . . . . . . . . . . . . . 19 2.1.2 Large-Scale Platform Based Applications . . . . . . . . . . . . . . . . 21 2.1.3 Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.2 Simulation Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.1 Wired Performance Models . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.2 Wired Network Energy Model . . . . . . . . . . . . . . . . . . . . . . . 30 2.2.3 Wi-Fi Performance Model . . . . . . . . . . . . . . . . . . . . . . . . . 32 2.3 Experimentations and tools . . . . . . . . . . . . . . . . . . . . . . . 36 2.3.1 Computer Science Experiments . . . . . . . . . . . . . . . . . . . . . . 37 2.3.2 Application-Level Simulators . . . . . . . . . . . . . . . . . . . . . . . 38 2.3.3 Packet-Level Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . 40 2.3.4 Flow-Level Simulators . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Table 2 .

 2 1: Application-Level network simulators review.

		Models
		Performance	Energy
	Simulators	Domain CPU Wired Wireless CPU Wired Wireless
	CloudSim	Cloud
	DartCSim+	Cloud
	iFogSim	FogCloud
	mtCloudSim	Cloud

tuples with a simple bandwidth/latency model as presented in Section 2.2.1. Fog applications are represented by Directed Acyclic Graphs (DAG), where nodes of the graph represent an application module and each edge represent modules dependencies. In this way, applications module can be mapped to different nodes (either to the Cloud or to Fog depending placement policies) which allows for distributed Fog application simulations. Regarding energy consumption, iFogSim still benefits from servers and VMs energy models inherited from CloudSim and allows for Fog node energy measurement. Thus, iFogSim can be used to study coarse-grained Fog application placement strategies and their effects on performance and energy. However, iFogSim does not provides any wireless communication models and does not account for network protocols overhead. Despite providing an end-to-end framework, iFogSim is restricted to Fog application study and does not target accurate network energy predictions for neither wireless nor wired communications. Consequently, iFogSim is not suitable for end-to-end network energy studies.

Table 2 .

 2 2: Packet-level network simulators review.

		Models
		Performance	Energy
	Simulators	Domain CPU Wired Wireless CPU Wired Wireless
	CupCarbon	WSN
	Komondor	Wi-Fi
	OMNET++ Various a
	ns-3	Various

a. Can be applied to various domains.

Table 2 .

 2 3: Flow-level network simulators review.

		Models
		Performance	Energy
	Simulators Domain CPU Wired Wireless CPU Wired Wireless
	Narses	WSN
	DeSiNe	Wi-Fi
	FLEO	Cloud
	SimGrid	Various a
	a. Can be applied to various domains.

Table 3 .

 3 1: Simulations Energy Parameters.

	(a) IoT part.		(b) Network part.
	Parameter	Value	Parameter	Value
	Supply Voltage	3.3V	Idle	0.00001W
	Tx	0.38A	Bytes (Tx/Rx)	3.4nJ
	Rx	0.313A	Pkt (Tx/Rx)	192.0nJ
	Idle	0.273A

Table 3 . 2 :

 32 Sensors transmission interval effects with 15 sensors.

	Transmission Interval	10s	30s	50s	70s	90s
	Sensor Power	13.51794W 13.51767W 13.51767W 13.51767W 13.51761W
	Network Power	0.44188W 0.44177W 0.44171W 0.44171W 0.44171W
	Application Delay	0.09951s	0.10021s	0.10100s	0.10203s	0.10202s

Table 3 .

 3 3: Network Devices Parameters.

	Device	Parameters
	Gateway	Static power = 8.3 Watts, Bandwidth = 54Mbps, Utilization = 10%
	Core router	Static power = 555 Watts, 48 ports of 1 Gbps, Utilization = 25%
	Edge switch	Static power = 150 Watts, 48 ports of 1 Gbps, Utilization = 25%

Table 4 .

 4 1: Overview the energy parameters used in the simulation.

		Ports
	Parameters	1Gbps 10Gbps
	Idle Power	1.12W 0.53W
	Packet Energy 197.2nJ 1 504nJ
	Byte Energy	3.4nJ	14nJ

Table 5 .

 5 3: Time prediction and throughput average relative error between SimGrid Wi-Fi model and ns-3 for each scenario.

Table 5 .

 5 This figure clearly shows that packets are essentially dropped on the 4: Comparison of packet dropped during the P1U platform simulations in ns-3.

		Interferences
		Enable	Disable
	Number of Stations	Max PhyRxDrop Max PhyRxDrop Variation(%)
	1	5618	5713	+1.691%
	2	63683	53012	-16.746%
	5	558128	466599	-16.399%
	15	4862547	3167841	-34.852%

Table 5 .

 5 5: Time prediction and throughput average relative error between SimGrid Wi-Fi model and ns-3 for each scenario while disabling the ns-3 additive power interference model.

Table 5 .

 5 6 provides the scalability results for the P3B scenario. This table shows that the number of STA has a strong impact on the ns-3 execution time. Conversely, SimGrid execution time is almost unchanged. Thus in this scenario, we are able to estimate the performance of Wi-Fi for a given configuration with ARE of 3.04% in comparison with ns-3 in less than a second.

		ns-3		SimGrid
	Number of Stations Execution Time Peak Memory Usage Execution Time Peak Memory Usage
	3	334s	70.65MB	<1s	14.22MB
	15	2 527s	74.65MB	<1s	15.11MB
	24	4 268s	77.92MB	<1s	15.41MB
	30	6 328s	81.83MB	<1s	15.60MB

Table 5 .

 5 6: Scalability analysis of the P3B scenario.

  Modèles scalable pour la prédiction temporelle et énergétique des infrastructures FogMot clés : simulation,réseaux,énergie,modèle,simulateur,SimGrid,Wi-Fi,paquet,flux Résumé : L'informatique géo-distribuée (Fog Computing) désigne la migration des ressources de calcul et de stockage du nuage (Cloud) vers les utilisateurs. Cette migration des ressources permet de réduire la latence des terminaux utilisateurs afin de répondre à l'évolution des usages de l'Internet. En parallèle, le nombre de terminaux ne cesse de croître avec le développement de l'Internet des objets. Cette croissance des infrastructures et du nombre d'objets connectés à Internet entraîne une hausse de la consommation électrique globale liée au numérique. Cependant, cette consommation est très distri-buée et fait intervenir de multiples acteurs : objets connectés, réseaux locaux, fournisseurs d'accès à Internet, infrastructures de Fog et de Cloud. Il est ainsi difficile d'étudier l'impact de la croissance du nombre d'objets connectés sur la consommation électrique des infrastructures qui constituent l'Internet des objets. L'objectif de cette thèse est de proposer des modèles afin de permettre l'étude à grande échelle de la consommation énergétique des infrastructures Fog de manière efficace et reproductible. Les modèles proposés ont été intégrés à l'outil de simulation SimGrid afin d'être validés et diffusés.

Titre :

(a) 2 hosts 1 link platform power profile (b) 4 hosts 3 links platform power profile (c) Dogbone platform power profileFigure 4.5: Microbenchmarks energy results on heterogeneous energy platforms.

This chapter is organized as follows. Section 5.1 presents the context and the problematic of the proposed Wi-Fi model. Section 5.2 introduces the core of the SimGrid bandwidth sharing

Characterization of low-bandwidth IoT applications

In this section, we detail the characteristics of the considered IoT application. While the derived model is more generic, we focus on a given application to obtain a precise use-case with accurate power consumption measurements.

The Google Nest Thermostat relies on five sensors: temperature, humidity, near-field activity, far-field activity and ambient light [START_REF] Google | Nest Learning Thermostat -Spec Sheet[END_REF]. Periodical measurements, sent through wireless communications on the Internet, are stored on Google data centers and processed to learn the home inhabitants habits. The learned behavior is employed to automatically adjust the home temperature managed by heating and cooling systems. Each IoT device senses periodically its environment. Then, it sends the produced data through Wi-Fi (in our context) to its gateway or AP. The AP is in charge of transmitting the data to the cloud using the Internet. Figure 3.1a illustrates this architecture. In a home, several IoT devices can share the same AP. We consider low-bandwidth applications where devices produce several network packets during each sensing period. Given this IEEE 802.11n configuration for ns-3, the next step is to instantiate our SimGrid Wi-Fi model by determining the effective rate r i of each station in the cell. Since we fixed the channel communication rate at 54MBps, we run a calibration experiment on ns-3 to determine the effective throughput of the actual configuration. The experiment consists in one station that communicates with an access point at a distance of 15m as depicted on Figure 5.3. Communications occur at the maximum achievable throughput with a TCP socket. This experiment gives us an effective throughput of 42.10Mbps. Thus, we use this value as the effective rate r i for every station to instantiate our model. It is important to note that this rate will remain fixed during all the validation process since we are not using any rate adaptation algorithm.

To summarize, we configure the ns-3 simulator to reflect a IEEE 802.11n configuration with a single STA. Then we calibrate our SimGrid 802.11 model by measuring the station effective

Support for other wireless technologies

Despite being used by a lot of ICT devices, Wi-Fi is not the single technology used in IoT and Fog infrastructures. Since connected objects are meant to be connected for a long period, many wireless technologies have been developed targeting low power energy consumption. Thus, proposing additional wireless communication models could improve the range of applications of our simulation framework.

Future research impact

In the literature many works can benefit from an end-to-end simulation framework. Table 6.1 revealed interesting characteristics about them. First, most of the presented work is related to end-to-end energy studies and involves IoT, Fog, ISP and Cloud platforms. However, the majority of them based their experimentations on a custom numerical model which is often