CCIC-WSN: An Architecture for Single Channel Cluster-based Information-Centric Wireless Sensor Networks

11/24/2020 ∙ by Muhammad Atif Ur Rehman, et al. ∙ HONGIK UNIVERSITY 0

The promising vision of Information-Centric Networking (ICN) and of its realization, Named Data Networking (NDN), has attracted extensive attention in recent years in the context of the Internet of Things (IoT) and Wireless Sensor Networks (WSNs). However, a comprehensive NDN/ICN-based architectural design for WSNs, including specially tailored naming schemes and forwarding mechanisms, has yet to be explored. In this paper, we present single-Channel Cluster-based Information-Centric WSN (CCIC-WSN), an NDN/ICN-based framework to fulfill the requirements of cluster-based WSNs, such as communication between child nodes and cluster heads, association of new child nodes with cluster heads, discovery of the namespace of newly associated nodes, and child node mobility. Through an extensive simulation study, we demonstrate that CCIC-WSN achieves 71-90 than recently proposed frameworks for NDN/ICN-based WSNs under various evaluation settings.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 4

page 5

page 9

page 11

page 13

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

Wireless Sensor Networks (WSNs) consist of resource-constrained and resourceful nodes in terms of computation power, storage capacity, battery source, and communication range  [yick2008wireless]. These nodes are often deployed in highly dynamic and sometimes inaccessible areas to perform tasks such as (1) monitoring and sensing, (2) storing of acquired information reports, and (3) transmission of such reports toward a sink node, either directly or via multiple hops. As the acquired information from a sensor node must be forwarded to the sink node for further analysis, efficient forwarding plays an important role in minimizing energy consumption. Limited by communication range and battery life, the direct communication in WSN is not practical as high energy consumption during transmission results in early expiration of a sensor node [clustersurvey]. At the same time, a significant amount of energy is also consumed in multi-hop communication as the intermediate nodes retransmit the received packets on behalf of neighboring nodes.

Fig. 1: NDN communication process.

To address these limitations, a cluster-based hierarchical approach is usually employed in WSN, where the sensor nodes organize themselves into multiple groups  [cluster-2, cluster-3, salah]. A leader node, often referred to as Cluster Head (CH), is selected and is responsible for performing tasks such as 1) accepting association request from a node that wishes to join the cluster, 2) aggregating the information acquired from child nodes (sensor nodes members of a cluster), and 3) forwarding the aggregated information towards a sink node. In such an architecture, a child node has to forward the sensed information toward the CH located at a single hop and relatively in close proximity as compared to the sink node. As a result, a significant amount of energy can be preserved in a cluster-based WSN.

In both cluster-based WSN and general WSN, the end users, such as sink nodes or base stations, are interested in fetching the updated sensed information regardless of which sensor node is producing the information [nour2019survey]. In the conventional WSNs, the nodes communicate with each other via an address-based architecture that often introduces several challenges, especially in highly dynamic environments. Therefore, the recent paradigm shift in communication models from address-oriented to content-oriented has motivated researchers to look into content-centric network architectures such as Named Data Networking (NDN)  [NDN], which employs names rather than host addresses for communication purposes.

As an architecture, NDN was originally utilized for communication between devices on the Internet. However, the Maximum Transmission Unit (MTU) size and the general resource requirements of these devices are different from those in WSNs. Such characteristics result in the need to extend the existing NDN architecture for communication in WSNs. For instance, the namespace design for WSNs should consider a rather limited length of names that can fit into 127 bytes MTU [ISI]. Moreover, for cluster-based WSNs, separate naming schemes should be designed for CHs and child nodes, as these nodes may vary in terms of the available resources. Considering that WSNs follow a wireless ad hoc communication model, energy-efficient forwarding mechanisms are also required to minimize unnecessary packet transmissions.

Taking into account all these unique characteristics of cluster-based WSNs, this paper proposes extensions to the NDN architecture for WSNs. We first propose naming schemes for CHs and child nodes. We also propose a naming scheme for the association of new nodes with CHs, which is an essential process in cluster-based WSNs, and the sharing of CH information with new, not-yet-associated nodes. After the association of a new node, a CH employs a synchronization process to share the name of the newly associated node with other nodes in the network for communication purposes. Our proposed architecture, coined single Channel Cluster-based Information-Centric Wireless Sensor Networks (CCIC-WSN), supports child node mobility by having CHs maintain a data structure with the members of their clusters (i.e., the child nodes that are associated with them) and synchronize this data structure with other CHs. Finally, CCIC-WSN features energy-efficient forwarding mechanisms for intra- and inter-cluster communication.

The main contributions of our work are summarized as follows:

  • [leftmargin=*]

  • Naming schemes for WSNs: CCIC-WSN offers a set of naming schemes for: (i) the exchange of data among resource-rich CHs and resource-constrained child nodes; and (ii) the association of new nodes with CHs.

  • Lite-query structure: CCIC-WSN supports the execution of named lite queries on CHs for efficient data extraction, with the help of different constraints.

  • Named-based forwarding mechanisms for WSNs: CCIC-WSN features a set of name-based forwarding mechanisms for energy-efficient intra- and inter-cluster (over multiple wireless hops) communication, minimizing unnecessary packet transmissions.

Through our extensive simulation study, we demonstrated that CCIC-WSN significantly outperforms recently proposed NDN-based frameworks for WSNs, achieving 71–90% lower energy consumption and 74–96% lower data retrieval delays than these frameworks. To the best of our knowledge, CCIC-WSN is the first comprehensive architectural design for cluster-based WSNs in NDN.

The rest of this paper is organized as follows: Section II provides some brief background on NDN and some related work, while Section III motivates the design of CCIC-WSN. An architectural description of the CCIC-WSN design is outlined in Section IV. Section V specifies the details of various components of CCIC-WSN. Section VI presents our simulation study. Subsequently, a number of open research challenges and future directions are discussed in Section VII; Section VIII finally concludes our work.

