# ICENET: An Information Centric Protocol for Big Data Wireless Sensor Networks
## 2 Related Works
### Information-Centric Protocols  
The Directed Diffusion (DD) protocol [34] is a classical routing solution for sensor networks, while [PERSON] et al. [25], later, suggested the initial ideas that led to the design of the first information-centric routing protocol for WSNs. Recently, the search for alternative architectures for the Future Internet and the increasing number of IoT applications has once again drawn attention to information-centric approaches, and a number of works investigated the applicability and potential of the paradigm in WSNs [13; 16; 17; 21; 22; 26; 27; 37]. Although being a classic solution, DD relies on flooding which incurs in considerable overhead and is not suitable for large-scale wireless networks. To request information, users insert queries (called 'interests') into the network, at some arbitrary sink node. A single interest message retrieves data from multiple nodes. Initially, the sink broadcasts the received interest at a low data rate. This interest message is exploratory and aims to determine if there are nodes to respond to the received query. \begin{table}
\begin{tabular}{c c c c c c c} \hline \hline  & **PROTOCOL** & **DD**[34] & **CCN-WSN**[28] & **CCR**[35] & **COAP**[33] & **MQTT**[36] \\ \hline \multirow{2}{*}{**Approach**} & information-centric & X & X & X & & \\ \cline{2-6}  & address-centric & & & & X & X \\ \hline \multirow{3}{*}{**Transport**} & UDP & & & X & X & \\ \cline{2-6}  & TCP & & & & & X \\ \cline{2-6}  & Specific & X & X & & & \\ \hline \multirow{2}{*}{**Routing**} & Flooding & X & X & & & \\ \cline{2-6}  & RPL & & & X & X & X \\ \hline \multirow{3}{*}{**Architecture**} & request-response & X & X & X & X & \\ \cline{2-6}  & publish-subscribe & & & & & X \\ \cline{2-6}  & resource-observe & & & & X & \\ \hline \multirow{3}{*}{**Reliability**} & multiple paths & X & & & & \\ \cline{2-6}  & not implemented & & X & & & \\ \cline{2-6}  & confirmable messages & & & X & X & \\ \cline{2-6}  & \multicolumn{2}{c}{QoS levels} & & & & X \\ \hline \multirow{3}{*}{**Data from**} & yes & X & X & & & \\ \cline{2-6}  & no & & & X & X & X \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Protocol comparison. Sensor nodes also broadcast received interests, such that interest messages are flooded over the whole network. Then, if a node is a data source for an interest, it forwards a data message to each neighbor node from which the interest was received. Thus, data messages return along the reverse path of interest message propagation, so that the sink eventually receives data from multiple paths. DD adopts a mechanism called reinforcement to ensure the use of optimal routes between the sensors and the sink, and also to perform route repair. Then, after receiving data messages from multiple paths, the sink node selects one neighbor and re-sends the interest at higher data rate, according to local rules. One example of a local rule is to reinforce any node that transmits data faster than others. In order to monitor the quality of the paths and to guarantee data delivery, the sink continues to receive data from multiple paths. However, the selected path sends data at a higher rate. Furthermore, DD implements a simple caching mechanism, which is, nevertheless, not sufficient to minimize the damage of constantly flooding a resource-constrained network in both up and down directions. CCN-WSN has been proposed, in [28], as a variant of the CCNx protocol designed for PCs. Since CCNx is not directly applicable to WSNs, CCN-WSN redesigns the message format to cope with the IEEE 802.15.4 standard [38], as well as modifying the naming strategy, according to the information provided by the sensors. Then, CCN-WSN is employed straight away on top of IEEE 802.15.4, avoiding upper layer protocols in order to reduce overhead. However, CCN-WSN still has a high overhead since it relies on flooding; while nodes need to maintain a table, listing every user request. With CCN-WSN, nodes broadcast an interest message to request content.