Abstract: This study analyses the progress of, and state of the art in, energy‐efficient strategies for wirelessly connecting networks of embedded computers, such as those found in wireless sensor networks (WSN), Internet of Things (IoT) and cyber-physical systems (CPS) applications. Specifically, emphasis is given to energy conservation as vital to assuring the feasibility of long lifetime, low‐maintenance and more autonomous monitoring and control situations. A complete description of the link layer and routing protocols for a range of traffic patterns are discussed, and their integration and evaluation as whole protocol stacks.
Claims:1. A communications protocol suite specifies how data should be formatted (i.e.in, packets), transmitted and received (channel access), and routed in a network. Layers of abstraction describe the various networking functions involved and vary somewhat depending upon the abstraction model.
2. Energy‐efficient medium access control (MAC) protocols, selecting a suitable MAC protocol is heavily dependent upon the application, specifically on the statistical properties of the traffic generated in the network, the network topology and environmental factors. A well‐designed application will consider each of these factors at design time.
3. The worst‐case scenario from an energy perspective is that the radio must be on 100% of the time. Therefore, once a wireless technology is selected, the designer sets about choosing a chip. The majority are reasonably similar in their electrical characteristics, irrespective of the manufacturer.
4. Routing algorithms are essential for every WSN as they define how packets flow within the network. Algorithms differ based on their capabilities, effectiveness, amount of memory required to store the routing state, agility and energy awareness.
5. Typically, WSNs have been deployed to collect data about certain phenomena in predefined geographic areas (sensing field). Nodes in such a network sample a sensor at a predefined rate and report the sensed data towards a sink node.
6. For networks deployed for monitoring and continuous data collection, peer-to-peer (P2P) communication is often unnecessary. Each node only needs to know how to deliver data to one of the base stations.
7. With the arrival of IPv6, researchers set about implementing it for sensor networks. This was met with several challenges. Because the main usage domain of IPv6 is Ethernet, to cope with increased Internet traffic, the maximum transmission unit (MTU) was increased from 576 to 1280 bytes compared to IPv4. , Description:Achieving neutral energy operation requires a comprehensive understanding of the application at design time and is seen as a ‘holy grail’ for networked embedded computing devices. However, applications tend to be characterised by heterogeneous performance requirements, deployment environments and criticalities. Therefore, there are few, if any, ‘one size fits all solutions. If one assumes that sensors and actuators are low cost concerning energy in terms of sampling and information processing (which is not always accurate in the case of industrial applications, communication is widely accepted as the primary energy consumption. This energy consumption occurs when the radio transceiver is in an active state to send, receive and route packets. Assuming a worst‐case scenario whereby the radio transceiver is always busy (a condition that tends to require tens of milliwatts of power, the obvious way to reduce energy consumption is to place the device in the lowest power mode available for as long as possible—a technique known as duty cycling, which can be applied to the radio transceiver (radio duty cycling, RDC) and the other components of the device. This is equally true for current system on chip (SoC) solutions that integrate transceiver and microcontroller circuitry on the same chip.
Wireless communication
There are several well‐known wireless communications technologies in widespread use. These range from cellular, now on the verge of the 5th Generation (5G), to WiFi and Bluetooth Low Energy (BLE), among the most widespread. Recent WiFi and BLE chipsets are significantly lower power than their predecessors. They are increasingly competitive for certain energy‐efficient ‘IoT’‐type applications, particularly in the consumer electronics market.
Communications protocol suites
A communications protocol suite specifies how data should be formatted (i.e.in, packets), transmitted and received (channel access), and routed in a network. Layers of abstraction describe the various networking functions involved and vary somewhat depending upon the abstraction model. For example, the OSI model specifies seven layers, whereas the TCP/IP model (Internet Protocol suite) specifies four. This is a particularly relevant issue in WSN design, as it is well known that efficiencies are best achieved by co‐designing the layers. Still, they are often designed independently (e.g. RPL) to enable interoperability. The most recent IETF stack proposed by the 6TiSCH working group, particularly suited to IoT, is shown in Fig.1 and loosely maintains the TCP/IP model. In this case, the time-synchronized channel hopping (TSCH) is used at the ‘link layer’ (which includes medium access control), 6top is an interface layer to the 6LoWPAN adaptation and compression layer (used to reduce the size of the IPv6 header such that it comfortably fits in the 127‐bytes available in a physical layer packet), and RPL at the Internet/routing layer. UDP is used at the transport layer to mitigate the overheads of TCP (i.e. end‐to‐end handshaking) and the Constrained Application Protocol (CoAP). While the higher layers of the stack benefit from having an understanding of, and in many instances, real‐time information from, the lower layers, the most critical from an energy efficiency perspective is the physical layer (i.e. the radio transceiver itself) and the link layer, the latter of which is responsible for medium access control, and therefore, how long the transceiver remains in an active or sleep state. Energy‐efficient medium access control (MAC) protocols, selecting a suitable MAC protocol is heavily dependent upon the application, specifically on the statistical properties of the traffic generated in the network, the network topology and environmental factors. A well‐designed application will consider each of these factors at design time. Firstly, the selection of the radio itself is critical. From an application standpoint, the essential quality of service requirements must be met, primarily bandwidth—otherwise, the application is probably infeasible (without resorting to trickery in software, such as compressive or predictive sense, and assuming this is satisfactory for an end‐user). The worst‐case scenario from an energy perspective is that the radio must be on 100% of the time. Therefore, once a wireless technology is selected, the designer sets about choosing a chip. The majority are reasonably similar in their electrical characteristics, irrespective of the manufacturer. This makes life easier, but it is worth considering the features of the chip selected. For example, on‐board hardware acceleration of security functions can significantly reduce the overheads associated with implementation in software. Most contemporary RFICs compliant with are in the tens of milliwatts range inactive modes and drop to the microwatt range in low power modes, making them good candidates for long‐term low‐power applications. They require additional RF front‐end design, including antenna and matching networks, plus an oscillator circuit to drive the clock. The latter involves the selection of inductors and capacitors, which are variable in their characteristics.
Environmental conditions such as temperature and humidity often affect essential performance characteristics. In the case of a wireless node, these have effects internally (i.e. on each device) and externally (i.e. the impact on the wireless medium), which both impact the performance of a network. In the case of the device, temperature effects and component selection significantly affect relative clock drift, which must be taken into account when tuning and learning protocol parameters like guard times and phase offsets, respectively. To ensure accurate synchronisation, understanding clock drift is essential to configure networking parameters, such as guard times, tightly. It has been studied where the authors investigate the effects of environmental temperature on clock drift and propose strategies to help designers choose optimal resynchronisation periods for given accuracies and where the authors study the impact of oscillator drift on end‐to‐end latency over multiple hops using varying capacitor accuracies and show how to determine optimal parameters to minimise energy consumption in duty‐cycled wireless sensor networks using low power medium access control techniques. It is also worth noting that temperature influences battery performance, particularly as temperatures reduce, where capacity is degraded and voltage is reduced. This is a relatively understudied area in terms of IoT/WSN technologies but is likely to be very important where devices are deployed outdoors in cold environments.
Energy‐efficient medium access control
A large body of research exists concerning MAC protocols for WSNs. Examples of energy‐efficient implementations include A‐MAC, BoX‐MAC, HuiMAC, SCP‐ MAC, ContikiMAC and WiseMAC. These MAC protocols are based on globally asynchronous radio duty‐cycled (RDC) approaches, where the objective is to minimise the active time of the RF transceiver. Typically, trade‐offs are assumed to be inherent in the design of these protocols, and the Pareto‐optimal solution is sought when considering energy efficiency and application-level or performance requirements, such as throughput, reliability and latency. The authors consider low data‐rate applications and attempt a tractable analytical approach to modelling latency and energy efficiency as functions of protocol parameters, including duty cycle, slot duration and total slots, seeking to determine optimal settings for given workloads defined by application‐level parameters. They find that WiseMAC best balances energy efficiency and latency based on the scenarios considered and attribute minimising protocol overhead through local synchronisation (also referred to as phase lock optimisation in the literature and exploited in several subsequent proposed MACs and random channel access as key to achieving this balance.
These protocols, however, are just the tip of the iceberg (and are heavily oriented towards aggressively duty‐cycled, energy‐efficient scenarios for low data‐rate applications). Present a comprehensive taxonomy of MAC protocols according to the various techniques used, classifying them according to the challenge they address. They describe the importance of understanding the statistical properties of the network traffic when selecting and tuning a MAC protocol, which is argued to be a more helpful approach for the application developer. The authors classify the traditional ‘MAC families’ as Reservation‐ Based Protocols and Contention‐Based Protocols at the highest level, where the former is synonymous with scheduled approaches such as Time Division Multiple Access (TDMA), and the latter with more straightforward, popular systems such as ALOHA and Carrier Sense Multiple Access (CSMA). They proceed to explore the functions relative to high—scheduled protocols for high‐rate applications such as multimedia; medium—protocols with standard active periods for medium rate applications such as those found in many industrial applications; and low—preamble sampling for low‐rate applications with rare event‐reporting, such as long‐term monitoring or metering, and finally consider hybrid protocols for time‐varying application-level functionality. Table 1 borrows the structure and updates the taxonomy of that presented. Specifically, A‐MAC, and Reins‐MAC, which leverage TSMP and are closely linked with ongoing standardisation initiatives, are notable protocols published.
Energy‐efficient networking, data collection and dissemination
Routing algorithms are essential for every WSN as they define how packets flow within the network. Algorithms differ based on their capabilities, effectiveness, amount of memory required to store the routing state, agility and energy awareness.
Routing protocols for WSNs can be categorised into three main groups depending on the functionality they provide: (i) protocols that route data only towards one or more predefined base‐station or sink nodes, referred to as data collection protocols or many‐to‐one patterns of communication, (ii) protocols that allow peer‐to‐peer or any‐to‐any patterns of communication between nodes in the network and (iii) protocols allowing one node to disseminate a message to all or a subset of the nodes in the network, also referred to a one‐to‐many pattern of communication. Protocols belonging to the first group are usually based on building routing trees rooted at one (or more) sink node(s). Every node in the network forwards all data towards a sink via a selected parent. Protocols from the second group support peer‐to‐peer communication; any node in the network can send a message to any other node. These protocols either exploit some routing table learned beforehand to forward data towards the destination, or they first need to find the destination node and establish a connection. Protocols from the last group are usually based on gossiping or flooding the whole network.
Data collection
Typically, WSNs have been deployed to collect data about certain phenomena in predefined geographic areas (sensing field). Nodes in such a network sample a sensor at a predefined rate and report the sensed data towards a sink node. The network may contain several base‐ stations, in which case a node typically forwards data towards the closest base station only. Two of the most common routing protocols are Collection Tree Protocol (CTP) and Routing Protocol for Low Power and Lossy Network (RPL). CTP is a standard library of the TinyOS operating system, while the Contiki operating system comes with two standards alternatives: (i) Collect, which is part of the basic Rime network stack and is an alternative implementation of CTP for Contiki OS and (ii) RPL, which is part of the more complex IPv6 stack. There is also an RPL implementation for TinyOS called TinyRPL. These protocols are based on creating a directed acyclic graph rooted at the base station. Each node in the network forwards all data toward the root. A primary challenge in designing these protocols is defining the metric by which a node chooses its parent, via which the node will forward all packets. Early adopters of this approach used hop count to the base station as a metric. Later, CTP used a new metric: Expected Transmission Count (ETX). ETX uses the number of transmissions required to deliver the packet to the destination without error. ETX depends on the quality of the link. Many pro‐ tools vary by how the quality of the association is measured and computed (e.g. based on RSSI, a statistical measure of the number of packets lost, or a function of both). It has been shown that using this metric decreases network traffic and leads to lower energy consumption.
Peer‐to‐peer routing
For networks deployed for monitoring and continuous data collection, peer-to-peer (P2P) communication is often unnecessary. Each node only needs to know how to deliver data to one of the base stations. However, as WSNs become more common and serve a broader range of purposes, communication among nodes in the network will become more critical. WSNs are used to collect data and react to the environment and control it via actuators, components of emerging cyber-physical systems. Nodes in the network need to send messages directly to other nodes while lowering the overall traffic. This requirement becomes even more critical to send an actuation message directly to the actuator with actuation networks. For that purpose, routing protocols that allow P2P communication was developed.
Such P2P protocols may be categorised into five groups, depending on how they locate and forward messages to communicate with a peer: (i) geographic routing, (ii) routing based on trees, (iii) hierarchical routing, (iv) ad hoc shortest path routing and (v) routing based on routing tables.
Geographic routing
Each node is not addressed by its ID or IP address in geographic routing but by its geographic location. The routing decision is then based on the position of the node making the forwarding decision, the part of the destination node and the part of the neighbours of the forwarding node. The neighbour closest to the destination node is chosen as the next hop. As geographic routing heavily relies on the exact geographic position of the nodes, specialised hardware is required (e.g. GPS), and a localisation algorithm must be used. However, specialised hardware increases the price of the node, increases the energy requirements and is sometimes not very precise. Similarly, using localisation algorithms leads to additional network traffic and may also be imprecise.
Routing trees
In networks where P2P communication is based on routing trees, the nodes are organised in one or several trees where each node stores its parent's ID only. The root of a tree is represented by a more powerful node storing connectivity information of the whole network. The packet is first routed to the heart of a tree, where the central router computes the shortest path to the destination. The box is then routed downwards towards the goal via this straightforward path. The advantage of this approach is minimal memory requirements on the nodes and the simplicity of the routing algorithm. The disadvantage is potentially high routing stretch, that is, the ratio between the length of the found path and the optimal one, and the requirement that the central router is aware of the whole network topology. Additionally, top‐level nodes may become overloaded by the network traffic, especially in large networks.
Ad hoc routing
Unlike other routing algorithms, ad hoc routing does not require any global preparation phase during which the network is prepared for P2P communication. However, when a node needs to communicate with a peer, a path between the nodes must be established first. This is usually done by flooding the network with a request. The request contains the source node ID, the destination node ID and a path taken by the request so far. Unless the node is the destination that receives the request, each node adds itself to the course and re‐broadcasts the request. Once the destination node receives the request, it replies to the source node by reversing the direction of relay nodes. The algorithm leads to the discovery of the shortest path between two nodes.
The disadvantage of this approach is a costly path discovery as the whole network is flooded with a request, and there is poor energy efficiency. Even though other methods like routing via trees also rely on path discovery, the search in those networks is more directed and does not flood the entire network.
Routing based on routing tables
Approaches based on routing tables first execute a learning or a bootstrapping phase during which every node learns routes to nodes of interest. For every node, two other pieces of information are usually stored: distance and next hop. The number of balls is generally used as a distance, but any other additive metric could be used. Once the bootstrapping phase is complete, each node can independently forward the packet using the locally stored routing table.
Routing algorithms like RPL use a subset of nodes to store the routing table and only for nodes in the sub‐tree rooted in a given node. Other approaches like Energy-Aware Routing (EAR) use a routing table to store several alternative routes to the base station so a node can choose alternative ways to distribute network load better. Kolcun et al. proposed Dragon, where every node in the network stores a path to every other node. The platform also includes algorithms for a quick update of the routing table in the case of a node failure while keeping the network overhead low.
FULL-STACK IMPLEMENTATIONS
IPv6 over LR‐WPAN
With the arrival of IPv6, researchers set about implementing it for sensor networks. This was met with several challenges. Because the main usage domain of IPv6 is Ethernet, to cope with increased Internet traffic, the maximum transmission unit (MTU) was increased from 576 to 1280 bytes compared to IPv4. IPv6 addresses are 128‐bit long, and the standard IPv6 header size is 40 bytes. This is in strict contrast with the standard, whose throughput is limited to 250 kbps and the length of the frame to 127 bytes. The standard supports two addresses: short 16‐bit and EUI‐64 extended addresses. With link headers included, the adequate size of the payload could be as small as 81 bytes, which makes IPv6 headers seem too large. In 2007, Mulligan and an Internet Engineering Task Force (IETF) working group published a proposal to transfer IPv6 packets in low‐rate wireless personal area networks. A new protocol called 6LoWPAN was introduced. The working group aimed to define a stateless header compression that would decrease the header size so it can be used with the standard. The reduction was achieved by introducing four basic header types: (i) Dispatch Header, (ii) Mesh Header, (iii) Fragmentation Header and (iv) HC1 Header (IPv6 Header Compression Header). 6LoWPAN implements variable‐sized headers, where the header size varies from 4 to 13 bytes, depending on what kind of communication is required. The protocol is also prepared to support new types of headers.
Composable stacks
Many of the protocols described thus far have open-source, modular implementations available in the libraries of the various operating systems. Therefore, they can quickly be composed to suit an intended application scenario. We know that performance and appropriate selection depend on application-level requirements and statistical properties of the network traffic generated by that application. Therefore, very few studies explore in‐depth full‐stack implementations on per‐application bases. However, there are several well‐doc‐ umounted implementations that comparatively evaluate performance. The authors compare the performance of LWB against Dozer (a highly efficient TDMA‐based data collection protocol), CTP+A‐MAC, and CTP+LPL under a variety of conditions. CTP+A‐MAC, LWB and, more recently, Chaos are state‐of‐the‐art representative stacks from the research community that rival the standards‐based stacks, which tend to adopt something very similar to the 6TiSCH approach (Figure 1).
Energy analysis
One of the most comprehensive evaluations of a relatively complete stack is presented in, where CTP is run on several heterogeneous test‐beds, over several link layers, for various inter‐packet intervals (typically determined by the application scenario) at a variety of radio frequencies on multiple channels. While the evaluation shows that the combination of beaconing and data path validation used in its design is robust over various physical and link layers, the performance characteristics still do not quite meet those needed for ultra-long, large (i.e. extremely dense), highly reliable applications. The authors also leave the question of whether these methods are suitable for distance vector algorithms synonymous with ad hoc networking.
| # | Name | Date |
|---|---|---|
| 1 | 202241020523-COMPLETE SPECIFICATION [05-04-2022(online)].pdf | 2022-04-05 |
| 1 | 202241020523-REQUEST FOR EARLY PUBLICATION(FORM-9) [05-04-2022(online)].pdf | 2022-04-05 |
| 2 | 202241020523-DRAWINGS [05-04-2022(online)].pdf | 2022-04-05 |
| 2 | 202241020523-FORM-9 [05-04-2022(online)].pdf | 2022-04-05 |
| 3 | 202241020523-FIGURE OF ABSTRACT [05-04-2022(online)].jpg | 2022-04-05 |
| 3 | 202241020523-FORM 1 [05-04-2022(online)].pdf | 2022-04-05 |
| 4 | 202241020523-FIGURE OF ABSTRACT [05-04-2022(online)].jpg | 2022-04-05 |
| 4 | 202241020523-FORM 1 [05-04-2022(online)].pdf | 2022-04-05 |
| 5 | 202241020523-DRAWINGS [05-04-2022(online)].pdf | 2022-04-05 |
| 5 | 202241020523-FORM-9 [05-04-2022(online)].pdf | 2022-04-05 |
| 6 | 202241020523-COMPLETE SPECIFICATION [05-04-2022(online)].pdf | 2022-04-05 |
| 6 | 202241020523-REQUEST FOR EARLY PUBLICATION(FORM-9) [05-04-2022(online)].pdf | 2022-04-05 |