Efficient data delivery based on content-centric networking for Internet of Things applications

Abstract

Content-centric networking is a new networking paradigm for efficient data distribution in various environments including wireless sensor networks. It is likely that everything which benefits from networking will be connected. Recently, we have seen a huge proliferation of heterogeneous wireless devices, sensors, and distributed applications. These devices may generate a vast amount of time-constrained data. Content-centric networking is greatly useful to increase the data availability and the efficiency of data delivery. Internet of Things will enable all the communication devices to be interconnected and make the data generated by or associated with devices or objects globally accessible. In this article, we propose a possible architecture, necessary components, and related mechanisms for efficient data delivery in the wireless Internet of Things environment, which is based on content-centric networking. We also present simulation results to show the feasibility of the proposed architecture.

Keywords

Data delivery sensors Internet of Things

Introduction

The Internet sometimes called “network of networks” was created in the early 1960s with the goal to connect computers and allow them to share data. It was established to solve a main problem of sharing resources in the research community. During the past several decades, the Internet has evolved and nowadays represents the major means of communication that allows a number of users and devices in the world to access services and retrieve various information. The Internet has been greatly successful ever since its creation and has become a highway for globalization and an effective means for networking various devices and providing services and knowledge. Its size, complexity, and the role it plays in the modern world have far exceeded the initial expectations.

Billions of interconnected heterogeneous devices, ranging from wireless sensors to actuators, smart home appliances, and many other wired or wireless physical objects are able to interact and cooperate with each other and other things/objects to create a new context-based application or service with a common goal of creating a smart world. The Internet of Things (IoT) refers to the ever-growing network of these devices/things. IoT extends the Internet connectivity to a diverse range of devices and things that utilize the embedded technology to communicate and interact with the external environment. This emerging IoT technology has been adopted by many application areas, for example, remote sensing, real-time traffic monitoring, weather monitoring, military surveillance, health care, civil structure monitoring, fire detection, smart home management, and many other areas related to the real life.

The need for connecting and integrating the massive amount of devices at a global scale has naturally led to the future IoT vision. There are two main challenges in IoT: anytime connectivity and communication with anything. Today’s Internet is based on the host-to-host communication paradigm. In other words, it is based on the point-to-point connection, which eventually means that every connected device has to be uniquely addressable and should be dealt with differently. Most of current communication protocols in the IoT rely on point-to-point connections and are therefore vulnerable to link failures. Many improved solutions including p2p,¹ proxy-oriented,² and cloud-based^3,4 approaches were proposed and used with the current Internet, but they cannot resolve the single point of failure problem. We have also seen that the protocol incompatibility of today’s communication networks drives the IoT concept toward a bunch of sparse sensor networks. ZigBee, one of the most popular wireless sensor network (WSN) technologies, has implemented its own protocol stack on top of the data link layer.

Content-centric networking (CCN)⁵ is a new networking paradigm which is not based on the point-to-point scenario and provides a common protocol platform for all types of communicating devices. Also data can be stored at intermediate nodes as well as the original source. Since IoT devices may generate massive amount of data and thus will bring enormous challenges with respect to transport over the Internet, an architecture like CCN⁶ will clearly be a suitable choice.

In this article, we define a possible network architecture and necessary components for efficient data delivery in the wireless IoT sensor environment, which is based on CCN. Our goal is to show that it is possible to implement communication mechanisms for IoT with the following features:

No end-to-end connection;

Transparent in-network data storage of sensor data;

Reduced workload for the sensor devices;

Synchronized and live data.

Specifically, we propose a new query merging and in-network aggregation mechanism to reduce the workload of the network. We also propose a new data retrieval mechanism from the edge sensor to ensure data liveliness. The rest of this article is organized as follows. Section “Related work” describes the recent work related to sensor networks, IoT, and CCN. Section “An architecture for efficient data delivery in the wireless IoT environment” presents an architecture, necessary components, and related mechanisms for efficient data delivery in the wireless IoT environment in detail. Section “Implementation and experiments” describes implementation details and performance issues, and finally, section “Concluding remarks” concludes this article.

Related work

