## 4 Foundations of HWSNs
### Communication Links  
As previously mentioned, each node in a HWSN has at least one data communication interface and it is able to process network messages. The capabilities of a communication interface depend on the technology used to implement it (e.g., WiFi, Bluetooth, infrared or 3G). Particularly, the use of a specific technology determines the communication threshold between two network nodes, the bandwidth of the communication channel and the reliability of the link between nodes. The reliability of the link also depends on the demand for message transportation received by the channel. For instance, the communication requests after a disaster (e.g., an earthquake) surpass largely the bandwidth available in cellular networks. Thus, a regularly reliable network is rendered unreliable for a certain time period. In HWSN we assume that the link between two nodes can be classified into: _stable_, _unstable_ and _null_. The link is stable (_i.e._, reliable) if there is a high probability (over 2/3) that two nodes can communicate between each other when required. Reliable links must be implemented among nodes that need to communicate in a rapid manner or that work in a tightly-coupled way; for instance, between a sensor that detects smoke and the processing unit that activates the sprinklers. Figure 4: Roles composition for a node. Unstable reliability means that the probability for effective communication between two nodes is between 1/3 and 2/3.This communication should be provided between nodes that exchange non-sensitive or critical information. The coupling among nodes using an unstable link should be loosely-coupling; for instance a node that needs the help of a rule to disseminate a low-priority message. Finally, the link will be null if there is not a direct link between the nodes that need to interact or if the probability to have an effective communication is low (e.g., below 1/3). In this case, the nodes could interact using intermediary nodes, for instance through a rule. This segmentation of quality links is inspired by recommendations made for managing the communication links in groupware applications [32]. The use of routing strategies in this scenario should be analyzed carefully, because it could result in more drawbacks than advantages. For instance, the energy consumption of the nodes and also the number of messages in the network can rise considerably, generating thus an early collapse of the supporting network. The information sharing between these nodes can be done using witness units. Figure 5 illustrates the type of interaction that is usually present among nodes that play different roles. The interaction based on information tends to be more coupled than the interaction based on messages, therefore the communication links between nodes exchanging information (e.g., the components of an HBS: sensor, human-input, processing unit and actuator) should be as stable as possible. The interaction with mules or witness units is loosely-coupled, therefore the communication link could become unreliable. Of course, the higher the reliability of the communication links, the faster the communication process. Designers of IoT-based systems should try to have links as reliable as possible; however in several scenarios, like in disaster relief efforts, having a stable link is almost impossible [4,15]. The temporal instability of the link could be addressed using multi-hop communication, as proposed in [33]. Estimating the quality of the communication links that would be available in the field will allow designers to determine several features of the solution; for instance: how fast the information can be disseminated through the network, which nodes are causing a bottleneck, or what percentage of nodes can receive a piece of information in a certain time period. Based on these results, the design of the system can be improved in an evolving way during the design time. Thus, the system can be implemented once its features have been determined analyzing the capabilities of the system model.