This article presents a novel approach to the analysis of wireless sensor networks (WSN) security, based on the regulations intended for wireless communication devices. Starting from the analysis and classification of attacks, countermeasures, and available protocols, we present the current state on secure communication stacks for embedded systems. The regulation analysis is based on civil EN 50150 and MIL STD-188-220, both applicable to WSN communications. Afterwards, starting from a list of known WSN attacks, we use a correspondence table to match WSN attacks with countermeasures required by regulations. This approach allows us to produce a precise security evaluation and classification methodology for WSN protocols. The results show that current protocols do not present a complete coverage of security issues. While this conclusion is already known for many WSN protocols, to the best of our knowledge this is the first time a complete methodology is proposed to base this assertion. Moreover, by using the proposed methodology, we are able to precisely identify the exposed threats for each WSN protocol under analysis.
Security assessment of a wireless sensor network (WSN) protocol is a critical issue for a wide range of applications, increasingly pushed by the Internet-of-Things trends. WSNs present peculiar characteristics regarding security feature implementation, because their applications generally address low-energy and battery powered embedded devices, in which the main requirement is to minimize the computational power. Therefore, security attack countermeasures should be implemented with careful attention, due to the limited resources in the system.
This paper aims at identifying a set of measures that should be taken into account while choosing or designing a communication protocol for WSNs, in order to achieve system security and low overhead at the same time. We start with an analysis of the main issues related to security in sensor networks (even if the considerations could be extended to all battery-powered radio devices) where resources are limited and their optimization is a mandatory requirement.
The paper is organized as follows: Section
Differently from other approaches [
There are three features intended to be addressed while dealing with a secure protocol in WSNs [
WSNs are very peculiar from the point of view of security, since they can be subjected to a huge range of vulnerabilities, but at the same time they have few resources to face them. Actually, WSNs are affected by all the known vulnerabilities of a linked network, with the addition of the following:
Depending on the nature of the attacker, vulnerabilities can be classified as follows [
Moreover, the attacker can perform different kind of activities depending on his capabilities that can be classified as follows:
If an attacker can propagate a DoS by compromising other members of the network or moving through the network, the attack is called Dynamic DoS (DDoS). Two main groups of DDoS attacks can be identified [
Most sensor network protocols feature self-organization of the network and on-demand discovery of the path at routing level; hence there are no problems if one or few nodes cease to exist because of DoS attacks. Things change in case of an increasing number of attacked nodes. Existing WSN solutions completely break down when more than a certain number of nodes are compromised.
End-to-end security mechanisms are generally too computational expensive due to the limited resources available in sensor networks. In [
In this section, we present taxonomy of attacks and common defenses, classified by the communication layer at which they are usually performed [
The purpose of this kind of attacks is keeping busy the communication medium used by the network and introducing RF interferences at the same frequency used by the network. In some literature works they are also reported as “collision” attacks related to link layer.
The result of jamming is that packets on air are damaged, or they are never transmitted, if nodes have a collision avoidance mechanism which reports an always busy medium.
A common defense to this attack is the adoption of spread-spectrum techniques for transmission. Namely, there are two different approaches: FHSS (Frequency-hopping spread spectrum), which is somewhat resistant to an attacker who does not know the hopping scheme, but it may be simply tracked by scanning the transmission. DSSS (Direct-sequence spread spectrum), which is more efficient against this kind of attack, since it relies on a wider RF spectrum.
Both types of spread spectrum countermeasures may be neutralized if the attacker is capable of performing a wideband and high-power jamming attack.
In this case the attacker gains physical access to a node belonging to the WSN; for example, the node may be physically destroyed or intentionally altered.
Defenses against tampering can be adopted at protocol level (i.e., the communication protocol knows that some node may be destroyed and is designed to keep the network operational even in that occurrence) or at physical level, for example, through geographical separation of nodes, camouflages, or antitampering node packaging. However, these solutions may be expensive and easily bypassed if proper tools are used.
This attack is performed by inducing a node to continuously retransmit a packet until the battery of the node is exhausted. This is possible, for example, in protocols that schedule a retransmission when an acknowledgment packet is not received. However, each part of protocol code that schedules a transmission may be attacked and forced to induce exhaustion.
In the IEEE 802.11-based protocols, for example, Request To Send (RTS) and Clear To Send (CTS) packets are used to reserve bandwidth before data transmission. A compromised node could repeatedly send RTS packets in order to elicit CTS packets from a targeted neighbor node, consuming battery power of both nodes. In other protocols, an attacker node sending “path discover request” may induce exhaustion if the malicious node that continuously sends this kind of requests induces the receiving node to respond.
A defense against this type of attack can be implemented by limiting the number of transmissions even to authenticated nodes.
Many protocols use an exchange of
This attack can be avoided by verifying link bidirectionality, assuming that a legitimate node has the same radio capabilities of other WSN nodes. Authentication may be another solution.
Two distinct malicious nodes usually implement this attack. It consists in tunneling packets from a malicious node that sniffs packets to a remote malicious node with long-range radio.
In case an attacker node uses the same hardware platform of the other nodes in the network, a defense against this attack could be implemented by designing a reduced radio range, in order to achieve the required coverage but at the same time avoiding remote replies. A more general countermeasure adopts a geographical routing scheme with timestamps inserted into packets. This measure adds information about node position in each packet that can be used to compute its Time Of Flight (TOF), hence rejecting packets coming from “too distant” nodes.
In a sinkhole attack, a malicious node attracts traffic from a particular area. All traffic of the area is diverted to the attacker node. The attack is accomplished by compromising the routing algorithm in order to induce source nodes to see a particular node always as “next hop.” In that way all traffic will be redirected through the malicious node. If it never forwards packets to neighbors, the attack would be called
The attack can be avoided using route algorithms resistant to an arbitrary configuration or using a geographical routing.
In this attack, the malicious node assumes multiple identities. This kind of attack undermines a distributed solution counting on cooperation. It may be used, for example, to break a cryptographic distributed scheme.
Networks can be defended from the Sybil attack by location verification routines, to be sure that a node is really there where it claims to be, or with proper authentication method to avoid identity fraud typical of this attack [
This class of attacks is focused on altering routing information in several ways, for example, modifying routing packets exchanged between nodes. In on-demand routing protocols that schedule an answer to a path discover request, an attack called
Another kind of bogus routing attack is the
Defenses against this kind of attack can be implemented authenticating nodes that send updating route info, while a refresh mechanism may avoid keeping corrupted route data in the network.
A malicious node linked to the network can selectively drop certain packets, usually to favor a route direction. This attack is also known as “
Defenses against this kind of attack can be implemented by using multiple nonjoined routing path obtained using different algorithms.
This kind of attack is based on theanalysis of traffic patterns in order to identify and target nodes that have special responsibilities. For instance, in a geographic routing scheme, the analysis could allow an attacker to figure out where important nodes are, such as cluster-heads or cryptographic-key managers.
A defense against this attack can be implemented by encrypting headers as well as content [
Vulnerabilities at transport and higher layers are introduced a wireless sensor network is interfaced with IP-based networks. Up to this point we considered WSN protocols that do not necessarily implement an IP-based communication. Note that from this layer to onwards, the typical security issues of IP-based communications become part of the issues of the WSN architecture; since they are common to IP networks, they will not be addressed in this work.
Figure as a relay of commands received by remote users toward the WSN; as a data storage system, in which the proxy collects data from WSN and stores them in a database, while users perform query on proxy database to read sensor network data.
Interconnection of a WSN with remote human interfaces via proxy.
The limited standardization in the WSN world and the consequent huge variety of protocols let foresee that it is impossible to design general proxy architectures. So, each proxy will have vulnerabilities linked to the specific sensor network it refers to. However a proxy is potentially dangerous for the existence of the WSN itself if configured as a relay, since a malicious user able to gain proxy authentication, could, for instance, flood messages through the WSN and perform an exhaustion attack. On the other hand, a proxy that implements a standard interface for a database is exposed to common database attacks. In both cases, if the proxy fails, for a remote user there is no way to access WSN data.
A particular approach consists in introducing redundancy at proxy level, since it could be the bottleneck of the network, through the adoption of a delay tolerant architecture [
In this section we report the standards that are considered relevant for wireless communications for embedded devices. In particular, we focus on the civil standard [
EN 50159, also issued as IEC62280, addresses a huge range of security issues for safe communications in railways systems. In particular, “Part1” and “Part2” detail security issues for closed or open, nontrusted transmission systems [
In WSNs and embedded networks in general, constraints on power consumption and low computational capacity lead to the diffusion of these requirements through the whole protocol definition, in order to optimize available resources.
In EN 50159-2 the following threats are listed:
Moreover, in the analysis conducted by [
MIL STD-188-220 is a military communication standard first released in May 1993, while the latest revision “D w/Change 1” was released in June 2008 [
The standard, approved by the US Department of Defense, defines protocol architectures for inter- and intracommunications within Digital Message Transfer Devices (DMTDs) that take part to Command, Control, Communications, Computer, and Intelligence (C4I) systems. In particular, it defines the lowest communication layers for DMTDs, including wireless embedded devices that take part to the network.
Since it is a military standard, the main focus is on reliability of the protocol. In particular MIL STD-188-220 describes the physical and data-link layers of the communication stack used in wireless devices to exchange VMF messages (Figure
The VMF stack layers.
Here we analyze some of the defense mechanism implemented in this protocol, starting from the lowest communication layer, focusing on mechanisms related to asynchronous transmission and on Communication Security (COMSEC) issues, embedded in the communication protocol description.
The transmission frame derived from the standard is reported in Figure
Transmission frame structure with embedded COMSEC.
Excluding phasing and postamble fields, used for bit-synchronization and end-of-transmission flagging, our attention will be focused on transmission synchronization and data fields. They are specified as in Figure
Transmission synchronization field.
The most important fields related to security issues are The
As for the security mechanism, at data-link layer MIL 188-220 adopts the following strategies:
This list of countermeasures adopted by MIL 188-220 will be kept as a reference for the construction of a complete countermeasure list for WSNs.
In this section we expose validation methods used for evaluating computer system security. We aim at finding out methodology guidelines for validation of security countermeasures in WSN systems.
Common criteria (CC) for Information Technology Security Evaluation [
The following paragraphs contain a description of the framework key-points. In the following, the “target of evaluation” (TOE) is the system to be evaluated in its security claims.
Usually a user community or government institution creates a protection profile (PP), that is, a collection of security requirements for a class of IT products. It can be focused on a target user or a particular application of the TOE.
Security target (ST) describes a set of properties of the specific TOE that fulfill the requirements that are expressed in one or more PPs.
Three groups of actors are involved in the security evaluation.
Evaluation is conducted against countermeasures reported in ST. Two kinds of countermeasures are classified in the framework, countermeasures related to the TOE that must be verified and countermeasures related to the operational framework (safety, operational environment, etc.) that are not verified.
Evaluation of the countermeasures adopted to defend assets from threats goes through two steps. Evaluation of counter measure sufficiency. The ST describes the adopted countermeasures as security objectives. These are detailed in security functional requirements (SFRs), written in a standardized language, described in Part II of [ Evaluation of countermeasure correctness. If adopted countermeasures are correct, threats are cancelled. Security assurance requirements (SARs) detail requirements needed to fulfill correctness. Evaluation of correctness is then determined by applying SARs to “evaluation evidences,” that is, to a series of tests that can be heterogeneous and various in their nature.
According to the criteria exposed above, our work proposes that a wireless communication protocol should deal with SFRs related to “class FCO communication,” that is, “
The first SFR has dependencies with “
The complete validation of a protocol with CC is out of the scope of the article, but criteria are taken into account as reference to increase security requirements of a model of WSN TOE and list countermeasures needed to accomplish such requirements. Results are presented in Table
Defense methods versus CC requirements.
SFRs | Counter measure |
---|---|
FCO_NRO |
|
FCO_NRR |
|
FIA_UID |
|
FDP_ITT |
|
FDP_ACC |
|
FDP_IFC | I/O are physically defined in RF circuits |
FDP_IFF | Handshake in PtP link |
FDP_UIT |
|
This analysis points the light to the need of having an accurate flow control and an active logic on the node that dynamically scans anomalies in received packets.
The analysis of threats conducted in [
Description of defense methods against threats.
ID | Defense method | Used against Threat ( |
---|---|---|
A |
|
1; 2; 3; 4 |
B |
|
1; 4; 6 |
C |
|
2; 6 |
D |
|
3 |
E |
|
3; 7; 9 |
F |
|
3; 7 |
G |
|
5 |
H |
|
5; 7 |
I |
|
1; 2; 3; 4; 5 |
J |
|
8 |
K |
|
8 |
L |
|
1; 2; 4; 5; 8; 6; 10 |
M |
|
1 |
N |
|
8; 6 |
O |
|
1; 6; 8 |
P |
|
3; 7 |
Threats discussed in this standard are quite general and can be addressed to a wide range of communication protocols, not just wireless ones.
We can link the considered threats list (Section
Connection table between WSN attacks taxonomy and EN50159 threats.
Threat | Attack | |||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
X | X | X | X | ||||||
|
X | X | X | X | X | |||||
|
X | X | X | X | X | |||||
|
X | X | ||||||||
|
X | |||||||||
|
X | X | X | X | X | X | ||||
|
X | X | ||||||||
|
X | X | X | |||||||
|
X | X | X | |||||||
|
X | X |
Table
Particular attention should be mentioned for the tampering attack, as it comes out that tampering is not a common attack covered by regulations. This could be due to the “drop and forget” nature of a WSN node and to the reduced physical dimensions. As from Section dynamic routing, which consists in a routing protocol that does not use static routing tables, but can rearrange routing on-the-fly, if required; antitamper enclosure, which is a physical countermeasure that aims at detecting physical node manumissions. Since this is a physical countermeasure, not related to the protocol stack, it will not be introduced in Table
Using data in Table †—countermeasures related to numeric manipulation and transformation of packets; ‡—countermeasures that act on physical handling of packets; #—countermeasure that act on queuing policies; ##—countermeasures related to node monitoring and identification; $—directives on routing scheme.
Correlation between defense methods and WSN attacks.
ID | Defense methods | Attacks | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|||
A |
|
3 | — | 2 | 2 | 2 | 1 | 3 | — | 2 | 1 | * |
B |
|
2 | — | 2 | 1 | 1 | 1 | 2 | — | 2 | 1 | |
D |
|
1 | — | 1 | 1 | 1 | — | — | — | 1 | — | |
P |
|
1 | — | 1 | 1 | 2 | — | — | 1 | 1 | — | |
|
||||||||||||
C |
|
— | — | 1 | 2 | 2 | 2 | 1 | — | 1 | 2 | ** |
E |
|
2 | — | 2 | 2 | 1 | — | — | 1 | 1 | — | |
I |
|
4 | — | 2 | 2 | 2 | 1 | 3 | — | 2 | 1 | |
O |
|
2 | — | 2 | 1 | 2 | 1 | 2 | — | 2 | 1 | |
|
||||||||||||
G |
|
1 | — | — | — | — | — | — | — | — | — | † |
H |
|
1 | — | — | — | 1 | — | — | 1 | — | — | |
|
||||||||||||
K |
|
1 | — | — | — | 1 | — | 1 | — | — | — | ‡ |
M |
|
1 | — | 1 | — | — | — | 1 | — | 1 | — | |
|
||||||||||||
L |
|
5 | — | 3 | 2 | 3 | 2 | 5 | — | 2 | 2 | # |
N |
|
1 | — | 1 | 1 | 2 | 1 | 1 | — | 1 | 1 | |
|
||||||||||||
F |
|
1 | — | 1 | 1 | 2 | — | — | 1 | 1 | — | ## |
J |
|
1 | — | — | — | 1 | — | 1 | — | — | — | |
|
||||||||||||
Q |
|
— | 1 | — | — | — | — | — | — | — | — | $ |
This last classification will be used during the layering of each countermeasure, that is, the introduction of a particular countermeasure into a specific communication protocol layer.
In this section we apply the correlations reported in Table
We group the protocols taken as case studies according to security features: intrusion detection and intrusion tolerance protocols: this class refers to features related to detection and tolerance of intrusions; routing layer protocols: this class refers to routing protocols. A general overview is available in [ whole atack protocols: protocols of this class offer countermeasures at several layers.
An overview of each analyzed protocol follows.
The AODVSTAT [
AODVSTAT is a sophisticated algorithm for the detection and reaction to a great variety of potential wireless network attacks; unfortunately it is quite computationally expensive.
This method adopts cooperative and distributed detection algorithms [
INSENS [
It reduces damages done by intruders by limiting flooding and using appropriate authentication mechanisms, based on symmetric-key cryptography. Moreover it allows alternative network routes to be established between non-malicious nodes. While not providing a real intrusion detection, but rather intrusion tolerance, it still requires a certain number of wireless sensor nodes completely dedicated to this purposes.
Ad hoc on-demand distance vector is a popular reactive routing algorithm. It is also the routing scheme adopted by ZigBee [
When a node of the WSN receives a packet addressed to an unknown destination, it starts sending a “route discovery” packet. This message is flooded through the network until a receiving node finds an entry in its routing table and answers to the request. Each flooded message sets on the receiving device a path in his routing table, since the source of the received message is an in-sight node. In that way, when the message reaches the discovered destination, a backward path is already set.
This kind of protocol introduces a lot of traffic overhead due to path discover flooding. If an attacker log in a relay proxy and is able to generate path discover requests, asking for bogus addresses, a lot of messages overhead will be generated, performing in an easy way an exhaustion attack.
The temporally ordered routing algorithm (TORA) is an adaptive routing algorithm stacked over the internet MANET encapsulation protocol (IMEP).
TORA logically organizes the WSN nodes as a DAG (directed acyclic graph) using both proactive and reactive path discovering schemes [
TORA supports on-demand path discovery very similar to AODV. The protocol uses a particular optimization to perform pro-active routing and adjust the height of the DAG through WSN nodes [
This protocol inherits weaknesses of AODV, but limits flooding of “path search” messages with respect to it. Malicious packets spread through the network may compromise the delicate logical organization of a DAG and generate a huge packet overhead to recover the scheme.
The dynamic source routing protocol (DSR) is a flow oriented routing protocol based on mechanism of route discovering and route maintenance [
ZigBee defines a security layer based on IEEE 802.15.4 [
Particular features of security functions implemented in Zigbee are it maintains a counter on incoming and outgoing messages to implement reply protection; number of integrity bit in a frame can be chosen from 0 to 128; authentication and encryption can be chosen between two modes, one key shared from all nodes or one key for each pair of nodes. This last case has a higher memory cost; a node can become a “trust center” to provide security keys.
This protocol [
This protocol provides security in node-to-node communications [
This protocol [
This protocol implements encryption and authentication. It operates in two modes [ authenticated encryption (TinySec-AE); authentication only (TinySec-Auth).
In this protocol packets are partially encrypted, avoiding encrypt/decrypt at each hop.
TinySec explicitly omits replay protection, recommending it to be performed at application layer.
TinySec has been incorporated in TinyOs releases. It requires 728 bytes of RAM and 7146 bytes of program space. The energy overhead imposed by TinySec is 3% for TinySec-Auth and 10% for TinySec-AE.
While TinySec achieves low energy consumption by reducing security countermeasures and ZigBee implements good security features, but suffers for high energy consumption, MiniSec [
MiniSec has two operating modes, one tailored for single-source communications and another tailored for multisource broadcast communications.
In Table
Minisec performances compared to other protocols.
Payload (B) | Packet overhead (B) | Security overhead (B) | Total size (B) | Energy (mAs) | Increase over TinyOS | |
---|---|---|---|---|---|---|
TinyOS | 24 | 12 | — | 36 | 0.034 | — |
TinySec | 24 | 17 | 5 | 41 | 0.0387 | 13.9% |
SNEP | 24 | 20 | 8 | 44 | 0.0415 | 22.2% |
MiniSec | 24 | 15 | 3 | 39 | 0.0368 | 8.3% |
The ISA100.11a protocol has been developed by ISA100 committee, formed in 2005. In 2009 it was announced the first release of ISA 100.11.a [ link-local addressing; message forwarding; PHY management; adaptive channel-hopping to avoid occupied channels message addressing, timing and integrity checks; detection and recovery of message loss; clock synchronization.
Some of these features can be directly found in the structure of data link layer protocol data unit (DPDU), shown in Figure
ISA100.11a DPDU.
The protocol is designed to be extremely flexible in terms of layers composition, but nodes that implements different version of this standard may not interoperate.
Introduced into the market in 2007 and approved by the International Electrotechnical Commission (IEC) in 2010 as IEC 62591, the standard is based on the HART “user layer” and the 802.15.4 physical/MAC layers [ message integrity code (MIC): this is a sort of CRC code calculated over the whole payload and used during authentication; counter: a 4 byte counter used to create the cryptographic security control byte: a header byte used to define the used security features.
The protocol handles transmission failures through retransmissions using dedicated and shared time slots through different paths in the routing graph [
WirelessHART DPDU.
Here we present a chart which contains the countermeasures identified with the methodology introduced in Section
WSN protocols comparison chart.
|
|
|
|
|
|
|
|
|
|
|
|
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
X | — | — | X | X | X | X | X | — | X | X | X |
|
X | — | — | X | X | X | X | X | — | X | X | |
|
X | — | — | X | — | — | X | X | — | X | X | |
|
X | X | X | X | X | X | X | X | X | X | X | X |
|
X | — | — | X | X | X | X | X | — | X | X | |
|
X | X | X | — | — | — | X | X | X | X | X | X |
|
— | — | — | — | — | — | — | X | — | X | X | X |
|
— | — | X | — | — | — | X | X | X | X | X | X |
|
— | — | — | — | — | — | — | — | — | — | X | X |
|
X | X | X | — | — | — | — | — | — | — | — | — |
|
X | — | — | — | X | X | X | — | — | X | X | X |
|
— | — | — | — | — | — | — | X | — | — | X | X |
|
— | — | — | — | — | — | X | X | — | — | X | X |
|
X | — | — | X | X | X | X | — | — | — | X | X |
|
— | — | X | — | — | — | — | — | — | — | X | X |
|
— | — | — | — | — | — | — | — | — | — | — | — |
|
X | — | X | X | X | X | X | — | — | — | X | X |
* | ‡ | $$ |
We can see that all the listed protocols offer some kind of counter measures against security threats. Even protocols not specifically designed for security offer some points of strength. Some of the protocols address just a specific communication need and implement only particular countermeasures, relying on lower layers to integrate security requirements. Usually this approach increases the stack size and resources needed by nodes, since no cross-layer-optimizations can be performed.
Protocols that face “intrusion detection and tolerance” (Section
Nevertheless, it is possible to see from Table
These observations lead to the following conclusions: regulations sometimes require more than one countermeasure against the same threat; none of the analyzed protocols has a full countermeasure coverage; the coverage is usually obtained through several firmware stratifications and relying on lower communication layer functionalities, with no interlayer optimization.
We also want to remark that facing all security issues at the lowest communication layers could not even be possible for some embedded platforms that offer a limited access to hardware driver functions.
According to these conclusions, the choice of implementing a communication stack fully customized can introduce the following advantages: covering all countermeasures; offering a lightweight implementation through intralayer optimization and sharing of functionalities.
These main directives should be kept as guideline to design security in protocols dedicated to low-power devices.
We presented an overview of general security issues for WSNs and introduced attack taxonomy to catalogue common attacks. The proposed taxonomy is built by analyzing attacks and countermeasures related to each OSI layer involved in the communication, from the physical to the transport layer.
Then we focused on existing standards and in particular the civil EN 50159 and the military MIL STD-188-220D w/Change 1, to find out suitable countermeasures, solutions, and architectures. In order to validate the countermeasure list, an evaluation of the common criteria regarding wireless protocols was produced. In particular these criteria offer a list of security requirements that a generic “target of evaluation” has to fulfill according to its functionalities.
The complete list of countermeasure was finally mapped in conjunction with the taxonomy introduced for wireless and ad hoc mobile sensor networks. As a result, all identified attacks in WSN have been linked to a countermeasure.
Finally, we applied the methodology to the evaluation of popular protocols for wireless sensor networks. The common characteristic we found is that security functionalities are spread between several layers. This generally affects the protocol by decreasing performances, since security implemented in this way introduces an overhead that can hardly be reduced through optimization and sharing of functionalities.
None of the analyzed protocols covers all security requirements, but the most recent ones seem to cover all threats. In particular, WirelessHART also seems to point out a lightweight solution and a degree of inter-layer optimization.
Future work will leverage on this study to design a new WSN protocol, specific for homeland security and in particular for area monitoring and threats recognition applications, in the view of overcoming all the identified security issues.
The authors declare that there is no conflict of interests regarding the publication of this paper.
Experiments were conducted in WSN laboratory of Selex ES.