QoS encompasses a lot of areas. Depending on the field in which it is used, the meaning can vary slightly. QoS can refer to the capability to provide assurance that the service requirements of applications can be satisfied. QoS can also be defined as the network’s ability to customize the treatment of specific classes of data. Finally, QoS can be seen as the resource reservation control mechanisms that can guarantee a certain level of performance of a data flow. This definition, contrary to the previous ones, refers to the mechanisms to achieve a certain service quality rather than on the service quality itself.

An application’s QoS requirements are conveyed in terms of high-level parameters that specify what the user requires. These parameters can specify many different aspects of the system as the QoS term is very general. QoS parameters can also be used to measure the system performance and to control whether the QoS has actually been provided by it. We define the first set of QoS requirements as user-specified QoS and the latter as low-level QoS. By user-specified we mean the set of parameters that users can control to customize the communication between nodes in the WSAN. Low level parameters, on the other hand, measure features that are either provided by the middleware or somehow indicate its performance and cannot usually be modified by users. However, the boundaries between low-level and user-specified parameters are not well defined and other classifications are possible. For example, in existing proposals some of the low-level parameters are considered user-specified parameters and viceversa.

Developing applications for WSANs is not an easy task and many different challenges need to be faced. Many of the them are common to all distributed systems but there are many others that arise from the intrinsic nature that these devices currently present. Some of the most important challenges focusing in those related to QoS and the CIP problem are:

Resource-limited platform Current WSAN platforms have very limited resources because of the embedded character of the devices, their small size, the dynamicity they present and also because of their autonomous nature. Sophisticated protocols are needed to implement complex QoS functionality in this kind of environment. One of the most restraining features of WSANs is the limited power source they have. The capacity of current batteries used to power sensor nodes is expected to grow over time, but not fast enough to satisfy the sensor node demands. All protocols developed for these kinds of platforms need to be designed to be energy efficient. Because the most energyexpensive operation involves communicating sensor nodes using the radio transceiver particular emphasis should be put on minimizing data communication. If a node goes down as a result of a depleted battery, it is not always feasible to manually replace it. Alternatively, some energy harvesting techniques can be used in order to ensure an unlimited (under energy efficient protocols) energy source. Monitoring applications in WSANs usually relay all the information they get from the sensors to some sink nodes. As a result, memory consumption in the nodes of the networks will be unbalanced, which means, nodes near the sink nodes will receive more packet traffic than the rest. Some techniques need to be developed to balance the network traffic to the maximum extent possible. Some methods for obtaining energy efficiency are data aggregation, data fusion, duty cycling and time synchronization. Other constraint resources to bear in mind involve the bandwidth, memory, processing capabilities and transmission power of the platform.


Data redundancy One of the main features of WSANs is the high density with which nodes can be deployed. If proper algorithms are used, this redundancy can help the network to be more reliable and fault tolerant as failures in individual nodes do not affect the overall network behavior. However, redundancy affects the energy consumption of the WSAN as the same readings are gathered by physically close nodes. In this sense, data aggregation techniques can be used to reduce the information transmitted over the network and to report related readings as only one. In CIP, the redundancy is one of the most interesting factors that make WSANs useful for that goal. By deploying a high number of nodes in the environment, not only is it easier to get fault tolerance but also to balance traffic and energy consumption throughout the network for example by using duty cycling.


WSAN dynamism WSANs are highly dynamic distributed systems. The state of the network is expected to change as nodes fail, are added or their internal state changes (from or to the sleep mode for example). Also, the connectivity graph can change as the communication range varies because of a change in the transmission power or due to external factors. In addition, if node mobility is allowed, the protocols are much more complex. Designing protocols that allow node mobility and effectively provide QoS requirements is very challenging. The fact that the position of a node can vary over time makes it hard to route packets under strict QoS requirements. Routing tables are much more dynamic and neighbor discovery techniques become much more complex especially if the node mobility range is not bounded. CIP applications using WSANs, however, are usually not expected to be mobile.