References Objective Query Support Pull Support Push Support Mobility Clustering
[UWSN] An NDN system design for under water WSN
[HFHN] An ICN-based pull- & push-based communication framework for smart buildings
[NDWSN] An NDN system design for data collection in WSN
[PBD2] Push data broadcast control in ICN multi-hop wireless networks
[NINQ] A name integrated query framework for NDN-based IoT
[CCN-WSN] A lightweight, flexible Content-Centric Networking Protocol for WSN
[WR] An NDN based real time wireless recharging framework for WSN
[EEIF] An energy efficient Interest forwarding mechanism in WSNs
CCIC-WSN An ICN architectural design for cluster-based WSNs
TABLE I: Summary of Related Work

Ii Background & Related Work

Ii-a Named Data Networking: An overview

NDN [NDN] is a realization of the Information-Centric Networking (ICN) vision [xylomenos2013survey]. In NDN/ICN, the communication model is based on the content name. Consumer applications send requests for named content/data, called Interest packets toward producer applications that generate the requested content. In response to Interests, producers send the requested content, in the form of a Data packet, back to the requesting consumer(s). Once generated, Data packets are cryptographically signed by their producers, binding the generated content to the name of the Data packets that carry this content.

NDN is based on the following fundamental principles: (i) application-defined, hierarchical, and semantically meaningful naming: NDN carries packets that are identified through application-defined names directly at the network layer for communication purposes; (ii) name-based, stateful forwarding: NDN forwards Interests based on their names toward the requested data—forwarded Interests leave state at each NDN forwarder [nour2020collaborative], while the retrieved Data packets utilize this state to follow the same path as their corresponding Interests back to the requesting consumer(s), satisfying the state at each NDN forwarder [mastorakis2019towards, mastorakis2020icedge]; and (iii) content-centric security: each Data packet in NDN carries the signature of its producer directly at the network layer, which secures the content in transit across the network and at rest [zhang2018overview].

A detailed Interest/Data packets forwarding process in NDN is illustrated in Fig. 1 and briefly discussed below. To realize the NDN stateful forwarding plane, NDN forwarders are equipped with three data structures: (i) a Forwarding Information Base (FIB): FIB contains a number of entries, where each entry consists of a name prefix and a set of outgoing interfaces, and is used for Interest forwarding purposes; (ii) a Pending Interest Table (PIT): PIT stores recently forwarded Interests that have yet to bring content back, essentially maintaining the network state created by these Interests; and (iii) a Content Store (CS): CS caches recently retrieved Data packets to satisfy future requests for the same content.

Fig. 2: Cluster-based WSN for Battlefield Surveillance.

Ii-B Related Work: WSNs over NDN/ICN

Table I presents a summary of related work on WSNs over NDN/ICN. Bouk et al. [UWSN] utilize hierarchical naming for pull-based communications in underwater sensor networks, where the selected naming components refer to time, location, data type, and preference. Arshad et al. [HFHN] consider the scenario of smart buildings and introduce a hybrid naming scheme consisting of hierarchical and flat components, without specifically considering the deployment of cluster-based wireless nodes in smart buildings. Furthermore, Rehman et al. [CCIC] and Amadeo et al. [NDWSN] perform preliminary explorations of the design space, propose directions for the integration of WSN with NDN, without proposing complete architectural designs. Ullah et al. [PBD2][ullah2019push] consider push-based use-cases (e.g., accident reporting for vehicular networks) and introduce a naming scheme to control the propagation of data packets in the network. To mitigate potential storms of broadcast messages, the authors propose modifications of the overall NDN forwarding and packet processing logic. Furthermore, Rehman et al. propose a flexible, expressive, and secure framework that offers a query-based mechanism for content retrieval in smart building scenarios [NINQ, rehman2019network]. This framework also supports configuration and control commands among nodes in a smart building. However, the query structure is not compatible with the 127-byte MTU size of WSNs, while neither of the two solutions considered functions such as new node association that are needed in cluster-based WSNs.

To accomplish time synchronization in ICN-based WSN networks, a protocol was proposed where clock information of nodes is shared via ICN messaging [CCN-WSN]. The authors proposed a modified format of Interest and Data packets to fulfil the requirements of WSNs such as in-network processing and data aggregation. A framework for the real-time recharging of WSN nodes over NDN was also proposed [WR]. In this work, NDN-based protocols for energy monitoring and reporting were designed and an analytical result was collected. In addition, an Interest forwarding scheme for WSNs with two modes of operation (flooding and directive forwarding modes) was proposed [EEIF]. Data producers are initially discovered via the Interest flooding mode, while directive mode is subsequently used to steer future Interests toward those producers. Potential message broadcast storms in the network are mitigated with the use of scope control and packet suppression algorithms [nour2018nncp].

How does CCIC-WSN differ from prior work? The non-cluster-based information-centric WSN approaches discussed thus far primarily deal with the Interest and Data packet forwarding, providing various solutions such as scope control, packet suppression, and deferred timers to avoid broadcast storms, among others. Going beyond the forwarding strategies, the cluster-based information-centric WSNs also require: (i) novel naming schemes that ought to demonstrate good compatibility with resource-constrained and resource-rich nodes for content dissemination; (ii) tailored named and integrated computing functionalities for the CH node that can aggregate the acquired information before data transmission to a sink node; (iii) an efficient mechanism that aims to provide the association of new nodes in the network; (iv) support for child node mobility among various clusters; and (v) a specially designed forwarding process for intra- and inter-cluster communication. The previous works in the domain of information-centric WSN do not provide the necessary mechanisms to deal with these requirements of a cluster-based network. To this end, the proposed CCIC-WSN framework extends the NDN architecture in order to provide efficient communication while supporting the fundamental requirements of cluster-based systems.

Fig. 3: CCIC-WSN Node Architecture.

Iii Motivation