The WSN is a wireless network that behaves as a digital skin and consists of spatially distributed autonomous devices with sensors, providing a virtual layer to monitor physical or environmental conditions using any computational system. There are many different types of sensors such as seismic, low sampling rate magnetic, thermal, visual, infrared, acoustic, and radar, which are able to monitor a wide variety of ambient conditions that include many aspects like temperature, humidity, vehicular movement, lightning condition, pressure, soil makeup, and noise levels.⁷

It is a big challenge to provide an efficient and reliable communication paradigm for WSN data transmission. Many data transmission and processing systems have been proposed for WSN to acquire the high throughput. The single-hop data-gathering system⁸ is a new data-gathering system for large-scale WSNs. A mobile data collector called M-collector is used for collecting data from single-hop communications and finally sends the gathered data to the static data sink. A novel time division multiple access (TDMA)-based medium access control (MAC) protocol⁹ was proposed to be used in a cluster-based WSN to conserve energy and increase data transmission efficiency of sensors. With this protocol, data transmission occurs only when a node contains the data, otherwise the node stays in a sleep mode. A data aggregation and authentication (DAA) protocol¹⁰ was proposed to integrate false data detection with data aggregation and confidentiality. A protocol proposed in Ozdemir and Cam¹¹ disseminates data to sensors of a network by first constructing a connected dominating set in the network. These approaches transmit data based on the point-to-point communication paradigm and cannot decouple data from the location.

IoT operates according to the “any-time, any-place, any-one connected” principle. It can handle a lot of things and generate data using the connections between virtual and physical devices in the communicating world. The diversities of IoT can be found in different technologies such as M2M, WSN, and Web technology. The potentiality of the WSN paradigm will be fully unleashed once it is connected to the Internet and become part of the IoT.^12,13

The CCN architecture^5,14–19 decouples the content from the location and works like a virtual content distributor all over the network. Ant colony–based routing^20–22 restricts the Interest Packet dissemination and content distribution, but the overhead and the complexity of the algorithm are high due to the collection of global information. Several proxy-based approaches^23,24 were proposed to provide seamless connectivity toward the content when the end users are mobile and change its location frequently. But these approaches increase the complexity in handling mobility by increasing its dependency on a central administration or proxy server. The CCN paradigm applied to WSNs will enhance data transmission efficiency using the principle of CCN forwarding strategies.^25,26 NDN-ACE²⁷ is a lightweight access control protocol for constrained environments (ACE) over Named Data Networking (NDN). A wireless NDN-IoT²⁸ network provides a novel distributed probabilistic caching strategy. A new push-based mechanism²⁹ was introduced to optimize the traffic utilization within a CCN-based network for IoT applications where information is created and consumed at different frequencies.

CCN is based on the communication with the content name instead of the source-destination communication scenario.⁵ Therefore, CCN can provide anytime, anywhere communication for accessing a certain content. In CCN, contents are accessed using the hierarchically arranged name components that are generated by the content providers. An Interest packet which includes the content name is broadcast toward all the available content provider nodes. Any node that has the original or a replicated copy of the requested content can respond to the request with the content.

However, the above prior work only used the CCN approach in specific domains like mobile ad hoc network (MANET), WSNs or wireless networks, or wired networks, which is not a full representative of the IoT architecture in heterogeneous domains.

An architecture for efficient data delivery in the wireless IoT environment

In this section, we present a possible CCN-based architecture for efficient data delivery in the wireless IoT environment.

A structure for content naming

The main principle of CCN is that a content is accessed using the content name rather than the host address, and thus, content naming is a very important issue in CCN. With the exponential growth of IoT devices, it is difficult to find and manage relevant data in a fast and efficient way. Therefore, it is important to provide a well-organized naming scheme that is flexible and provides a low delay in retrieving or identifying the content from the edge network. Our proposed architecture follows a hierarchical structure for content naming and is defined as follows:

/domain/applicationType/location/sensorType/timeStamp/dataAttribute/…

• Domain is used to check whether the packet belongs to the CCN domain, for example, /hufs.ac.kr/

• ApplicationType is the identity of the application of the sensor data to which the data are best suited and which provides authenticity, for example, /temperature management system/

• Location is used to indicate the data origin, for example, /engineeringbuilding/floor3/room-304-1/