Scalability Many QoS-aware protocols have been presented in the scientific literature but most of them have only been simulated. Simulation is important because it allows general information to be extracted about the behavior of the algorithm and about its suitability in a real platform. However, real platform tests should be used whenever possible since performance results significantly vary among them. Furthermore, based on our own experience, to obtain good scalability is much more difficult if the tests are done on real platforms than in a simulation. This is primarily due to the assumptions simulators make in the communications between nodes. Real nodes show a much more unpredictable behavior that needs to be taken into account. Approaches such as clustering can significantly help to improve the scalability of the system. In such approaches the network is divided into isolated clusters which can not communicate with each other. This way, traffic in the network is considerably reduced and new cluster additions are independent from existing ones. Despite all efforts made towards improving scalability, currentWSANsize is not greater than around a thousand nodes [25]. Further research will make it possible to see networks with tens of thousands of nodes, but as envisioned by the scientific community this number is expected to be much higher in the future. CIP WSANs are thought to be scalable as the number of nodes is expected to be high. This high density is used to guarantee fault-tolerance and to provide QoS.


N-to-N communications Communications in WSANs are not restricted to sensor reading delivery between sensors and sink nodes. More complex communications are also used in many proposals which involve an N-to-N communication pattern between all devices in the network. This is particularly true in networks which not only report information to the sink nodes but also can be managed and accessed at will by users. Although N-to-N communications improve the system flexibility and capabilities, this kind of communication makes it more difficult to guarantee QoS as it can be carried out between any pair of nodes at any time. Protocols need to bear that in mind and try as far as possible to balance the traffic and communication between nodes. In CIP applications N-to-N communications can be used for example to exchange messages between a set of sensors and actors to reach an agreement on how to keep track of an abnormal event.


Multiple types of traffic It is usual for some applications to share the same WSAN, each of them having their own requirements. Thus, the platform needs to support different kinds of traffic and should adapt itself to the needs of the applications, which may be at some point in conflict with each other. In the case the application requirements can not be met, the application should be notified.


QoS models Although the main subject of research in this context is to actually devise and implement solutions that provide QoS, the study of methods that simplify the task of specifying these requirements is also important. Current solutions are based on parameters that the user needs to specify and that influence the QoS configuration of the platform (e.g. priority and deadline). The configurable QoS parameters offered by the platform should be simple and the unit used for every parameter should follow a standard, if possible. Also the number of parameters offered should constitute a small but complete set that allows the developer to specify all possible requirements in the platform. Lastly, it is important to bear in mind that the programming abstraction used for the system is going to influence the way in which QoS requirements are specified.


Real-time/reliable platforms The distributed nature of this technology makes it impossible to provide 100% reliability in the delivery of messages. However, by means of protocols, the delivery probability can be raised to acceptable levels. To provide such features, complex protocols need to be used, which in turn have a negative influence on other aspects of the system such as energy efficiency or scalability. Most of the current solutions only provide soft real-time assurance. This is due to the limited real-time and reliable capabilities of the underlaying platform over which the application runs. In order for a protocol to provide hard real-time properties, the operating system of the platform where it runs needs to support it. An example of a platform of this kind is uC/OS-II. Although, hard real-time is usually the appropriate choice for CIP, sometimes using a soft real-time platform with good QoS support algorithms may suffice.


Energy efficiency It is obvious that the more tasks need to be done, the more time they will consume. In this sense, providing QoS requires additional effort in terms of computation, memory and communication. All these things have an important effect on the energy consumption. It would be interesting to study under what circumstances this extra energy consumption is worth it and moreover to adapt the network to dynamically choose the best configuration to provide the QoS requirements specified. More generically, the study of trade-offs is important in the way that it allows the network to adapt itself to the application needs ensuring that no extra computation or communication is wasted. This study is particularly interesting in the CIP problem where the availability of these kinds of systems needs to be high and the life time of the network needs to be maximized.


Standardization As the WSAN field is still being developed, some standards have appeared which try to establish common ways of providing functionality at physical, link and even network layer (ZibBee, 6LoWPAN, WirelessHART). However, standard QoS handling procedures are not well defined yet. This is due to the relatively little research on the area of QoS in WSANs. One of the challenges to overcome is to achieve a generic way of providing QoS that satisfies the needs of all users. Currently, there is much interest in the development of IPv6 support over WSANs in an attempt to standardize the protocols in WSANs, to reuse the knowledge about IP networks and to connect WSANs to existing wired and wireless networks throughout the world. The 6LoWPAN protocol, for example, defines the encapsulation and header compression mechanisms that allow IPv6 packets to be sent and received over IEEE 802.15.4 based networks The use of IPv6 in CIP WSAN is interesting. This would allow the network to be queried over the internet, for example from a SCADA system that can be used to monitor the state of the CI and the WSAN. The choice of a proper standard greatly simplifies the task of achieving interoperability between this SCADA system and the WSAN.