To motivate the design of CCIC-WSN, let us consider a battlefield surveillance and monitoring system use-case with the help of a diagram presented in Fig. 2. Such a system may require multiple nodes that perform functions such as collaborative target tracking, sensitive area monitoring, data analysis, and communication. These nodes can be deployed in the form of clusters on the battleground and the nearby suspicious areas. The battlefield surveillance system can be utilized for the monitoring of various objects such as spying robots, tanks, and the movement pattern of enemy troops. Furthermore, this system generates alerts and forwards the acquired information towards base stations in addition to nearby friendly troops to take precautionary measures and immediate response.

Such a system may consist of three layers for: (i) sensing and monitoring; (ii) data aggregation and analysis; and (iii) data fusion. The nodes in these layers may be loosely or strongly coupled with each other for efficient monitoring, target tracking, analysis, and generation of alerts. For example, nodes such as MICAz motes [micaz] in a sensing and monitoring layer measure acoustic signals produced by various targeted objects. These nodes, often termed as child nodes, are responsible for performing sensing and monitoring operations. The nodes in the second layer such as cluster-heads—capable of performing various compute and storage-intensive tasks [krol2019compute]—may periodically fetch, aggregate, and examine the recorded samples. Finally, the aggregated information is forwarded towards the base station for data fusion and further analysis.

The current deployment of WSNs, as in the use-case mentioned above, employ traditional address-based solutions which may result in efficiency and scalability issues. For example, extracting vibration data from a single sensor in the battlefield surveillance and monitoring system requires the knowledge of the address of each sensor as well as the type of data each sensor generates (address to content/data mapping). As a result, the management of all nodes in large-scale environments (e.g., enterprises) becomes a significantly complex and time-consuming task. On the other hand, CCIC-WSN runs on top of NDN eliminating the need for address configuration and tedious content-address mappings as well as supporting the fundamental requirements of cluster-based WSNs.

Iv CCIC-WSN: An Architectural Overview

In this section, we present an overview of the CCIC-WSN design and we discuss its system model along with our assumptions.

Iv-a System Design in a Nutshell

CCIC-WSN provides named services to the nodes in cluster-based WSNs by leveraging the NDN communication model and extending the NDN architecture. The overall system design and, more specifically, the CCIC-WSN node architecture for both a CH and a child node is presented in Fig. 3. Novel packet types along with the legacy Interest/Data packets as well as new modules are added to enable the cluster-based communication in WSN as briefly described below.

The incoming packets on a CH (left of Fig. 3

) are classified into two categories: (i) content request/response packets that are further divided into conventional Interest/Data packets and query-based Interest/Data packets; and (ii) management packets. The management packets and the relevant modules serve as a key enabler of cluster-based communication in the WSN and follow the rituals of the NDN communication architecture. To accomplish the requirements of managing the cluster-based communication, we designed a hierarchical naming scheme for the cluster information association process that identifies the CHs in the network for association purposes. Further, the hierarchical synchronization (

“sync” for short) naming scheme and related module are designed to share association-related information with other nodes in the WSN.

Similar to the CH, the incoming packets on a child node (right part of Fig. 3) are also classified into two categories: (i) content request/response packets; and (ii) management packets. To associate with a CH, a child node utilizes information request/response packets to fetch the information of potential CHs in the vicinity and association request/response packets to associate itself with a specific CH. Furthermore, a child node may receive a sync-information packet, containing information about new nodes and may store it in a member collection data structure, if enabled.

Iv-B System Model and Assumptions

In this work, we consider a single-channel cluster-based WSN as a graph , where is a set of nodes and is a set of links. Nodes organize themselves in the form of clusters [clustering]. Let , a Boolean variable, indicate the resource availability at node . If , the node has enough resources in terms of computational power, storage capacity, battery, and transceiver power to become a CH; otherwise, . Based on the available resources, there could be at least two types of nodes in each cluster: Cluster Head () and Child Node (). nodes often have more resources compared to nodes. nodes perform cluster management tasks such as the assignment of duty-cycles to , reception of sensed data from , aggregation operations on received data, and forwarding of aggregated data to the sink or the requesting node. In contrast, the have limited resources; therefore, they only sense the environment and forward sensed data toward a node located one hop away.

Packet Type Description
Cluster Head Interest & Data Packets These conventional Interest & Data packets are used to fetch the content from a cluster head
Child Node Interest & Data Packets These conventional Interest & Data packets are used to fetch the content from a child node
Cluster Head Information Interest Packet An unassociated node forwards this packet to find the potential CHs in its neighborhood.
Cluster Head Information Data Packet A CH forwards this response after receiving a CH information Interest packet
Cluster Head Association Interest Packet An unassociated node forwards this packet to associate itself with a CH
Cluster Head Association Data Packet A CH acknowledges the cluster head association Interest of a child node
New Node Sync Interest Packet This packet is used to share the information of newly associated child node
New Node Sync Data Packet This packet acknowledges the reception of a sync Interest packet
TABLE II: Packet Types in CCIC-WSN

In cluster-based WSN, both and can act as producers of data. At the micro level, the are deployed at specific locations and sense their surroundings. At this level, a acts as a producer of data, while a node acts as a consumer. Considering that the acts as a provider, a specific naming scheme is required that assigns a unique and compact name to the sensed data. Eq. 1 expresses the assignment of a naming scheme (type 1) for the sensed data by a .

(1)

As opposed to this, at the macro level, a node acts as a producer of data generated by several under its administration. As a is responsible for several , which may be heterogeneous in terms of sensing the environment (e.g., audio, video, or scalar sensors), the naming scheme of nodes differs from the naming scheme of . Eq. 2 expresses the assignment of a naming scheme (type 2) for the generated data by a .

(2)