• SensorType is used to differentiate different type of sensor data, for example, /temperature/

• TimeStamp identifies a particular subset of data relevant to a given instance or period of time, for example, /timestamp/

• DataAttribute (optional) is a dictionary to provide data presentation and data structure, for example, /<data1:int><data2:string>/

In our proposed architecture, the number of naming components is not limited. It has the full flexibility for the data provider to choose any number of name components with any definition.

The network model

In this article, we consider a sensor network consisting of N sensors randomly dispersed over a rectangular network. We make several basic assumptions as follows:

All sensor nodes are stationary and can work in an ad hoc mode and communicate with all other nodes.

Wireless links are symmetric and stable.

Nodes have the transmission capability with the long-term evolution (LTE) base station.

Each node in the proposed network architecture has three basic functional elements for content-centric communication: Content Store (CS), Forwarding Information Base (FIB), and Pending Interest Table (PIT) as in Jacobson et al.⁵ CS maintains the relation between the content name and stored content at the local cache of a CCN node. FIB contains the necessary information to forward an Interest packet to the appropriate next hop, which is similar to the routing table of the host-based network architecture. It contains all the next hop interface IDs for each reachable content. PIT is a fundamental structure to preserve the state of the received Interest packet. It records all incoming interface IDs for unsatisfied Interests so that it can satisfy the Interest later as soon as the content is available.

Components of the proposed architecture

The proposed CCN architecture is composed of Smart Base Stations (SBS), Smart Routers (SR), Smart Mobile Sensors (SMS), for example, Smart Phones, Service Management System, and Context Management System as shown in Figure 1. Service Management System and Context Management System form the IoT Decision Controller (IDC). We use the short notions later to describe the functionalities of the proposed architecture. SR, SBS, and SMS belong to transport domain and responsible for reliable data transmission from SMS to IDC. Service Management System and Context Management System belong to service domain that generates a meaningful reasoning to identify a context and execute the relevant event and works as a distributed intelligent controller. SBSs are connected to SMSs using the wired interface, and SRs are connected to the service domain using the wired interface. SBSs are equipped with a mobility handler (e.g. mobility management entity (MME) in LTE) to deal with the mobility of the mobile sensors. The main reason for distributing the intelligence among the base stations and edge sensors in our proposed architecture is to reduce the response time for data delivery even during the high-mobile environment. All the components in Figure 1 have the basic functionalities of the CCN node model.

Figure 1.

The proposed architecture.

Transport domain

The objective of this domain is to disseminate the sensor data in a fast, smart, and green way to reduce the energy consumption and network load among the sensor node and the SBS. To support the large amount of sensing devices and the huge amount of sensing information, we propose an approach to select a Super Sensor Delegator (SSD) from all the homogenous sensor nodes. SSD collects data from its members, aggregates it, and sends it to the SBS.

SSD selection. An SSD is selected and assigned by an SBS. During the selection process, the SBS broadcasts a Proposal Interest message by adding the keyword Proposal to the available sensor nodes. When the end sensor node receives the Proposal Interest, it replies back with the Proposal Data message that contains the following parameters.

Energy eligibility factor E_c. The sensor node measures its energy ratio E_r,i using equation (1)

E_{r, i} = \frac{E_{rem, i}}{E_{init, i}}

(1)

where E_rem,i is the remaining energy of the sensor node i and E_init,i is the initial energy of the sensor node i. Each of the sensor nodes calculate energy eligibility E_c to determine whether it is capable of being an SSD or not. If the remaining energy of the node is below 50% of its initial energy, then the node will not be considered as a candidate for SSD and the value of E_c becomes 0, otherwise it is selected from Table 1.

Table 1.

Calculating energy eligibility factor E_c.

Energy (E_r)	Value (E_c)
<0.5	0
0.51–0.6	0.6
0.61–0.7	0.7
0.71–0.8	0.8
0.81–0.9	0.9
0.91–1.0	1

The primary task of SSD is to provide the accurate, synchronized data to the base station from the set of edge sensors with the maximum level of simplicity. Therefore, we assume that SSD has the strong computing power, the mass storage, and enough energy. After receiving the Prepare Data message from the majority of SMSs, the SBS uses equation (2) as a utility function u_i to select the best SSD

