# ICENET: An Information Centric Protocol for Big Data Wireless Sensor Networks
## 2 Related Works
### Address-Centric Protocols  
Several address-centric protocols have been proposed for IoT environments. Two of the more popular protocols are the Message Queue Telemetry Transport (MQTT) [36] and the Constrained Application Protocol (CoAP) [39]. Both MQTT and CoAP are application layer protocols, whose major difference is that the former uses TCP as a transport protocol while the latter runs on UDP [40]. The reason for designing an UDP-based application layer protocol is to avoid all TCP connection overheads for connection establishment and closing, which makes the protocol more suitable for IoT environments. Compared to other application layer protocols, CoAP presents the lowest overhead and has received widespread acceptance [41; 42]. MQTT uses a topic-based publish-subscribe architecture. Intelligent devices (publishers) send messages to an address called a topic in a server (broker). Clients register as subscribers for certain topics and the broker informs then when publishers update topics of interest. Publishers are data sources that transmit information to subscribers through the broker. The reliability mechanism offers three Quality of Service (QoS) levels for message delivery. Although MQTT is designed to present a low overhead, publishers constantly send data to the broker, even when there are no interested subscribers. This mode of operation is not efficient and causes unnecessary consumption of network resources. CoAP is based on Representational State Transfer (REST) and was developed to operate with HTTP. REST is an architectural style that makes information available as resources identified by Universal Resource Identifiers (URIs). Two architectures are supported: Request-response and resource-observe. If the request-response architecture is adopted, clients send requests to a server and receive data in response to these requests. The observe architecture allows a client (observer) to register its interest in a certain resource indicated by a URI. When the IoT device updates an URI with a new value, all observers are notified. Since UDP does not provide reliable message delivery, CoAP implements its own reliability mechanism. Messages are either confirmable or non-confirmable. Confirmable messages require an acknowledgment from the receiver node. CoAP also supports multicast messages to a group of devices [43]. However, this mode of communication presents important limitations [44]. First, multicast messages are not confirmable, and therefore no reliability mechanism is provided. In addition, multicast messages prevent the adoption of a caching mechanism. Another important drawback refers to scalability. Considering large-scale WSNs, the number of possible multicast groups may not be feasible, given the available resources. Furthermore, the cost of maintaining a multicast forwarding topology is prohibitively expensive and demands the adoption of special multicast protocols [45]. Due to the unfeasibility of multicast communication in large-scale wireless networks, a client interested in information from various data sources should address a request for each of them. Each node corresponds to a distinct URI. This means that the server must know the information provided by each of the nodes. This centralized approach generates high overhead communication to keep information about the nodes up to date. In addition, sending multiple requests to the network to get the same information is not efficient. Regarding WSNs, an energy-efficient protocol is required in order to gather the huge amount of data produced by the large number of sensors, but the strategies adopted by traditional protocols are not suitable. Flooding, forwarding a query/command to each destination node, or periodically sending data to a central device causes interference, delays, and a reduced network lifetime. In addition, centralized solutions must be avoided because of the unacceptable communication overheads involved in network topology discovery.