Given that asymmetric cryptography may be too expensive for a WSN use-case [shi2004designing], we assume that and nodes are able to perform symmetric cryptographic algorithms. To this end, we assume that nodes can utilize algorithms such as Advanced Encryption Standard (AES) [daemen2013design] and Hashed Message Authentication Codes (HMAC) [krawczyk1997hmac] to protect the integrity and authenticate the generated Data packets. We discuss directions for secure node association and data encryption/decryption and authentication in Section VII-C. Table II shows an overview of the different types of Interest and Data packets that are used in CCIC-WSN. In the following subsections, we provide a detailed description of all of these packet types and the components of the CCIC-WSN design.

V CCIC-WSN Design Components

In this section, we present the components of the CCIC-WSN design in detail.

V-a Naming for content fetching from nodes and

CN Namespace Design: The namespace design for , as expressed in Eq. 1, is presented in Fig. 4. This namespace consists of several components: The first component refers to the ID, which is used during the new node association process and by to differentiate the data produced by different under their administration; the second component refers to the name of the and is used during intra-cluster forwarding and to limit the number of redundant packet transmissions; the third component refers to the physical location of a , which can be obtained through a Global Positioning System (GPS) module installed on this node; the fourth component refers to the type of the data sensed (produced) by the node (e.g., temperature, pressure, audio, video, etc.); and the last component refers to the time at which the sensed information was produced111

Note that, for the CCIN-WSN design, we chose the epoch time format to save extra bytes required by a general time, where the time is separated through different notations, such as “:”, “-“ and “/”.

.

Fig. 4: node namespace design.
Fig. 5: namespace design.

CH Namespace Design: A acts as a consumer when it fetches content from a (c.f., Eq. 1) and as a producer when other s or sink nodes fetch the content from it (c.f., Eq. 2 ). To this end, a should have a proper namespace that incorporates the type of content that is produced under its administration. Fig. 5 illustrates the namespace design for nodes, which includes several components: The first component refers to the name prefix, which is used to locate the in multi-hop communication scenarios; the second one specifies the distance of the to the sink node; the third one is determined based on the the responsibilities of the (type of generated data). The selects the cluster type at the time of network initialization. To accept the association requests from various types of , the selects "heterogeneous" as the cluster type. Alternatively, the selects a specific cluster type (e.g., temperature, scalar, audio, video, etc.), so that only that generate the specified type of data can be associated with this . The last component may have two types of values: It may either contain a lite-query (Section V-B) or it can specify the name of a to fetch data from that .

V-B Customized Lite-Query Structure for WSN

The lite-query component is the last part of the naming scheme and can only be processed by the node. We limit the processing of lite queries to the because it usually has enough computing, storage, and battery resources, which are required for the processing and storing of the results that a query may yield. We present examples of various lite-queries that we use in CCIC-WSN in Table III. Note that the query scope is not limited to these examples; many other combinations based on the WSN application requirements can be defined. Each component in the lite-query is separated by “_” and plays an important role in content filtering. The first component in the lite-query is a combination of two dynamic keywords, where a character “.” is used to separate these two keywords. The first keyword denotes the task name, such as vibration, temperature, pressure, while the second keyword defines the name of the field, such as date, time, NID (Node ID), or val (value).

Lite-Query Example Description
tem.val_gt_25 Select a temperature sub-collection in which values are greater than 25
tem.val_lt_25 Select a temperature sub-collection in which values are less than 25
tem.val_eq_25 Select a temperature sub-collection in which values are equal to 25
tem.val_neq_25 Select a temperature sub-collection in which values are not equal to 25
tem.val_in_25 Check whether the temperature collection has a value of 25 or not. The result will contain a Boolean value
tem.val_bet_25_and_50 Select a temperature sub-collection in which values are between 25 and 50
tem.val_gt_25_limit_10_dsc Select the top 10 (in a descending order) temperature sub-collections in which values are greater than 25
tem.val_gt_25_count Retrieve the number of temperature sub-collections in which values are greater than 25
tem.val_bet_9_and_14_avg Get the average temperature values of the current day between 9AM and 2PM
TABLE III: Interpretation of Lite-Queries in CCIC-WSN

To compress the size of the lite-query and save 5–10 bytes in the content name, we limit the size of the task name to three characters. For example, a task “temperature” can be defined through “tem,” while a task “vibration” can be defined through “vib”. Therefore, by using 3 characters from 52 alphabets (small and large caps), our structure can scale up to approximately 523 unique tasks.

Fig. 6: CH selection namespace.

The second keyword that refers to the field name can be a maximum of 4 bytes. These two keywords are combined and form a unique dynamic keyword that is employed to filter the content. For instance, “vib.time” indicates that the requested vibration data should be filtered based on the time value of this lite-query. The second component in the lite-query structure is the comparison operator. For example, the comparison operator “lte” (less than or equal to) can be employed to compare the values of <task>.<field> with a static value that follows this operator. Several other keywords such as desc, asc, count, sel, avg, min, and max can be used to filter the results.

V-C Ch Join Process

When joining a network, a new (unassociated) node selects a to become part of a network. In CCIC-WSN, a responds to cluster selection and association requests. The join process consists of two phases: i) the selection phase and ii) the association phase. As a result, the total time needed for the join process is:

(3)

where and represent the time for the selection and the association phases respectively.

V-C1 Selection Phase

In the selection phase, a new node broadcasts an Interest packet with a name as shown in Fig. 6, which consists of the following components:

CH_Info: This is a prefix used to indicate that the current Interest is a selection request. This component is used as a routing prefix to locate multiple s in the network.

Node_ID: This is the ID of the new node. From the perspective, this name component is variable and can take various values. The uses this ID to distinguish the current node from other CNs and their produced data as well.

Location: These are the physical coordinates of the new node and can be used by a to decide on whether to accept the current node as a child.

Type: This is the type of the new node based on the data it produces (e.g., temperature, pressure, video, audio , etc.). Similar to the location component, a uses this component to decide whether to accept the current node as a child.

Time: It shows that the data from a new node can be accessed for a specific time interval.