u_{i} = \frac{E_{c, i}}{E_{c_{\max}} - E_{c_{\min}}} \times w_{1} + \dots + \frac{C_{n, i}}{C_{n_{\max}} - C_{n_{\min}}} \times w_{n}

(2)

where u_i is the utility value of node i, $E_{c_{\max}}$ is the maximum energy eligibility factor value among the participating sensor nodes, and $E_{c_{m i n}}$ is the minimum energy eligibility factor value among the participating sensor nodes. C_n,i is the other qualitative attribute of variable length, for example, computing power and storage of the sensor node i. The sum of w₁, w₂, …, w_n is 1.

SBS unicasts a Bond Interest message to the proposed sensor node. After receiving the Bond Interest message, the nominated SSD replies back with the Bond Data message to approve the bonding request. The general representation of SBS and SSD is shown in Figure 2, and the message flow for selecting SSD by SBS is shown in Figure 3.

SSD leave. Sensor nodes are dynamic and resource constrained. Each SSD can join or leave at any time. In order to prevent the failure and unavailability of an SSD, SBS keeps tracking of a sensor node that has the second highest utility value. SBS monitors the received signal strength of the SSD. If the received signal strength is below 50% of its initial level, SBS chooses the sensor node as a new SSD that has the second highest utility value. If the chosen node fails under the natural condition for being an SSD, SBS initiates a new process of SSD selection.

SSD data retrieval and ensuring liveliness. Sensor data are temporarily stored in the SSD. CCN is consumer-driven, and data can only be retrieved by an Interest message. To generalize this process, we temporarily consider the SSD as a consumer and the edge sensor as a producer. The message flows among the producer and consumer is shown in Figure 4.

Figure 2.

SBS and SSD.

Figure 3.

Message flows for SBS and SMS.

Figure 4.

Message flows among SSD and SMS.

Step 1. The work flow for consumer is shown in Figure 5. When a consumer wants to retrieve desired data, for example, temperature of a particular area, it broadcasts a Prepare Interest message to all associated producers. The Interest message is tagged with a unique proposal number. The higher proposal number means the more freshness of the data. Then, the consumer keeps collecting the reply messages named prepareYes from the producers until it receives majority of them. The replied Data message is tagged with the requested proposal number and the maximum proposal number of the provider. If the majority of providers reply with prepareNo Data message, the provider will select a higher proposal number and restart from Step 1.

Figure 5.

Work flow for consumer.

Step 2. If a majority of providers reply with prepareYes Data message, the consumer will multicast Accept Interest to those providers who reply with preparesYes and who have the data with a proposal number that meets the user-defined demand for data sampling. Then, the consumer keeps collecting the data replies from the producers. Otherwise, it will select a higher proposal number and restart from Step 1 again. If the provider receives an Accept Interest with a proposal number n, and if it did not reply with any data with the proposal number greater than n, it will accept the request and will reply with the requested Data message that satisfy the Accept Interest message. The work flow for promising as a provider is shown in Figure 6.

Figure 6.

Work flow for producer.

Query merging and in-network aggregation. The data are sensed by the sensors and are stored into its CS. Whenever an Interest message is received in the sensor network, it directs sensor nodes of the network to perform an action and they sense continuous stream of data from the applicable environment. The Interest sent to the WSN initiated from the base station generally has many identical attributes. In order to reduce the traffic between the base station and the sensor network, these identical attributes are merged and injected with a new Interest. In the event of new injection of a new query, we derive a new equation which produces a new set of Interests from all the available Interest sets. Let the base station receive i₁, i₂, …, i_n, the set of Interests at the same time, then it can simply unicast a conjunctive Interest I using equation (3) and the additional Interest using equation (4)

I = (i_{1} \cup i_{2}, \dots, \cup i_{n})

(3)

I_{n} = (i_{n} \cap I)

(4)