Cross layer architecture The layered design of communication protocols such as TCP/IP has given really good results in terms of simplicity, scalability. The layered design makes it possible to change or update parts of it without affecting the whole protocol. However, the inflexibility and suboptimality of this paradigm result in poor performance for multihop wireless networks in general and more specifically for WSANs, especially when the application has high bandwidth needs and/or stringent delay constraints. Cross-layer design allows communication between layers (such as physical and network layers) which traditionally have been independent in order to exchange more information that can be used to improve efficiency. The traditional layered approach should be used if requirements can be met without applying a cross-layer design. However, WSAN platforms usually resort to cross-layer techniques in order to maximize the performance.


QoS protocol integration Many protocols have been proposed that deal with some QoS aspects. Many of these works describe a protocol that has been evaluated by means of a simulator. In order to actually confirm that all this work can be applied to real examples we think that it is useful to make a greater effort to try to integrate different algorithms and strategies in a complete system and test its performance using real devices. Although simulators have their place, we believe that what really validates the usefulness of a set of proposals comes as a result of developing a complete system that takes into account the knowledge gathered in the field. A protocol that seems to perform well may not work well when used in combination with others and using real devices.


QoS monitoring and application development Considerable effort is being invested in developing ways of providing QoS. However, it is also really important to be able to monitor and study the results taken from the WSAN. Techniques need to be designed that allow the network state to be queried and to keep track of the way it evolves. Also, development tools need to be refined. In this sense, node debugging and node code deployment are still arduous tasks and further development is expected to be done in the area of WSAN simulators. Other areas such as the implementation of IDEs that allow programmers to simplify the tasks of developing WSAN applications are much more developed.

In addition to studying QoS challenges and issues for WSANs, several MAC, routing, hybrid protocols and middleware have been analyzed in this work and can be found here.

This last section presents a possible classification of the main desirable properties at each communication layer. Not all QoS parameters are included, only the main features a CIP system needs. Besides, some of the parameters can be offered at different layers as in the case of reliability but it has only been included in the layer that usually provides it. This classification can vary depending on the specific needs of each scenario but it is expected to be useful as a guideline when implementing a WSAN for a CIP system.

The physical layer (first layer in the OSI model) is platform dependent and therefore has not been included in the figure.

Layer 2 accommodates the MAC layer. This layer has a great impact on the WSAN’s performance and therefore needs to be energy efficient. Also, all upper layers rely on the functionality provided by the MAC protocol. This means that ideally the MAC layer should handle different traffic classes (manage priority). This property, however, can also be provided at network layer as many proposals in the literature do. The MAC protocol cannot be dependent on the underlying distribution of the nodes, that is, it should be flexible enough to efficiently handle different network topologies. Finally, the use of cross-layer interactions between the MAC protocol and the network protocol seems an interesting approach to improve performance.

The routing protocol stands at the network layer and allows multi-hop delivery of information between motes. Because important nodes in centralized algorithms can be subject to attack, it is advisable to opt for a non-centralized one. Fault tolerance and reliability are two important parameters that the routing protocol needs to provide in CIP systems. In some approaches these two parameters are offered in the MAC layer or even at transport layer rather than in the routing protocol. Critical data needs to be delivered on time in order to act against possible failures or attacks, so bounded delay is also an important task of the network layer.

Layers above the network layer provide a way for developers to specify their needs and the behavior of the application. On the one hand, a higher level of abstraction is needed, for example, in the form of a middleware. This allows programmers to simplify the task of programming application and leaves certain repetitive tasks, such as communication or node discovery, in the hands of the middleware, making programs less error-prone. On the other hand, QoS requirements should be specified in a flexible way that allows programmers to map their QoS needs to an appropriate network configuration.