The above hierarchical naming format consists of five components. Among them, only the first component is static and is used to locate the CHs in the network; the remaining four components are variable, and their values depend on the unassociated node. On receiving such an Interest, a may or may not respond depending on its current workload. If there is no excessive workload on the , the will respond with a Data packet that carries related information, such as the distance from a sink node, the number of CNs that are already associated with the , the traffic load on the , and the unique name of the itself for name discovery.

V-C2 Ch Association Phase

When a new node receives a selection response from one or more s, it decides which to associate with. The selection decision may be based on various parameters and is out of the scope of our work. After deciding which to select, a forwards a association Interest that carries a name as shown in Fig. 7. This name has the following components:

Fig. 7: association namespace.

CH_Association: It indicates that the current Interest packet is an association request from an unassociated node.

CH Unique Name: It indicates that the current Interest packet is only destined for the CH whose name is mentioned in this field.

The remaining components in the name are the same as presented in Fig. 6. Once a CH receives an association Interest, it uses the name components of this Interest to create Interests that will fetch data from this in the future. It further stores the information of the in its members collection as shown in Fig. 8. After storing this information, the CH performs two operations: i) responds with a Data packet to the and ii) starts a sync process in the network (further explained in Section V-D). The CH association Data packet acts as an acknowledgment to the that the CH has accepted its association request. Upon receiving this Data packet, the completes its own name by adding the CH unique name as the second component (Fig. 4).

Fig. 8: An example of a members collection

V-D New Synchronization Process

When a new concludes the association process with a , the shares the new node information (such as its naming scheme) with its and other s. Other s may further share this information with their own . The rationale of sharing this information is to make other nodes and aware of the name of the new node, so that they can employ this name to fetch content in the future. Note that the synchronization process might be an expensive process — its cost grows with the number of nodes that participate in this process. Accordingly, the scope of the synchronization process depends on the WSN application scenario and should be used according to the application requirements. The total number of nodes receiving a sync message from an that shares the information of a new node that joined its cluster is:

(4)

where is the number of child nodes of that initiated the sync process and is the number of CH nodes that are in the communication range of , thus receiving ’s sync message. is the number of s that a has, which received ’s sync message and if a shares the new node information with its own ( otherwise).

Fig. 9 shows the synchronization naming scheme that is used to share the new node information with other nodes in the network. The first name component (Node_Sync_Message) indicates that this is a synchronization packet. The remaining name components are the same as defined in the previous subsections and demonstrate the information of a new node. As soon the node is associated with the , the generates a synchronization Interest under the naming scheme of Fig. 9. On receiving a synchronization Interest, the and nodes (if enabled) store the new node information in their members-collection data structures.

Fig. 9: Synchronization naming scheme

V-E Cn Mobility

CCIC-WSN enables seamless mobility of CNs. When a CN moves from one CH to another CH, it re-initiates the join process. During the association process with a new CH, the previous CH of this CN may receive the Interest with the information of the new CH. As a result, the old CH will deduce that this CN is no longer part of its cluster. It will also remove the name of this child from its members-collection data structure.

If a CN has moved out of the communication range of its old CH, the information or association packets with a new CH will not be received by the old CH. In this case, when the association process is completed, the new CH will share the information with the old CH via the synchronization process. As a result, the old CH will deduce that the CN has moved out of the communication range of the old cluster and now produces data as a part of a new cluster.

After initializing the association process with a new CH, the child node’s old CH will be notified that the CN has moved after a time interval = + , where is the time needed for the CN to join the new CH (defined in Eq. 3) and is the time needed for the CN information to be propagated from the new CH to the old CH through the synchronization process.

V-F CCIC-WSN: Forwarding Scenarios

In cluster-based WSNs, the communication can be either intra- or inter-cluster. The intra-cluster communication can be further divided into three subcategories: (i) initiated, pull-based communication; (ii) initiated, pull-based communication; and (iii) initiated, push-based communication. Similarly, the inter-cluster communication can also be further divided into three subcategories: (i) node to another cluster forwarding, (ii) to another cluster forwarding, and (iii) to forwarding. In the rest of this subsection, we describe the forwarding of Interest and Data packets in these intra- and inter-cluster communication cases.

Fig. 10: CCIC-WSN Forwarding Scenarios

V-F1 Intra-cluster forwarding: Ch to Cn

In this case, acts as a consumer and can issue an Interest packet that carries the name for content to be retrieved from a one hop away. As all are one hop away from their corresponding , only the that produced the data responds, while other nodes in the cluster ignore the Interest packet.

The use-case scenario (a) in Fig. 10 illustrates a communication scenario of Intra-cluster forwarding from a to a . The CH generates an Interest with a name “R1/CH-R/39.273-11.130647/temperature/”, where “R1” is the prefix of the that has produced the data, “CH-R” is the name prefix of the , “39.273-11.130647” refers to the location of the , and “temperature” shows the type of the requested data. When CN-R1 receives the Interest, it returns its temperature values to the CH-R. For example, "R1/CH-R/39.273-11.130647/temperature/
1578391803 |5
” indicates that a temperature value “5” is sent to CH-R by CN-R1, which is located at 39.273-11.130647 and sensed the value at time 1578391803.

V-F2 Intra-cluster forwarding: Cn to Ch

In this case, a acts as a consumer and a acts as a producer. When a receives an Interest packet, it replies with a Data packet, while all other nodes within the ’s communication range remain silent. The use-case scenario (b) in Fig. 10 shows a communication scenario of intra-cluster forwarding from a to a . A CN-Q1 generates an Interest packet with the name “CH-Q/1/heterogeneous/Q2/CH-Q/25.592-12.120458/Vibration/1568391803“, where “CH-Q“ refers to the name of the CH, “1“ shows that CH-Q is one hop away from the sink node, “Q2“ refers to the name of the , “25.592-12.120458“ is the location of CN-Q2, “vibration“ is the type of the requested data, and “1568391803“ is the epoch time when the requested data was produced222We assume that nodes have synchronized clocks. This can be achieved, for example, through a GPS system or a network-based solution [mtibaa2020ndntp]. If the epoch time in an Interest does not match the epoch time of the actual data production (e.g., due to clock drifting), the CH sends back the data that has been generated as close to the requested epoch time as possible.. When CH-Q receives the Interest, it either retrieves the content from CN-Q2 by following the CH-to-CN (Section  V-F1) forwarding mechanism or returns the stored value, if available.