Fast learning FIB. The FIB prefix is learned in two ways. First, the SMS may broadcast, multicast, or unicast the data name or a prefix of a data name to the nearby neighbors. The prefix will eventually reach the core network routers. Second, each node may learn the FIB prefix by referring to the response of the pending Interest packet. Each node has a limited amount of storage capacity to handle FIB entries. In order to handle the scalability problem of FIB manipulation for a huge amount of data, we set a storage threshold. The storage threshold, for example, 0.75, means that a node can hold the 75% of its total storage for FIB manipulation. The remaining 25% are used for FIB updates. When a new FIB entry appears, the storage capacity of the node will be checked against the threshold value, and if it is below the threshold value, the entry is injected in the FIB. Otherwise, a FIB aggregation is performed, the storage capacity will be checked again, and the new FIB entry is inserted. Each node in the network has the ability to aggregate the FIB entries to its minimum level and to transfer toward the neighboring node.

Data dissemination approach

Edge-sensor-to-IDC. IDC broadcasts an Interest packet to the nearby SBSs or SRs with the desired content name. An SBS or SR receives the Interest packet, looks up its CS for the requested content. If a matching content is found, then it will be sent out via the arrival interface as a response to the Interest packet. If the matching content is not found in the CS, a lookup is performed in the PIT. If there is already an existing PIT entry for the corresponding Interest packet for the same arrival interface, the Interest packet is discarded. If there is any existing PIT entry for the corresponding Interest packet but the arrival interface is different, then a new PIT entry for the arrival interface is added to the PIT and the Interest packet is discarded. If there is no matching PIT entry, then a lookup is performed in the FIB. If there is a matching entry found in the FIB for the requested content, a new PIT entry is added to the PIT, and the Interest packet is forwarded to the interfaces available in the FIB. An Interest packet is forwarded to a single interface according to the round-robin fashion or using the random probability to reduce the response time to retrieve the content. IDC may also retrieve a large volume of data by mentioning the large duration of time stamp in the interest message. If there is no match found in the FIB, the Interest packet is discarded, which means that there is no way to satisfy the data request. Any node that receives multiple Interests at the same time may reduce the Interest latency using the Query Merging and In-Network Aggregation techniques. Data are delivered back to the IDC using the forwarding route of the Interest packet to the SSD. When a Data packet is received by the intermediary node, it looks up its CS. If a matching entry for the received data is found on its CS, then it discards the content because the content is duplicated and received previously. If there is no corresponding matching entry in the CS, it looks up its PIT to find any Interest unsatisfied for the corresponding content. If there is a match in the PIT, the content is stored in the CS and forwarded to the interfaces in the PIT. After successful forwarding, the PIT entry is removed. If there is no match found in the PIT, the content is discarded and not processed further. The message flow for the data dissemination from IDC to SSD is shown in Figure 7.

Figure 7.

Message flow for data dissemination.

IDC-to-actuator. Actuator registers or publishes a service name that is desired by itself. Then, it forwards the name to the IDC to construct the related FIB entry. When a decision for any contextual perspective is made at the IDC, then it transmits an Interest message using the previously generated FIB information. After receiving the Interest message, the actuator triggers its desired job based on the available data attribute in the Interest message. After successful operation, the actuator replies back with an Acknowledgement Data message to the IDC. The message flow for the data dissemination from IDC to Actuator is shown in Figure 7.

Service domain

The objective of the service domain shown in Figure 1 is to meet the heterogeneity of data sources and the need for seamless integration and management of devices, services, and applications. The detailed sketching of this domain is shown in Figure 8. Context management is responsible for the information flows provided by different sources, for example, sensors. The context information is collected in an ontology that represents a specific domain knowledge, whereas, finally, a service to manage all this information is used by consumers and producers. The service domain is responsible for processing the information extracted from transport domain and for making decisions according to the actuator context. Intelligent data processing techniques and complex event-oriented decision are applied here over the data provided by the transport domain. In this article, since we mainly focus on the transport domain, the details of service domain are out of scope.

Figure 8.

Generic IDC architecture.

Implementation and experiments

