The term "network" is a common one in the IT industry. Most people immediately think of a computer network, and terms such as LAN (Local Area Network) or WLAN (Wireless Local Area Network) are quickly added.
A sensor network is basically just a network of computers. Only in this case, the computers are smaller and their function is usually limited to measuring and transmitting data (environmental parameters, etc.). The computers are small microcontrollers with appropriate sensors and radio chips. They form the sensor board or a "sensor node" and are constructed differently depending on their intended use.
A powerful or energy-saving microcontroller, wired or wireless, tiny or as big as a shoebox, a simple temperature sensor or a complex sensor array. The aim is to be able to set up a large network as cheaply as possible and collect data from all over the place.
At the moment, however, nodes are still relatively large and expensive and not yet ready for the mass market, but this diversity means that the potential applications are huge. They range from simple sensor networks for temperature monitoring in buildings to huge sensor networks for seismic monitoring of volcanoes. In the US, for example, sensor networks are being used to monitor remote forest areas for forest fires, but all these sensor networks are relatively similar and use the same technologies.
I would now like to look at the structure and the technologies used in more detail.
As the name suggests, sensor nodes form a network. However, what makes a sensor network special is the way in which they form this network: unlike normal computer networks, sensor networks form an ad-hoc network. This is a network that works without a fixed infrastructure. The result is a meshed network in which nodes are connected to one or more other nodes.
This structure makes it possible for data to be passed back and forth between nodes until it reaches its destination (see Figure 1 - blue arrows).
The data load is therefore distributed more favourably than, for example, in star-shaped networks with central nodes. The design of a sensor node means that resources such as computing time, energy or data rate are very limited.
In a meshed network, it is still possible to build up a large network because the distance to the next node is relatively short, but in a sensor network the network configures itself autonomously. This means that there is no need for a central instance to configure the network.
Sensor nodes can fail, move or new nodes can be added. Special routing protocols (more on this later) ensure that the network always adapts accordingly. The sensors constantly determine the optimal route to the other sensors, creating a routing table. Criteria include the shortest route or the use of the least congested nodes. This dynamic has both advantages and disadvantages: the advantage mentioned above is that the network automatically adapts to changes. The network is therefore virtually fail-safe. If a node fails, the data flow is rerouted via another node (see Figure 1 - green arrows).
As a result, and due to the good load distribution, the sensor network is very efficient. Furthermore, the network costs are very low due to the decentralised administration.
However, this dynamic has its drawbacks. The performance of such a network cannot be predicted and is highly dependent on the closeness of the network. The number of nodes can change at any time, requiring constant updating of the routing table. Transmission times can also vary greatly due to differences in cable quality. How good is the connection between the nodes? Are there walls between them? Influences that are unpredictable.
In addition, the routing is relatively complex. Each node needs to know how to reach its destination node. In order to have a network that is as fail-safe as possible, as many sensor nodes as possible must also be in operation and not go into standby. However, this is often desired with battery-powered sensor nodes. In order to be able to communicate with other networks, there is a gateway (parent node, see blue node in Figure 1) that acts as a link between the sensor network and, for example, a normal local area network (LAN). This allows further processing of sensor data on additional servers or cloud-based platforms. Processing or other logic should be avoided in the actual sensor network, as performance is often limited here.
This article is still relatively general and has focused on the general understanding of a sensor network. In the second part, we will look under the hood and take a closer look at the technologies and protocols used in a sensor network.
In order to optimally meet these requirements, several technologies/protocols run in the background:
IEEE 802.15.4 describes the standard for a transmission protocol, which was defined specifically for radio-based (sensor) networks. The two lowest layers of the OSI model are described in the standard. When developing the protocol, attention was paid to the special requirements of a sensor network:
Another special feature of the protocol is the use of two different network nodes, each with a different range of functions. There are RFDs (Reduced Function Devices) and FFDs (Full Function Devices). As the name suggests, RFDs have a reduced range of functions. As a result, they can only communicate with FFDs, as they do not have any administrative functions. The advantage of the reduced functionality is that they are cheaper to develop and consume less power. This makes them ideal for sensor nodes. FFDs, on the other hand, have the full range of functions and are therefore often used as management nodes or gateways. An FFD can also act as a PAN coordinator, defining the PAN identifier to separate the network from other IEEE 802.15.4 networks.
In the sensor network we have set up, the border router will later take over this function. The individual sensor nodes function as RFDs, more about this in later articles.
6LoWPAN stands for “IPv6 over low power Wireless Personal Area Network” and is a communication protocol for energy-saving radio transmission via IPv6 in an IEEE 802.15.4 based network.
6LoWPAN works primarily on the network layer and performs the tasks of header compression, packet fragmentation and defragmentation, as well as routing.
Header compression in particular is an important task. The smaller the header, the less has to be transferred and the more energy efficient it is. Another reason for compression is that using normal IPv6 overhead, only 33 bytes of data would be available:
The MTU (maximum transmission unit) for 802.15.4 networks is 127 bytes in size. With a maximum frame overhead of 25 bytes with IEEE 802.15.4 and an additional header for security features of 21 bytes, only 33 bytes remain for data after the IP header (40 bytes) and the UDP header (8 bytes). That is clearly too little. Apart from the fact that IPv6 requires an MTU of 1280 bytes.
Header compression assumes that the node's IPv6 address consists of an identical 64-bit prefix for the subnet and a 64-bit suffix, which is identical to the node's MAC address. If packets are now only transported via one hop (node), the destination address suffix is identical to its MAC address and the sender's suffix is identical to its MAC address and can therefore be omitted. If you only use the link-local address, you can even omit the prefix.
To avoid the problem of the smaller MTU size, packet fragmentation and defragmentation is used to virtually generate an MTU size of 1280 bytes.
RPL stands for “Routing Protocol for Low Power and Lossy Networks” and is a routing protocol for wireless sensor networks. The protocol is based entirely on IPv6 and optimally meets the above-mentioned routing requirements. A description of the protocol can be found in my blog post.
UDP stands for “User Datagram Protocol” and is a minimal and connectionless network protocol. This means that there is no need to set up an extra connection between the transmitter and receiver. The disadvantage is that it is not possible to say with certainty that a package will reach the recipient. Furthermore, it is not possible to say whether the data is unfalsified or whether it was also received by third parties. However, the advantage of connectionless transmission is the faster start of data transmission, which is particularly advantageous for small data packets.
The data on the receiving end is assigned via ports. A UDP transfer must therefore always also transmit the destination port. The UDP header therefore consists of four data fields, each with 16 bits: source and destination port, length and checksum.
CoAP stands for “Constrained Application Protocol” and is a message protocol based on REST. But as the name suggests in a stripped-down version, as the full REST protocol is not yet lightweight enough for microcontrollers.
CoAP also introduces an OBSERVE and DISCOVER function and is based on UDP instead of HTTP/TCP. This results in an increase in performance due to CoAP's message-oriented approach.
If you want more information about CoAP, I recommend Heise's article on “RESTful with CoAP”.
CoAP is also used in the sensor network I have set up. Thanks to various implementations for Riot OS, messages can therefore be sent quickly and easily between nodes. You can find more information about CoAP with Riot OS in my later post when it comes to the C program used.
Basically, a sensor network is based on the same protocols as a normal network. Only that the protocols have been adapted or extended according to their purpose. Be it the optimized IEEE-802.15.4 transmission protocol or the more energy-efficient 6LoWPAN. But thanks to these special technologies, a sensor network can be operated sensibly without sacrificing the convenience of known technologies.