V-F3 Intra-cluster forwarding (push scenario): Cn to Ch

This mechanism is designed for a push-based communication scenario, where a child node may send a Data packet directly to a CH. In emergency scenarios (e.g., detection of an individual with an infectious diseases, car accidents), data can be attached to Interests. These Interests will be broadcast from a child node to a CH. The CH will respond with a Data packet to acknowledge the reception of this Interest, while other child nodes that receive this Interest will ignore it. The names of the exchanged packets follow the naming scheme presented in Section V-F2.

V-F4 Inter-cluster forwarding: multi-hop communication (Cn to Cn)

This mechanism is used for inter-cluster communication scenarios, where a may fetch the content from another that is a member of another cluster. In such cases, only the CHs of the consumer and producer child nodes will participate in the communication and act as forwarders. We explain the Interest and Data exchange mechanism in a stepwise manner through an example presented as use-case scenario (c) in Fig. 10 as follows:

Step 1: A CN-P2, which is a member of CH-P, is interested in the content of CN-O3, which is a member of CH-O. Therefore, the CN-P2 sends an Interest to request the content produced by CN-O3 of CH-O. In this case, the CN-P2 is the consumer, CH-P and CH-O are forwarders, while the CN-O3 is the producer333Note that for communication with child nodes in another cluster, we assume that the required information has been shared during the synchronization process (Section V-D). .

Step 2: When the CH-P receives the Interest from CN-P2, it broadcasts this Interest within its communication range. All other child nodes associated with CH-P discard the Interest.

Step 3: When the CH-O receives the Interest from CH-P, it broadcasts this Interest within its communication range. All the nodes will discard the Interest except for CN-O3 that is the producer of the requested data.

Step 4: CN-O3 receives the Interest from CH-O and either checks whether the content has already been generated or senses the environment in real-time (if a timestamp in the future is specified in the Interest). It then responds with a Data packet containing the requested content.

Step 5: CH-O receives the Data packet from CN-O3. It may cache the data in its CS and then forward it to CH-P. Due to their resource-rich nature, CHs may cache received Data packets in their CS.

Step 6: CH-P receives the Data packet from CH-O and forwards it to child node P2 after potentially caching it in its CS.

V-F5 Inter-cluster forwarding: multi-hop communication (Cn to Ch)

This mechanism is used by a child node of a cluster in order to retrieve some content from the CH of another cluster. In the above example of Fig. 10 use-case scenario (c), the CN-P2 sent an Interest to retrieve some content from CH-O. The request follows similar steps as mentioned in Section V-F4 with the difference that, in current use-case scenario, CH-O will not forward the Interest to one of its child nodes, but it will rather directly respond the Interest packet if the requested content is available in its CS. To avoid unnecessary packet transmissions in the network, only CN-P2, CH-P itself, and CH-O participate in the communication process.

V-F6 Inter-cluster forwarding: multi-hop communication (Ch to Ch)

In this scenario, a CH communicates with another CH to retrieve some content or request data based on lite queries. For instance, data aggregation operations may be needed by a CH. In such cases, the CH sends Interest packets to another CH to receive aggregated data. The use-case scenario (d) in Fig. 10 illustrates a scenario, where CH-S sends an Interest with a lite-query in its name to retrieve a number of temperature values recorded after a certain point in time. In our example, the epoch time “1578391803” indicates the time of January 7, 2020, 10:10:03 AM. As a result, this Interest will retrieve the temperature values from CH-M that have been generated after this point in time.

Vi Evaluation

In this section, our goal is to evaluate the tradeoffs of the CCIC-WSN design through an extensive simulation study and compare its performance with state-of-the-art schemes for WSNs; Energy-Efficient Interest Forwarding (EEIF) [EEIF] and Hierarchical and Flat-based Hybrid Naming scheme (HFHN) [HFHN], both of which have been discussed in Section II-B. As our baseline, we also compare CCIC-WSN to the vanilla NDN architecture without introducing any modifications for WSNs. We first present our simulation setup and we then present our simulation results.

Vi-a Simulation Setup

In our simulations, we consider multiple nodes that are deployed in the form of clusters in an area of 300 m 200 m with a total of 100 nodes (Fig. 11). Each cluster consists of one node and multiple . For our simulations, we implemented CCIC-WSN in ndnSIM [ndnSIM], the NDN simulator, on a computer equipped with a Core i7 CPU and 8GB of RAM running Linux Ubuntu. The transmission range of is limited to one hop (i.e., to the they are associated with), while the transmission range of s is higher and covers the entire cluster. The is deliberately located at the center of a cluster and is reachable by its . In our simulation topology (Fig. 11), the green nodes at the bottom of a cluster are randomly chosen as the consumer nodes that request content at different rates. The black nodes are chosen as the CH, while the remaining nodes are producers. A summary of our simulation parameters is presented in Table IV.

Fig. 11: Simulation Topology

In our simulation study, we considered the following evaluation metrics:

  • [leftmargin=*]

  • Energy consumption: The total energy (() in J) consumed by all the nodes () for the transmission of Interest and Data packets.

  • Interest satisfaction rate: The ratio of the total number of Data packets () successfully retrieved to the total number of Interest packets () generated in the network.

  • Query satisfaction rate: The ratio of the total query-based Interests satisfied () to the total number of query-based Interests generated .

  • Interest satisfaction delay: The sum of the time required for an Interest to reach the producer , (), for the producer to process () this Interest (), and for the corresponding Data packet to reach the consumer , ().

  • Query satisfaction delay: The sum of the time required for an Interest carrying a lite-query to reach the producer , (), for the producer to process () this lite-query Interest (), and for the corresponding Data packet to reach the consumer ,  ().

  • Node association time: The time required for the association () of a CN node with a CH.

  • New node sync time: The time required () for a CH to share the information of a newly associated child node with its other child nodes and other CHs (), and these CHs to share this information with their own child nodes () through the synchronization process.