We implemented the proposed IoT architecture and a simple use case of IoT using NS-3 and CCNx⁵ on a Linux Ubuntu environment. The primary goals of our implementation were to show the performance characteristics of the proposed architecture with respect to CCN functionalities in the IoT environment and to show that the proposed architecture works well with the CCN functionalities in the wireless networks, for example, LTE networks combined with WSNs. A wide range of control and monitoring applications can be classified as pull-based, where the consumers, for example, decision-making controller like a heating system, can push an Interest to get the temperature in a laboratory area. Based on the retrieved data from the wireless sensor, the heating system can use an Interest to prompt a wireless end-device to perform a contextual job, for example, to switch on a laboratory device remotely. The reply data from the end-device can be used to acknowledge the execution of the job and indicate the type of the outcome of the job as success or failure. IoT devices may also originate push traffic for monitoring purposes, for example, monitoring of temperature level up-down inside an industrial or research area, and remote measurement, for example, study of weather conditions in the fields to forecast rain, drought, ice formation, snow, or wind changes. The proposed architecture delivers the data to the requesters in a fast manner.

We used the simulation topology shown in Figure 9. The different entity of the service domain integrated in a single node that is connected with an SR using 5-Mbps wired line. The SRs are connected with SBSs using via a packet data network gateway (PGW). Modern smartphones are sophisticated computing platforms with complex sensor capabilities such as detecting user location, recording high-quality audio, measuring ambient light, sensing geomagnetic strength, and sensing temperature. Due to the widespread use of smartphones, it is now possible to develop large-scale sensor networks using the cellular network technology and deploy applications on end user devices to collect and report sensor readings back to servers. So, we assume that in the simulation topology, each smart user equipment (UE) is connected with an ad hoc–based dispersed temperature sensor network. UEs work as an SSD for aggregating sensor data. We performed simulations to show the effectiveness and responsiveness of our proposed work toward real-time communications in the wireless networks. Fast and efficient data availability is the primary goal of our proposed approach, and therefore, we used data collection time, throughput at IDC, and data transmission success ratio as performance parameters. Data collection time is normally measured from the time at which a device requests for a certain data to the time at which the data are received successfully. Throughput is measured as the average number of data bytes received by the IDC per second. Data transmission success ratio is the ratio of the total number of data packets received by the IDC to the total number of data packets sent by all the SSDs. Note that the network capacity and types of traffic flows may affect the data collection time. Assigning weights for the utility function of equation (2) depends on the application’s preference. In this article, we did not consider assigning each weight for optimizing performance. For simulation purposes, we used only the energy attribute to define the utility function. The required parameters related to the simulation are specified in Table 2. Data files were published at each node as a text file. We created 60 text files per minute and published these files at each node as temperature data of the Laboratory area. In the pull-based scenario, the data were transmitted from the edge sensor to the decision controller based on the on-demand scenario. In the push-based scenario, multiple data packets were sent periodically for one Interest. For each data set of the simulation, we took the average value of the results from 10 simulation runs and showed the result with a confidence interval of 95%. In each simulation, we see the standard deviation of the observed value between 2% and 10%. Therefore, to the stable behaviors of the protocols, we represented the margin of error in all the simulation results we observed.

Figure 9.

A simulation topology.

Table 2.

Simulation parameters.

Parameters	Value
Network type	Wired, wireless
Simulation time	20 min
Number of IDC	1
Data file size	Random size 256, 512 KB
Underlying transport layer	TCP
Bandwidth in wired line	5 Mbps
Delay	2 ms
Data packet size	512 bytes

IDC: IoT decision controller; TCP: transport control protocol.

Data collection time

Figure 10 shows the data delivery time against the varying number of UEs. It shows the time between the smart UEs and the IDC. The IDC initiates Interest to retrieve data from smart UEs. Data delivery time of our proposed architecture has been evaluated and compared with the current Internet data retrieval approach (transport control protocol/Internet protocol (TCP/IP)) and the conventional CCN-based data retrieval approach.⁵ We showed the total data collection time for a 1 Mbps data generated by each SSD. However, the data collection time, that is, response time of CCN, is much shorter than the response time of TCP/IP because of the advantages of the name-based data retrieval policy. Due to the Internet’s p2p nature, each data chunk provided by each smart UE is transmitted in the different connection route and results in a huge traffic congestion. However, with our proposed architecture, less transfer time is needed for data collection because of the smart aggregation feature of the SSD. The simple CCN approach satisfies all the Interests received, and therefore, sometimes it may transmit identical data several times. The proposed reliable approach needs less transfer time because of its proper choice of data selection and Interest aggregation policy before the actual data transfer begins. Lots of replicated data will increase transmission delay, queuing delay, propagation delay, and processing delay at intermediate nodes. Also, the interesting feature is that instead of probing a sensor regularly, a better way was used to let the sensor transmit its data when needed. Our proposed mechanism reduces data collection time in a great extent, average data collection time is 40%–50% less compared to TCP/IP and 12%–22% less compared to the conventional CCN approach when the number of SSDs is between 8 and 12.

