Admission control for QoS in Fog deployments

Get Complete Project Material File(s) Now! »

Reference WSN deployments

Depending on the use cases and applications, WSN deployments cover a broad spectrum of characteristics in terms of node density, number of nodes, typical topology, traffic patterns, etc. Given that our main aim is to identify under which circumstances, if any, geographic forwarding is more advantageous than classical name-based forwarding, we need to select a number of specific use cases, representative of different application classes. For the purpose of quantitative assessment, we need each use case to precisely report characteristics that are specific to a single deployment. At the same time, provided that the selection is made among carefully defined application classes, we expect that the results for the selected example in any given application class qualitatively applies to other deployments in the same class.
As pointed out in Section 1.1, there are many classes of IoT applications. To better focus our investigation, we consider the IETF Routing Over Low power
and Lossy networks (ROLL) working group 1, which identifies four main use cases: (i) urban sensing [12], (ii) industrial sensing [7], (iii) home automation [5], and (iv) building automation [2]. While not considered by the ROLL working group, environmental sensor networks and machine-to-machine deployments are another class of deployments largely covered in the literature [10,112]. Without loss of generality, and to give the reader several reference points, we consider four deployments, whose relevant characteristics we summarize in Table 2.1 with their classes with respect to the aforementioned ROLL categories. For each deployment, we review the reference documentation or available data to determine the number of neighbours for each node, which we use as input data to our model. The deployments, ordered by increasing node degree in Table 2.1, are: (A) Place de la Nation: as an example of the urban sensing class, we take the Cisco-Paris deployment, which is a joint venture between Cisco, the City of Paris and several start-up companies [13]. The deployment is used to measure and track car and pedestrian traffic and pollution patterns on a highly frequented square in Paris. It consists of 19 cameras, 14 noise sensors, 5 pollution-reading sensors, and 12 wireless access points that report information about user connections. The measured data is opensource and available online [113].
(B) Great Duck Island: the Great Duck Island deployment [110] is an environmental sensor network consisting of 150 devices. The sensors were used to observe the habitat of seabirds on an island off the coast of Maine and its evolution depending on weather conditions.
(C) CASAS: as an example of the home automation class, we select CASAS [4], which is a so-called “smart-home in a box”: a ready-to-deploy sensor network that allows any consumer to transform their home in a connected (or “smart”) home. It consists of 30 nodes communicating over the IEEE 802.15.4 radio channel, including temperature sensors and infrared motion/light sensors. (D) Sensor Andrews: as an example of the building automation class, we select Sensor Andrew [111], a sensor network deployment at Carnegie Mellon University (CMU). More than 1000 devices spread all over the CMU campus report numerous measurements such as electricity consumption or temperature.

Reference Information-Centric Things (ICNWSN) Architecture

To realize secure geographic routing, several building blocks must be added to tradition ICN-WSN architectures: (i) a neighbour discovery and association protocol (Section 2.3.1), which ensures that only trusted nodes are authorized to send packets on the network; (ii) a secure beaconing (Section 2.3.2) protocol to handle topology and location changes; (iii) a forwarding scheme (Section 2.3.3), to ensure correct forwarding of Interest packets over the network independently of the forwarding algorithm class (i.e., geographic or name-based). In this section, sample implementations for these are detailed and discussed, highlighting the various trade-offs. Let us note that our study leaves for future work one important feature of ICN: in-network caching. As memory is a scarce resource on IoT platforms, a better understanding of the opportunities for in-network caching in the ICN-WSN would require a thorough study of current ICN-WSN stacks and their memory usage. We provide a first step in that direction with the results of Section 2.7.2.

READ  Plasmonic organic solar cells using silver nanoprisms

Data Encryption and Decryption

The cost of cryptography depends on the device’s capabilities, such as CPU characteristics, and more importantly on the availability of hardware cryptography components. We present the energy consumption of AES-CCM encryption in the OpenMote platform, considering both software- and hardwareassisted cryptography as a function of the message’s size in Figure 2.5. For the software implementation, we microbenchmark the AES implementation of the crypto module of RIOT with the previously outlined technique. Figure 2.5 provides the measurements as well as an equation derived from the measurements. For the hardware-assisted encryption, we point out that cryptography hardware modules are not yet supported on RIOT: we thus use as a reference the AES-CCM measurement reported in Table 6 of [118]. The picture clearly shows the importance of hardware modules for cryptographic operations: the AES-CCM software implementation consumes up to 5 times more energy than its hardware-assisted counterpart. In hardware, AES-CCM has a maximum cost of 10 μJ per packet (since the IEEE 802.15.4 maximum transmission unit (MTU) is 127B).