Vi-B Evaluation Results

Vi-B1 Energy Consumption

Energy consumption is directly proportional to the number of Interest and Data packets transmitted in the network. Fig. 12 and Fig. 13 demonstrate a comparative analysis of Interest and Data packets energy consumption among vanilla NDN, HFHN, EEIF, and CCIC-WSN. For this experiment, we vary the number of the Interest generation frequency from 2 Interest/sec to 20 Interest/sec and calculate the total amount of energy consumed by both Interest and Data packet transmissions.

Parameter Value
Simulator NS-3 (ndnSIM 2.5)
Communication Stack NDN
Wireless Interface IEEE 802.15.4
Topology size 300200
Total Number of Nodes 100
Total Number of Clusters 4
Mobility Model Constant Mobility with fixed location
Propagation Delay Model ConstantSpeedPropagationDelayModel
Energy consumption per bit 0.5 J/bit
PIT Timer 4 sec
Interest Packet Size 48 bytes
Data Packet Size 96 bytes
Simulation Time 1800s
TABLE IV: Simulation Parameters

Analyzing Fig. 12 and Fig. 13 for vanilla NDN, our results indicate that for low rates of Interest generation, the energy consumption of Interest packets is lower compared to the energy consumption of Data packets at identical frequency rate, since the size of an Interest packet is almost half the size of a Data packet. As the Interest generation frequency increases, the Interest packet energy consumption also increases and surpasses the Data packet energy consumption. This is due to the ad hoc nature of communication among the nodes, where each node that receives an Interest, forwards the Interest to neighboring nodes in the absence of the requested data. This creates a broadcast storm in the cluster and collisions occur due to simultaneous transmissions. Considering such collisions occur frequently, they increase the Interest retransmissions and, subsequently, the Interest energy consumption exceeds the Data packet energy consumption.

Fig. 12: Interest energy consumption as a function of Interest frequency
Fig. 13: Data energy consumption as a function of Interest frequency

Similar to vanilla NDN, HFHN demonstrates an analogous trend in results for Interest and Data packets energy consumption. The reason for this behavior is that in a single cluster all the nodes act as forwarders; rather than discarding the received Interests, they forward them instead, creating an Interest storm in the cluster. Contrarily, the results for EEIF show that it controls Interest flooding through scope control and packet suppression. At the same time, EEIF forwards Interests in dual mode (controlled flooding or directive mode). Thus, EEIF selects a limited number of forwarding nodes for the transmission of Interest and Data packets. However, our results indicate that 8 to 12 nodes out of the 25 nodes of a cluster still participate in the communication.

Fig. 14: Interest satisfaction rate as a function of the Interest generation frequency
Fig. 15: Query satisfaction rate as a function of the number of unique content objects
Fig. 16: Interest satisfaction delay as a function of Interest frequency
Fig. 17: Query satisfaction delay as a function of number of unique content

In comparison, our findings show that the use of CCIC-WSN results in 71–90% lower total consumed energy compared to vanilla NDN, HFHN, and EEIF. For intra-cluster communication, nodes in CCIC-WSN communicate directly with producer nodes or CHs without the need for any intermediate forwarders. As a result, CCIC-WSN can effectively control the transmissions of Interest and Data packets, avoiding storms of broadcast packets, and minimize collisions in the network, subsequently minimizing the overall consumed energy across the network.

Vi-B2 Interest and Query Satisfaction Rates

Fig. 15 and Fig. 15 show results on the Interest Satisfaction Rate (ISR) and the Query Satisfaction Rate (QSR), respectively. For ISR, we vary the Interest generation frequency between 10 Interest/sec and 50 Interest/sec, while, for QSR, we vary the number of unique content objects between 10 and 50 objects. For QSR, we assumed that producers have pre-recorded data samples, and all of them are uniquely identified by a time value in their names.

The results presented in Fig. 15 demonstrate that CCIC-WSN performs better than the other three schemes. The reason is that CCIC-WSN directly fetches the content from the producer for intra-cluster communication and in the worst case scenario, it involves two forwarder nodes for inter-cluster communication. In contrast, the remaining three schemes may involve multiple intermediate forwarders in the communication, causing congestion and collisions in the network and thus decreasing ISR.

Fig. 18: Node association time as a function of the number of nodes in the cluster and the number of CHs within the communication range of the new node
Fig. 19: Synchronization time as a function of the total number of nodes

The results in Fig. 15 show that CCIC-WSN attains a considerably higher QSR compared to EEIF, HFHN, and vanilla NDN. A single lite-query-based Interest packet in CCIC-WSN can fetch multiple content objects (on average 4 to 5) in a single Data packet by specifying the exact logic in its lite-query component. Thus, CCIC-WSN can decrease the number of required Interests for the retrieval of the same amount of content up to 4 times on average as compared to EEIF, HFHN, and vanilla NDN.

Vi-B3 Interest and Query Satisfaction Delays

For the Interest Satisfaction Delay (ISD), we vary the Interest generation frequency between 5 Interest/sec and 25 Interest/sec, as shown in Fig. 17, while for the Query Satisfaction Delay (QSD), the number of unique content objects varies between 5 and 25 objects, as shown in Fig. 17. Our results show that ISD for CCIC-WSN is significantly lower than the other three schemes. Furthermore, CCIC-WSN significantly reduces QSD compared to the other three schemes; a single lite-query-based Interest fetches several content objects as a single Data packet, reducing the delay needed to fetch the same amount of data compared to sending multiple and separate Interests for each content object. Overall, our results demonstrate that CCIC-WSN achieves 74-96% lower ISD and QSD than EEIF, HFHN, and vanillain NDN.