Figure 10.

Data collection time.

Throughput at IDC

Figure 11 shows the average throughput for different number of SSDs. While increasing the number of SSDs, we measured the throughput. In this simulation, we tried to figure out the scalability performance of our proposed architecture when the number of SSDs is increased. As shown in Figure 11, as the number of SSDs is increased, the performance of the proposed architecture outperforms the conventional CCN architecture in terms of throughput at IDC because of its name-based routing and contextual data retrieving mechanism. Furthermore, when the number of SSDs is between 6 and 10, our proposed protocol improves the throughput performance by 12%–16% compared to conventional CCN approach.⁵

Figure 11.

Throughput.

Data transmission success ratio

We also measured the performance of reachability and continuity of our proposed architecture in terms of data transmission success ratio, which implies that how much data were received correctly by the decision controller. The smart Interest aggregation strategy proposed in this article always tries to avoid redundant data flows. So, the unnecessary packet forwarding of the conventional CCN approach⁵ increases the data failure ratio. To show the impact of success ratio using this small number of SSDs, we added some additional constant bit rate (CBR) traffic to the SSDs and SBSs. As shown in Figure 12, the simulation result illustrated a significant improvement and offers as maximum as 10%–15% higher data transmission success ratio than the conventional CCN approach when the network load is high.

Figure 12.

Success ratio.

Concluding remarks

The management of the increasing number of connected devices and efficient data delivery between the devices is a major challenge to the current Internet architecture. In order to address this issue, we came up with the idea of integrating the content-centric paradigm with the IoT architecture. In this article, we showed that the IoT applications could benefit from several content-centric functionalities. We also proposed some extended features, demonstrated benefits of the proposed architecture and mechanisms, and illustrated how CCN would work for IoT applications in a practical world. In addition, we presented various simulation results to show that the proposed architecture works well in the wireless sensor environment.

Footnotes

Academic Editor: Mikhail Gofman

Declaration of conflicting interests

The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.

Funding

The author(s) disclosed receipt of the following financial support for the research, authorship, and/or publication of this article: This work was supported by Institute for Information & Communications Technology Promotion (IITP) grant funded by the Korea Government (MSIP) (No. B0101-16-0033, Research and Development of 5G Mobile Communications Technologies using CCN-based Multi-dimensional Scalability).

References

Kim

Suk

Efficient peer-to-peer context awareness data forwarding scheme in emergency situations. Peer-to-Peer Netw Appl 2016; 9: 477–486.

Van den Abeele

Hoebeke

Teklemariam

. Sensor function virtualization to support distributed intelligence in the internet of things. Wireless Pers Commun 2015; 81: 1415–1436.

Park

Kwon

Kang

IoT–cloud collaboration to establish a secure connection for lightweight devices. Wirel Netw. Epub ahead of print 8 January 2016. DOI: 10.1007/s11276-015-1182-y.

Kloch

Petersen

Madsen

OB.

Cloud based infrastructure, the new business possibilities and barriers. Wireless Pers Commun 2011; 58: 17–30.

Jacobson

Smetters

Thornton

. Networking named content. In: Proceedings of the 5th international conference on emerging networking experiments and technologies (CoNEXT), Rome, 1–4 December 2009.

Bosunia

Kim

Jeong

. Enhanced multimedia data delivery based on content-centric networking in wireless networks. Appl Math Inform Sci 2015; 9(2L): 579–589.

Estrin

Govindan

Heidemann

. Next century challenges: scalable coordination in sensor networks. In: Proceedings of the 5th annual ACM/IEEE international conference on mobile computing and networking (MobiCom’99), Seattle, WA, 15–20 August 1999, pp.263–270. New York: ACM.

Yang

Zhao