Table of contents :

Acknowledgements
Résumé / Abstract
List of Acronyms
1 Introduction 
1.1 The Internet-of-Things
1.1.1 IoT applications
1.1.2 IoT networks
1.1.3 Challenges
1.2 Information-Centric Networking for the IoT: motivation
1.2.1 Information-Centric Networking
1.2.2 ICN for the IoT
1.3 ICN for the IoT: background
1.3.1 ICN for the WSN
1.3.2 ICN for the Fog
1.3.3 ICN for specific IoT applications
1.4 Thesis contribution
1.4.1 Forwarding and routing in the ICN-IoT: challenges
1.4.2 Contribution and organization
1.5 Publications
2 Geographic routing 
2.1 Geographic routing
2.2 Reference WSN deployments
2.3 Reference Information-Centric Things (ICN-WSN) Architecture
2.3.1 Secure neighbour discovery
2.3.2 Secure beaconing
2.3.3 Forwarding
2.4 Methodology overview
2.4.1 Experimental setup
2.4.2 Memory
2.4.3 Computation
2.4.4 Energy
2.5 Cost of forwarding a single ICN packet
2.5.1 Frame transmission and reception
2.5.2 Data Encryption and Decryption
2.5.3 Forwarding algorithm
2.5.4 Overall cost
2.6 Cost of control traffic
2.6.1 Geographic forwarding
2.6.2 Flood and learn
2.7 Guidelines for ICN-WSN operation
2.7.1 Energy cost
2.7.2 Memory and CPU complexity
2.8 Summary
3 Fog admission control 
3.1 Admission control for QoS in Fog deployments
3.2 Problem description
3.2.1 Reference Fog architecture
3.2.2 Fog vs Cloud admission control
3.3 An analytical model
3.3.1 Application model and request distribution
3.3.2 Queueing model
3.3.3 Computing the statistical latency
3.3.4 Computing the cost function
3.3.5 An example application – Numerical parameters
3.4 Popularity-based Fog admission
3.4.1 Optimizing Fog resources
3.4.2 Blind admission control
3.4.3 LFU-AC strategy
3.4.4 The LRU-AC strategy
3.4.5 Preliminary evaluation of the admission control strategies
3.5 Ageing Bloom-Filters for an hardware-accelerated LRU-AC
3.5.1 Ageing-Bloom filters
3.5.2 Hit-rate approximation for the ABF
3.5.3 Model verification for = 1
3.5.4 ABF – memory usage vs LRU
3.6 Hardware-implementation of the LRU-AC
3.6.1 Using hICN as the underlying network layer
3.6.2 Hardware-implementation of the LRU-AC
3.7 Evaluation
3.7.1 Packet-level simulation
3.7.2 Implementation evaluation
3.8 Related Work
3.9 Summary
4 Intent-based ICN 
4.1 Intent-Based Networking and ICN
4.2 Related work
4.3 The vICN framework
4.3.1 Functional architecture
4.3.2 Resource model
4.3.3 Resource processor
4.3.4 Orchestrator and Scheduler
4.4 Implementation
4.4.1 vICN codebase
4.4.2 Slicing
4.4.3 IP and ICN topologies
4.4.4 Link emulation
4.4.5 Monitoring capabilities
4.5 Examples
4.5.1 Use case description
4.5.2 Scalability
4.5.3 Programmability
4.5.4 Monitoring and Reliability
4.6 An Intent-Centric network management protocol
4.6.1 Intent-based network model
4.6.2 Model-based routing and forwarding
4.7 Summary and future work
5 Conclusion 
5.1 Geographic routing for the ICN-enabled WSN
5.2 Popularity-based latency control for Fog applications
5.3 Intent-based management of ICN
5.4 Future research directions
Appendices

GET THE COMPLETE PROJECT

Related Posts