Vi-B4 Node Association Time

In these experiments, we assume that new nodes join the network during the simulation execution. In such cases, existing CHs and already associated child nodes exchange Interest and Data packets with each other. We present results in Fig. 19 on the association time as a function of the number of nodes already in a cluster (5 to 25 nodes) and the number of CHs that are within the communication range of the new node (1 to 3 CHs). The results demonstrate that the maximum association time for a node is approximately 194ms. Moreover, the results show that the association time does not alter considerably as we increase the number of CHs within the communication range of the new node, because only CHs that have available resources to accommodate the new node will reply to the node’s join request. As a result, the new node will be able to seamlessly and quickly associate itself with a CH that has available resources.

Vi-B5 New Node Sync Time

In these experiments, we assume that the synchronization process happens once a new node associates with a CH. We measured the synchronization time by varying the total number of nodes in the network from 20 to 200, as shown in Fig 19. The results show that the synchronization time increases with the number of nodes in the network. The maximum recorded time is 87 ms when the total number nodes in the network is 200.

Vii Future Directions and Open Research Challenges

The CCIC-WSN architecture fulfills the fundamental and necessary requirements of cluster-based WSN. However, this is only the first step toward a concrete NDN-based architecture for cluster-based WSNs with several important areas yet to be explored.

Vii-a TDMA-based Slot Assignments

To avoid interference and collisions, the child nodes in a single-channel cluster-based WSN forward sensed data in unique time slots. The CH splits the channel into equal time slots and distributes these time slots to the child nodes. The CH also communicates synchronization information to child nodes throughout the cluster. The CH can share such synchronization information in a control time slot which should be at the start of the time window. We may call these time slots as member-slots. In addition to the member-slots, a CH slot is also needed, which can be further divided into sub-slots for the association of new nodes with the CH and the synchronization with other CHs. To support such TDMA-based operations, further research is needed to explore energy-efficient slot assignment mechanisms and naming schemes under which the slot information will be shared.

Vii-B Cluster Head Reshuffling

The CH consumes more energy compared to the CN, as most of the time the CH node performs compute-intensive tasks and forwards the Data packets over long distances [energysurvey, energyfuzzy]. Consequently, after a few rounds, the elected CH may not be able to perform its duties and perish due to high energy consumption. To avoid communication losses in such failure scenarios, the expiring CH should handover its responsibilities to the nearby resourceful node. The CH handover process, often referred to as cluster-head reshuffling, may have an adverse effect on the performance of a cluster-based WSN, and if not carefully handled, it may result in high energy consumption and communication delays. To enable efficient CH reshuffling with the aim of minimizing the energy consumption, separate naming schemes are required for: 1) multi-casting of the expiration message among neighboring child nodes, 2) broadcasting of new CH name in the network, and 3) exchange of information between the old and the new CH. In addition, the proposed handover algorithm ought to demonstrate the minimum complexity and time requirement, and thus does not affect the overall communication requirements of cluster-based WSN.

Vii-C Secure Association, Data Authentication, and Encryption

Given that asymmetric cryptography may not be feasible for WSNs and IoT, since it may be too expensive for such applications [shi2004designing], solutions based on symmetric cryptography need to be explored. For example, child nodes can authenticate the CH during the association process (and vice versa) based on pre-shared symmetric keys and a trusted resourceful node that acts as an authentication manager [mick2017laser, bersani2007eap]. Symmetric keys for Data packet authentication and encryption/decryption may be generated once a child node becomes securely associated with a CH. The used symmetric keys will need to be refreshed/rotated over time to minimize the potential exposure in cases where there is leakage of a symmetric key [li2019secure]. Further research is needed along the direction of secure sensor and IoT on boarding, data encryption/decryption and authentication, and to investigate the tradeoffs of the key rotation period.

Vii-D Query Execution Plans

To improve query execution, modern databases such as MongoDB, MySQL, and SQL use execution plans that employ a query optimizer [kabra1998efficient, scherb2019execution]. In the proposed CCIC-WSN lite-query structure, a lite-query execution plan could be a set of sequences that a CH node performs to execute the lite-query. The need to devise a proper query plan for CCIC-WSN ascends, because consumers in CCIC-WSN formulate their lite-queries through filtering logic, but they do not share the exact order for the query execution. Therefore, a proper query planner module for CCIC-WSN should be developed. The responsibility of this type of module will be to fetch the best execution plan to efficiently filter the child nodes’ content.

Vii-E Denial-of-Service Attack during New Node Association

During the association process, a new node may receive the information of malicious CHs within its communication range. Malicious CHs may ignore the association requests of child nodes, essentially launching a Denial-of-Service (DoS) attack against these nodes. As a result, child nodes may not be able to associate with a legitimate CH in order to communicate with other nodes in the network.

Vii-F CCIC-WSN Cache Replacement Strategies

Since Data packets in CCIC-WSN may contain content that is filtered by the logic defined in lite-query components, the lite-query should be stored in the CS of a CH along with the content. If the same lite-query arrives in the future, the result can be provided from the CS rather than from the original CH. In addition to that, further research is needed on cache replacement policies to investigate the impact and tradeoffs of such policies in WSNs [ullah2020icn].

Viii Conclusion

In this paper, we proposed CCIC-WSN, an NDN-based design for single-channel cluster-based WSNs. We first presented the motivation for our work and then we discussed related work in ICN-based WSNs. We then presented the CCIC-WSN design components and evaluated CCIC-WSN through an extensive simulation study, where we compared its design to state-of-the-art solutions in ICN-based WSNs and a baseline vanilla NDN communication scheme. Finally, we presented a number of research directions and open issues that we plan to investigate as part of our future research work.

References