Tour planning for mobile data-gathering mechanisms in wireless sensor networks. IEEE T Veh Technol 2013; 62: 1472–1483.

Hsu

T-H

Yen

P-Y.

Adaptive time division multiple access-based medium access control protocol for energy conserving and data transmission in wireless sensor networks. IET Commun 2011; 5: 2662–2672.

10.

Zhu

Tao

. Target-aware, transmission power-adaptive, and collision-free data dissemination in wireless sensor networks. IEEE T Wirel Commun 2015; 14: 6911–6925.

11.

Ozdemir

Cam

Integration of false data detection with data aggregation and confidential transmission in wireless sensor networks. IEEE/ACM T Network 2010; 18: 736–749.

12.

Alcaraz

Najera

Lopez

. Wireless sensor networks and the Internet of things: do we need a complete integration? In: Proceedings of the 1st international workshop on the security of the internet of things (SecIoT’10), Tokyo, Japan, 29 November 2010.

13.

Ghayvat

Mukhopadhyay

Gui

. WSN- and IOT-based smart homes and their extension to smart buildings. Sensors 2015; 15: 10350–10379.

14.

DiBenedetto

Papadopoulos

Massey

Routing policies in named data networking. In: Proceedings of the ACM SIGCOMM workshop on information-centric networking (ICN’11), Toronto, ON, Canada, 15–19 August 2011.

15.

Zhang

Huang

Liu

. Reverse-trace routing scheme in content centric networking. J China Univ Post Telecommun 2013; 20(5): 22–29.

16.

Sun

Song

Yang

. DHR-CCN, distributed hierarchical routing for content centric network. J Internet Serv Inf Secur 2013; 3(1): 71–82.

17.

Koponen

Chawla

Chun

B-G

. A data-oriented (and beyond) network architecture. Comput Comm Rev 2007; 37(4): 181–192.

18.

Dannewitz

Kutscher

Ohlman

. Network of information (NetInf)—an information-centric networking architecture. Comput Commun 2013; 36: 721–735.

19.

Trossen

Parisis

Designing and realizing an information-centric internet. IEEE Commun Mag 2012; 50: 60–67.

20.

Okamura

Liu

. Ant colony based forwarding method for content-centric networking. In: Proceedings of the 27th international conference on advanced information networking and applications workshops, Barcelona, 25–28 March 2013, pp.306–311. New York: IEEE.

21.

Shanbhag

Schwan

Rimac

SoCCeR: services over content-centric routing. In: Proceedings of the ACM SIGCOMM workshop on information-centric networking (ICN’11), Toronto, ON, Canada, 15–19 August 2011.

22.

Eum

Nakauchi

Murata

. Potential based routing as a secondary best-effort routing for Information Centric Networking (ICN). Comput Netw 2013; 57(16): 3153–3164.

23.

Bolla

Rapuzzi

Repetto

. A user-centric mobility framework for multimedia interactive applications. In: Proceedings of the 6th international conference on symposium on wireless communication systems (ISWCS’09), Tuscany, 7–10 September 2009.

24.

Lee

Kim

Proxy-assisted content sharing using content centric networking (CCN) for resource-limited mobile consumer devices. IEEE T Consum Electr 2011; 57(2): 477–483.

25.

Campolo

Molinaro

Mitton

. Named data networking: a natural design for data collection in wireless sensor networks. In: Proceedings of the 2013 IFIP wireless days, Valencia, 13–15 November 2013.

26.

Gubbi

Buyya

Marusic

. Internet of Things (IoT): a vision, architectural elements, and future directions. Future Gener Comput Syst 2013; 29(7): 1645–1660.

27.

Shang

Liang

. NDN-ACE: access control for constrained environments over named data networking (Revision 1: 21 December 2015), https://named-data.net/publications/techreports/ndn-0036-1-ndn-ace/

28.

Ahmed Hail

Amadeo

Molinaro

. Caching in named data networking for the wireless internet of things. In: Proceedings of the international conference on recent advances in internet of things (RioT), Singapore, 7–9 April 2015.

29.

Francois

. CCN traffic optimization for IoT. In: Proceedings of the 4th international conference on the network of the future (NOF), Pohang, South Korea, 23–25 October 2013, pp.1–5. New York: IEEE.