International Journal of Computer Networks & Communications (IJCNC)

AIRCC PUBLISHING CORPORATION

IJCNC 03

Fast Packets Delivery Techniques For Urgent Packets In Emergency Applications Of Internet Of Things

Fawaz Alassery

Department of Computer Engineering, Taif University, Taif, Saudi Arabia

Abstract

Internet of Things (IoT) has been receiving a lot of interest around the world in academia, industry and telecommunication organizations.  In IoT, many constrained devices can communicate with each other which generate a huge number of transferred packets. These packets have different priorities based on the applications which are supported by IoT technology.  Emergency applications such as calling an ambulance in a car accident scenario need fast and reliable packets delivery in order to receive an immediate response from a service provider.  When a client sends his request with specific requirements, fast and reliable return contents (packets) should be fulfilled, otherwise,  the network resources may be wasted and undesirable circumstances may be counted. Content-Centric Networking (CCN) has become a promising network paradigm that satisfies the requirements of fast packets delivery for emergency applications of IoT.  In this paper, we propose fast packets delivery techniques based on CCN for IoT environment, these techniques are suitable for urgent packets in emergency applications that need fast delivery.  The simulation results show how the proposed techniques can achieve high throughput, a large number of request messages, fast response time and a  low number of lost packets in comparison with the normal CCN.

Keywords

Internet of Things, Content-Centric Networking, emergency applications, data delivery, real-time packets.

1. Introduction

The Internet of Things (IoT) consists of a large number of connected low power and cost devices which include sensors, cell phones, RF identification (RFID) tag, actuators and etc. These IoT devices have different capabilities and functions starting from sensing the surrounded environments, processing the sensed data of physical phenomena and transmitting the required data (packets) to destination nodes (receivers). The main advantage of using the IoT technology is the ability to interact human (internet users) with machines (IoT devices) which generates a huge amount of data (i.e. big data) that can be accessible from different places at different times by different people making critical challenges on how to manage millions of IoT devices which produce big data (i.e. millions of transferred packets through TCP/IP networks at the same time over various places) [1].

Cisco mentioned in one of their white papers that by 2020 there will be around 50 billion IoT devices that can be connected to each other in industries which create 14.4 trillion of dollars of values for industries around the world [2]. The IoT technology extends the connectivity of billions smart devices with the surrounding environments which cover many applications to make the world smart as shown in figure 1.

Figure 1. IoT Applications.

The Internet Protocol (IP) is widely utilized in today’s internet. Since it was introduced in the last decades, it was the protocol that focuses on how to connect network resources rather than the contents (packets) which need to be transferred over network topologies. The main paradigm for the connectivity between two hosts is host-to-host communication, which means the IP addresses for the two hosts must be recognized in order to transfer packets (i.e. routing through hosts’ IP addresses). However, when connecting millions of devices as the scenarios of IoT, routing packets through hosts IP addresses is challengeable due to the need for high level of management of limited space of IP addresses that IPv4 can deal with. Therefore, researchers introduced IPv6 in order to increase the IPv4 addresses space but the deployment cost and the large routing table entries creates very heavy load on the networks infrastructures [3].

Another challenge while dealing with millions of devices is the possibility for the breakdown of the links when these devices are communicated through point-to-point communication. The related servers and data storage may suffer from a single point of failure which wastes the network resources and increases the connectivity cost due to the need for replicated versions of the transferred or stored data. Point-point communication between millions of devices with diverse protocols, network topologies, packets priorities, and supported applications makes incompatible point-to-point communication which the IoT technology needs to deal with and introduces creative ways to communicate these large number of devices with each other [4].

Unlike traditional point-to-point communication which is based on hosts, IP addresses for routing packets, Content-Centric Networking (CCN) is a new network paradigm which is based on the contents of packets for routing rather the IP addresses of hosts. Giving a unique global name for each piece of information need to be extracted from surrounding smart devices is the main concept of CCN. When users want to fetch specific data from smart devices, they need to express their interest with the exact data name. Thus, the first class entity for the returned (retrieved) content is the data name rather than the IP addresses [5].

The main challenge of using CCN for IoT is that different regions have a different type of smart devices, application names, variable network components and various naming rules which increase difficulties on how to share and transfer contents without caring the exact names. In IoT, when a new node enters a certain area to measure a specific phenomenon, it should follow the simplest plug and play rule to retrieve the data and interact with the corresponding local network. Hence, defining a well-known naming structure (e.g. hierarchical naming structure [6][7]) for all smart devices in IoT is important for correct and fast packet delivery especially in emergency applications. In addition, due to millions of requests generated by smart devices of IoT which cause a massive amount of traffic delivered over the Internet, data can be aggregated at master nodes in order to facilitate and accelerate packets delivery which CCN can achieve. So CCN can be considered as a perfect choice for the future of IoT.

To deal with the above challenges, the main contributions of this paper are twofold:

• We distinguish the prioritize packets from the normal packets for the purpose of emergency applications in IoT by making a simple change in a packet structure of CCN. This simple change along with calling multiple packets at the same time instead of calling only one packet for one request will save the network resources and reduce the load on the network infrastructure.

• We have proposed a transport mode for the purpose of efficient content aggregation. This transport mode facilitates the fast and flexible packets delivery for emergency applications of IoT which need packets to be transferred as fast as possible.

The rest of the paper is organized as follows. Section 2 describes some related works in CCN which includes their related integration with IoT. Section 3 describes the network model and the related assumptions which we made in our works. Section 4 discusses the modification on CCN in order to prioritize the packets for emergency applications in IoT. Section 5 discusses the transport mode for the prioritized packets and explains the proposed aggregation mechanism for generated prioritized packets.. The evaluation results which show the advantages of the proposed techniques are presented in section 6. Finally, the conclusion of our works is summarized in section 7.

2. Related Works

During the last decade, many efforts have been focused on how to improve the future architecture of the Internet. All of these efforts concentrate on the data-centric architecture rather than host centric architecture. For example, Content-Centric Networking (CCN), Data -Oriented Networking Architecture (DONA), the Named Data Networking Architecture (NDNA), the Network of Information (NetInf), and the Scalable and Adaptive Internet Solutions (SAIL) [8]. The concept of Information- Centric Networking (ICN) was proposed in 2006 which is the architecture that focuses on data communication rather than who is communicating (i.e. content centric communication rather than the location of a user who has a unique IP address). After proposing ICN architecture, many efforts tried to enhance its performance. For example, DONA focused on how to improve the security of ICN architecture. The Publish- Subscribe Internet Technology (PURSUIT) tried to replace IP protocol stack with a push/subscribe protocol stack. NetInf focused on the scalability of the Internet. CCN was proposed in 2007 which focuses on the content communications, after that some efforts come to improve its performance and supported applications such as NDNA [9]. ICN architecture is shown in figure 2.

Figure 2. ICN Architecture.

The main focus in this section is CCN which is based on the name of the contents. Packets (i.e. interesting packets and data packets) will be routed based on the name of the content instead of the IP of the source node and the destination. In CCN a user makes a request for contents by sending interested packets that have the name of the contents. Data packets will be delivered in response to the request in the return path until they reach to a source node. During data packets transmission, the content will be stored in all nodes which are located in the routing path. Packets are divided into chucks that have identification numbers in order to collect these chunks and then forming the original packets at the source node which made the request for the contents. All the contents will be cached by the intermediate nodes which generate data packets that contain the requested content, these intermediate nodes are distributed in the reverse routing path. In CCN, nodes that made requests for contents and sending interested packets are called consumers, while nodes which response to the requests made by consumers and provide the required contents through sending data packets are called producers [10]. An overview of the communication between a consumer and a producer in CCN is shown in figure 3.  The figure illustrates the difference between the interest and data packets.

The main features for the communication model of CCN are explained in [9] and [10] such as forwarding, naming, caching and security. The forwarding feature in CCN is based on sending a broadcast message from a consumer, this message represents interest packet which requests a specific content from another node in the network (a producer). The intermediate nodes (i.e. routers with caching capabilities) have three data structures [11]. A Content Store (CS) which is used for the purpose of caching the received data. The Forwarding Information Base (FIB) contains information for the received interest packet in order to send them to the next hop based on the routing table. A Pending Interest Table (PIT) which is used for the purpose of registering the interest packets and waiting for the return data packets which are transferred in the reverse path. The entries of PIT include the names, the face for interest packets which are sent from the consumer, and the face for outgoing packets that are forwarded to the producer. When the intermediate node (router) receives the interest packet, it checks its CS in order to find a match between the interest packet and the data stored in CS. If there is a match, then the data will be sent back to the consumer. If not, then the router will check its PIT. If the name has already existed in PIT, it means that another consumer is already received the required data packets, and the router will add the new interest packet to its PIT. If the name isn’t founded in PIT, it means that the new interest packet will be added to the PIT and forwarded to the next intermediate node in the network. In the reverse path, when the data packet is received by a router, it checks its PIT in order to find out the entry for the corresponding interest packet for further data packet forwarding, then data will be cached and the PIT entry will be removed from the table, otherwise the data packet will be discarded. Another case for discarding the data packet is reaching the lifetime of the interest packet before the data packet arrives at the consumer [11]. Other CCN features such as naming, caching and security are discussed extensively in the literature (e.g. [8],[9], [10] and [11]).

Figure 3. CCN Communication model between consumers and producers.

If the relation between smart devices, sensors, and actuators of IoT more flexible, the IoT applications will be attracted because all users can find out the data requested easily. However, this relation is difficult because users use different network components, topologies and located in various places. In the IoT environment, the applications will collect millions of data packets that are sent from millions of producers, and it is difficult to keep tracking of the small chunks of data packets. Also, the IoT applications have difficulties on how much of data are exist in the network and where they are located. Thus, CCN has promising features for the IoT applications due to their capability to rout and cache data based on contents not the IP addresses [12].

In literature, some extensions are made in CCN in order to support the IoT applications. For example, authors in [13] proposed a new freshness mechanism which is driven by a consumer in order to minimize the freshness requirements of information in IoT applications. The Authors measured the caching delay between the time for information generation and the response to the intersect packets. The simulation results showed some improvements in the network performance when combing the freshness with the naming features of CCN in IoT environments. Authors in [14] proposed Addressable Data Networking (AND) which follows the same mechanism used in CCN for denoting data by names with some extension in forwarding packets that  are based on address data forwarding. AND maps names to addresses in order to reduce the complexity of forwarding data based on names in large-scale deployments of IoT. In [15], the authors estimated the caching time for the next node forwarding. They built a caching model which is based on named packet forwarding mechanism.  The proposed model showed an improvement in reducing the multicast communication overhead. Scheduling in industrial IoT applications based on CCN was proposed in [16]. The proposed cross-layer scheduling creates independent routing topologies as well as schedulers. The main focus of the paper is to minimize the heavy traffic of industrial IoT applications by different meachnisms such as a new data aggregation model and in network processing scenarios for the large amount of traffic. Also, the simulation results showed an improvement in the packets delivery ratio as well as a huge reduction in the network traffic by around 65%. Controlling multiple mobile routers based on the naming schema of ICN is proposed in [17]. If the distance between the mobile router and the coordination of souring node is less than a pre-defined threshold level, then the router will be connected to that node. The simulation results showed how the Router Moveable Information Centric Network (RMICN) retrieves the required data faster than any other benchmarking methods.

CCN is also involved in Wireless Sensor Networks (WSNs) researches. In [18], the authors proposed CCN-WSN protocol which is designed based on the mechanisms of CCN with some extensions in order to be suitable for limited resources networks such as WSNs. Authors made some changes in the interest packets by adding small amount of   data, and removing some fields from the data packets.  In order to improve the data collection in WSNs, authors in [19] proposed lightweight CCN (lCCN) where the sink nodes have the ability to collect packets and retrieve data from one sensor node or groups of sensors at the same time. In [20], authors proposed a packet diffusion-limited protocol based on CCN which is used for Wireless Multimedia Sensor Networks (WMSNs). This protocol minimizes the data packets flooding and accelerates the downloading of the contents because of using the shortest path routing mechanism. The throughput and the delay analysis for ad-hoc networks based on CCN is studied in [21]. Users retrieve data based on the content name rather than the source and destination addresses. The authors utilized the Euclidean distance in order to calculate the closest caching points to a requester for a faster and efficient caching mechanism. Using the content based routing instead of the physical addresses of nodes in WSNs is proposed in [22]. The Authors analyzed the mapping between the required data and the corresponding user queries in order to deliver the correct packet to the correct consumer (i.e. WSN nodes).

3. The Network Model

Our works are based on distributing various objects in a large-scale heterogeneous environment which includes sensors, actuators, and mobile devices distributed randomly. Our assumptions include the following:

  • All objects have the ability to sense the surrounding areas, perform required computations, and communicate with each other.
  • Wireless symmetrical links are assumed where data can be transmitted with equal speed and quantity in both directions.
  • All objects follow the main features of CCN. CS is used for caching purposes. The FIB contains information for the received interest packet in order to send them to the next hop based on the routing table. Registering the interest packets during their transmission is done by the PIT.
  • Many-to-one packets transmission is assumed where objects (i.e. multiple producers) can send multiple data packets to a Master Consumer (MC) (i.e. a single consumer). The Selection of the MC is discussed in section IV.
  • The objects remain stationary in their locations during their lifetime.
  • We assume LTE Base Stations (LTE-BS) with Mobility Management Entity (MME) in order to deal with the possibility of moving of the mobile devices and hence changing their locations. The LTE-BS(s) are located closer to the sensing areas.
  • Multi-hop transmission is assumed for routing packets from every object to the LTE-BS.
  • A pre-defined time threshold is assumed for receiving the data packets from producers. If the time for receiving data packets exceeds the threshold level, then the consumer will ignore the request which is sent before to collect the corresponding data packets. Hence, a new request (an interest packet) needs to be sent again.
  • Distinguishing between received data packets is accomplished using the request ID number which is attached in the header of a packet structure as will be explained in section 4.
  • The intermediate nodes (i.e. routers) has ability to distinguish between urgent and unurgent packets as well be discussed in section 4.
  • The contents producers announce their matching prefixes and the priorities of their contents based on the applications to the intermediate CCN routers. In our works we assume the highest priorities are given to the emergency applications.

A general overview of the network model is illustrated in figure 4.

Figure 4. The network model.

4. Packet Classifications for Emergency Applications in Iot

 In this section, we make some changes in the interest and data packets structure of CCN in order to support emerging applications of IoT. In CCN, different traffics have different requirements based on the applications. Our focus is on the emergency applications which need support for both high reliability of packets transmission and low end to end delay to ensure that the emergency calls arrive as fast as possible.

The proposed extension in the packet structure is based on adding 8 bits field that indicates the type of the interest packets. (i.e. Bit 0 is the normal packet, and bit 1 is the urgent packet). The following 3 bits are used to determine the lifetime which is needed to be met to avoid dropping packets when the return data packets don’t arrive on-time in response to the corresponding interest packets. The remaining 4 bits are used for the purpose of giving a unique ID number for either the interest and data packets. Figure 5 illustrates the proposed packet structure.

Figure 5. The proposed packet structure for CCN.

As shown in the network model of figure 4, the contents producers and the consumers are connected through intermediate CCN routers. All contents producers make announcements to the closer CCN routers for both the matching prefix and the priorities for their contents giving the contents of the emergency applications the highest priorities among their contents. The message flows to set up content priorities is illustrated in figure 6.

Figure 6. Message flows to announce the contents priorities.

Once the connected CCN routers receive all announcements from the producers located in their surrounding areas, they will start receiving the interest packets which enter the CCN router queues in a parallel structure (i.e. each consumer has its own queue for sending the interest packets). In the CCN router, the first bit of the packet type field will be checked. If the bit is 1, then the CCN router will recognize that the packet asking for urgent content and it is an interest packet for emergency application, but the CCN router will make sure on how urgent this interest packet due to the possibility for bit conversion from 1 to 0 or vise versa (i.e. after checking the packet type field to determine the first bit is 1, this will give the priority for the interest packet to enter the second check for the name of interest). This can be done by checking the name of the interest packet, the CCN router will check that name with the priorities which are already announced by the content producers. The CCN router will register the PIT information and send the interest packet to the content provider for the consumer which asked for the content that is recorded as high priority content. The content provider will send back the corresponding data packets following many-to-one packets transmission as will be discussed in the following section.

Figure 7 below demonstrates an example of how the consumers access the CCN router queues. In this example, we haven contents producers. The producer 1 has a normal content specified as /data/hospital/making appointment. This content is giving the priority number 2. The producer 2 has an emergency application content specified as /data/hospital/calling ambulance. This content is giving the priority number 1. The lower priority number means the content has a higher priority. In our example, both producers announce their content priorities to the CCN router. The consumer 1 asked for the content type /data/hospital/calling ambulance and the consumer 2 asked for the content type /data/hospital/making appointment. The interest packets sent from both consumers will access the CCN router queues at the edge of the router and the check is applied for both the packet type field and the name of the interest which is requested by each consumer.  The router recognized that the consumer 1 interest packets has bit=1 in the packet type field, and the consumer 1 asked for urgent contents which is provided by the content producer 2. So, the corresponding PIT information is reordered and the request (the interest packet) is sent to the producer 2 in order to send back the data packets in the reverse path in a many-to-one mechanism. The sending of interest packet follows the network routing procedures which we assumed to be a multi-hop transmission scenario. The mechanism is repeated for all packets which enter the CCN router queue.

Figure 7. An example for entering the CCN router queue.

 5. The Transport Mode of Prioritized Packets

The transport mode of the network model which is discussed in the previous section aims to reduce the computational complexity and the power consumption in order to transfer both interest and data packets effectively and as fast as possible. As shown in figure 4 for the network model, the sensing areas include many objects which sense the physical phenomena and send packets from one part of the network to another using LTE-BSs and intermediate CCN routers.

For each group of objects, it is necessary to nominate MC for the purpose of collecting the required data packets, aggregating them and then sending those packets to the closer LTE-BS which is connected to the intermediate CCN routers. The following subsections explain how to nominate the MC, how to disconnect the MC, and how to retrieve data in MC based on many-to-one mode for packets transmission.

5.1. Nominating the MC

 The LTE-BS is responsible for selecting the best MC from each group of objects. The main idea of selecting the best MC is based on nominating a consumer with higher remaining energy and lower packet loss ratio. Data is aggregated at the nominated MC to improve the network performance in terms of fast packets delivery ratio to response to the emerging applications of IoT.  Equation 1 shows how to select the MC:

The selection process for the best MC follows two stages. Stage one, the LTE-BS starts sending a broadcast message to all objects in its surrounding area. We call this message Check Interest. Once all objects receive the broadcast message, they will send back Check Data messages. Now, the LTE-BS will apply the proposed equation (1) in order to select the best MC object. That object will aggregate the packet for better performance. Stage two, after determining and selecting the nominated MC, the LTE-BS will unicast message which is called registered_Interst to the nominated MC. The nominated MC will send back the registered Data message to the LTE-BS which means that the selected MC is registered as the consumer in CCN, and the other objects are considered to be the producers.

5.2. Disconnecting the MC

 The selected MC may suffer from the limited resources of the network which leads to a fast reduction in the signal power which is received by the LTE-BS (i.e. a like failure). Therefore, when the LTE_BS select the best MC, it will also recognize the second object which satisfies equation (1) ( i.e. alternative MC). When the equivalent percentage of equation (1) falls below a threshold level (l) (i.e. );  l is assumed to be 25% and it can be tuned as a network designer requirements (it can be 30%, 40% and etc.), then the LTE_BS will select the second object which is already registered as the alternative MC. Also, when the alternative MC has a link failure, then the process for the two stages to select the MC needs to be applied again to select a new and alternative MC object.

5.3. Retrieving Data in MC Based on Many-to-One Packets transmission

 Data is retrieved only when an object send the interest packet. After selecting the best MC, it will be considered as the consumer which sends the interest packet. The other objects are considered as the providers which send the data packets in response to the interest packets (i.e. sending data packets in reverse path). We proposed two scenarios for retrieving data:

scenario one, when the selected MC consumer has an interest packet needs to be sent to a provider, the intermediate CCN router checks the type of the packet which is specified in the packet type field, if the interest packet asked for a content which is not urgent (i.e. not related to emergency application, for example. /data/hospital/making_appointment), then the router follows one-to-one mode which means that the content provider will send the related content (one packet) in response to one interest packet which is sent by a consumer. The consumer sends its interest packet in a message which we call Prepare_Requested_Normal_Intersest (or PRNI message). This message include the request number which is attached in the packet type field as explained early (i.e the last 4 bits in the packet type field). The CCN router sends PRNI message to the content provider which is connected to the router. The content provider responses by sending Ready message to the consumer. Now, the consumer unicasts a message called the Please_Send to the provider which has the content. Once the provider receives Please Send message, the data message will be delivered in chunks until the whole data packet is delivered to the consumer. The message Data_Sent is delivered to the consumer to satisfy the PRNI message.  This scenario is repeated for all interest packets.

Scenario two, when the selected MC consumer has an urgent interest packet for emergency application (e.g. sending a request /data/hospital/calling_ambulance), the CCN router found that the first bit in the packet type field is 1, and the name of the request is recognized as a high priority request after all producers accounted their contents pritto the CCN router. In this case the many-to-one packets transmission mode is activated which means that the content provider will send all related data content (packets) in response to the one request made by the consumer. It is like forming an end-to-end session between the consumer and the content producer. We believe that the emergency applications require packets to be delivered as fast as possible, and one-to-one packet transmission mode is not useful for urgent packets even if this mode ensures reliability when sending one request and waiting for the corresponding response. Thus, we CCN router will take the responsibility to determine which packet transmission mode need to be applied based on the type of the interest packet and the priority of the contents which are announced by the connected contents producers. Now, the consumer sends its interest packet in a message which we call Prepare_Requested_Urgent_Intersest (or PRUI message) and includes the request number in the packet header. The CCN router sends PRUI message to the content provider which is connected to the router. The content provider responses by sending a Ready message to the consumer. After that, the consumer unicasts a message called Please_Send_Group (or PSG message) to the producer which has the contents.  The whole group of packets will be sent after forming a session. Once the provider receives PSG message, the data message will be delivered in chunks until the whole data packets for the session are delivered to the consumer. The message Data_Sent is delivered to the consumer to satisfy the PRUI message.  This scenario is repeated for all urgent interest packets. Figure 8 illustrates the message flows for the two scenarios.

Figure 8. Message flows between a consumer and a producer.

5.4. Extensions in PIT and CS of CCN

 In normal CCN, when the interest packet needs to be forwarded to the content producers, the CCN router will filter the interest packets in order to prevent the packets which are already recorded in the PIT entry from transmitting to the content producers. This will minimize the traffic load in the network. However, in our many-to-one packets transmission mode, we enforce the CCN router to send every arrived interest packet to the content producers in order to keep the session which is formed between the consumer and the producers (i.e. sending all interest packets to the producers even if the PIT records the same entry which is repeated for some previous cycles). When the content producers send back the corresponding data packets, the CCN router will match the content prefix (not the full data name as the case in the normal CCN) with the PIT entry, if there is a match then the data packets will be forwarded to the consumer and the interest packet will be still recorded in the PIT until the whole packets are delivered to the consumer. When the lifetime for the interest packet reaches its predefined time threshold before receiving the associated data packets, the PIT entry for the interest packet will be deleted. The lifetime is specified in the packet type field which is the value for the 3 bits that are following the first bit used for identifying the type of interest packet)

For the CS, we made a simple change on how to cash the corresponding data packets to the CS in many-to-one packets transmission mode. That is instead of caching every data packets to the CS in CCN router, the packets will be forwarded directly to the corresponding consumer after forming the session between the producer and the consumer. This mechanism will accelerate packets delivery and increase the caching efficiency. The memory for the CCN router will be saved for further non-urgent data packets delivery which follows the one-to-one packets transmission mode.

6. Experimental Analysis

 In this section, we evaluate our proposed techniques and show the performance characteristics in terms of the throughput, the number of requests, the response time and the number of lost packets. The performance metrics are explained as follows:

  • The throughput is represented as the number of packets that are transmitted successfully starting from sending the interest packets from consumers until the last corresponding packets arrived successfully to consumers in the reverse path where producers send the content data packets.
  • The number of request messages is represented as the relation between the numbers of nominated MC and the number of interest messages that transmitted from consumers.
  • The response time is represented as the time consumed starting from sending the request messages until receiving the corresponding response messages, i.e. the time needed for interest packets to travel from source nodes (consumers) to destination nodes (producers), plus the time needed for the corresponding data packets to travel from the producers to the consumers in the reverse path.
  • The number of lost packets is the metric that shows how many packets are lost in the central CCN routers due to terminating the time interval or the congestion because of the packets queue in CCN routers.

In our simulation, we compare between the normal CCN which is based on one-to-one packet transmission mechanism and our proposed techniques which are based on many-to-one packets transmission mechanism and nominating some MC nodes. In the simulation which is based on NS-3 we distribute random objects (i.e. 100 sensor nodes) in the sensing area (i.e. 100m×100m) and add four LTE-BS(s) in the sensing area. The LTE-BS(s) are located in the north, the south, the east and the west of the sensing area. We also add eight CCN routers which are modified in their functionality as explained early in the center of the sensing area for the purpose of routing packets. The parameters of the simulation are selected as follows:

  • The simulation time is 30 minutes.
  • The number of objects is 100 sensors.
  • The number of LTE-BSs is 4.
  • The number of modified CCN routers is 8.
  • The Packet size is 256 bytes.
  • The chunk size is 16 bytes.
  • The bandwidth for wired networks that connects every two central CCN routers with each other is 10 Mbps. Also, the bandwidth for wired networks that connect any central CCN router with the LTE-BS is 10 Mbps.
  • The idle delay for successful reception of data packets is 10 seconds.

For the throughput, figure 9 illustrates the transmission of the successful packets. It is obvious that when increasing the number of nominated MC nodes the number of successful arrival packets is increased gradually. The throughput of the proposed techniques outperforms the normal CCN. When the number of nominated MC is between 65 and 35 the improvement in the throughput is about 26% and 14% when comparing the proposed techniques and the normal CCN.

Figure 9. Performance metric 1. The throughput

For the number of transmitted request messages, as shown in figure 10, the MC nodes play a  very important role on how to increase the number of interest messages. In emergency applications, it is required that the number of interest messages has to be increased in order to satisfy the emergency applications requirements of IoT. This figure shows that the normal CCN has a low number of interest messages due to the fact the each request message have to receive the corresponding acknowledgment from the related producers before sending the interest messages (i.e. one-to-one mechanism), but in many-to-one mechanism, many data messages can be transmitted at once in response to one interest message which increases the possibility for accelerating the number of transmission cycles and hence increasing the number of interest messages during the simulation time.

Figure 10. Performance metric 2. The number of interest messages.

For the response time, the proposed techniques give priority for urgent packets which are related to the emergency applications. This priority is recognized at the central CCN routers which support the routers to quickly send the interest messages to the related producers that have the contents. In addition, introducing check points for parallel queues at the edge of the CCN routers gives the opportunity for dealing with urgent packets. This mechanism along with increasing the number of MC nodes that are distributed in the sensing area will shorten the delay caused by sending many packets using many nodes with similar priority as the case in normal CCN. Figure 11 demonstrates the time needed for interest packets to travel from consumers to producers, plus the time needed for the reverse path.

For the number of lost packets, a comparison between the proposed techniques and the normal CCN is illustrated in figure 12. The figure shows how the normal CCN has lower packets lost due to the fact that each lost packet will be retransmitted again (i.e. reliable transmission), but this is not suitable for the emergency applications which need packets to be transmitted as fast as possible. Also, the check points in the CCN routers in the proposed techniques cause some packets lost due to the delay expected for checking the packets, so the lifetime for the packets may be terminated and hence dropping the packets at the CCN routers. However, increasing the number of CCN routers (8 routers in our simulation) will decrease the queuing delay, and these make the number of lost packets in our proposed techniques very close to the normal CCN.

Figure 11. Performance metric 3. The response time.

Figure 12. Performance metric 4. The number of lost packets.

7. Conclusion

 In this paper, we proposed fast packets delivery techniques for urgent packets in emergency applications of IoT. We proposed the many-to-one packets transmission mechanism instead of one-to-one packet transmission utilized in the normal CCN routers. We also modified the central CCN routers in order to distinguish between a packets priority. This modification is represented by adding packet type field in the packet structure of the CCN routers. Increasing the number of nominated MC nodes in the sensing field which are selected based on lower remaining energy and minimal packet loss ratio causes a significant performance of the proposed techniques to support emergency applications in terms of the throughput, the number in interest messages, the response time and the number of lost packets.

References

[1]     S. Arshad, B. Shahzaad, M. A. Azam, J. Loo, S. H. Ahmed and S. Aslam, Hierarchical and Flat-Based Hybrid         Naming Scheme in Content-Centric Networks of Things, IEEE Internet of Things Journal 5(2) (2018), 1070-1080.

[2]     H. Yue, L. Guo, R. Li, H. Asaeda and Y. Fang, DataClouds: Enabling Community-Based Data-Centric Services Over the Internet of Things, IEEE Internet of Things Journal 1(5) (2014), 472-482.

[3]     A. Durand, R. Droms, J. Woodyatt, and Y. Lee, Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion, RFC 6333 (Proposed Standard), Internet Engineering Task Force,  (2011).

[4]     O. Waltari and J. Kangasharju, Content-Centric Networking in the Internet of Things, 13th IEEE Annual Consumer Communications & Networking Conference (CCNC), 2016, pp. 73-78.

[5]     Yuning Song, Huadong Ma and Liang Liu, TCCN: Tag-assisted Content Centric Networking for Internet of Things, 16th IEEE International Symposium on A World of Wireless, Mobile and Multimedia Networks (WoWMoM), 2015, pp. 1-9

[6]     F. Ren, H. Zhou, L. Yi, Y. Qin and H. Zhang, A hierarchical mobility management scheme for content-centric networking, 11th IEEE Consumer Communications and Networking Conference (CCNC), 2014, pp. 170-175.

[7]     L. Sun, F. Song, D. Yang and Y. Qin, DHR-CCN Distributed Hirirchcal Routing  for Content Centric Network, Journal of Internet Services and Information Security (JISIS) 3 (1/2) (2013), 71-82.

[8]     G. Xylomenos et al., A Survey of Information-Centric Networking Research, IEEE Communications Surveys & Tutorials 16 (2) (2014), 1024-1049.

[9]     S. H. Ahmed, S. H. Bouk, and D. Kim, Content-Centric Networks: An Overview, Applications and Research Challenges, Springer Briefs in Electrical and Computer Engineering, Springer, Singapore, 2016.

[10]   R. Jmal and L. Chaari Fourati, Content-Centric Networking Management Based on Software Defined Networks: Survey, IEEE Transactions on Network and Service Management 14 (4) (2017), 1128-1142.

[11]   Y. Song, H. Ma and L. Liu, Content-centric internetworking for resource-constrained devices in the Internet of Things, 2013 IEEE International Conference on Communications (ICC), 2013, pp. 1742-1747.

[12]   T. Kurita, I. Sato, K. Fukuda and T. Tsuda, An extension of Information-Centric Networking for IoT applications, 2017 International Conference on Computing, Networking and Communications (ICNC), 2017, pp. 237-243.

[13]   J. Quevedo, D. Corujo and R. Aguiar, Consumer driven information freshness approach for content centric networking, 2014 IEEE Conference on Computer Communications Workshops (INFOCOM WKSHPS), 2014, pp. 482-487.

[14]   J.J.Garcia- Luna-Aceves, ADN: An Information-Centric Networking Architecture for the Internet of Things, 2017 IEEE/ACM Second International Conference on Internet-of-Things Design and Implementation (IoTDI), 2017, pp. 27-36.

[15]   Z. Zhang, H. Ma and L. Liu, Cache-Aware Named-Data Forwarding in Internet of Things, 2015 IEEE Global Communications Conference (GLOBECOM), 2015, pp. 1-6.

[16]   Y. Jin, U. Raza, A. Aijaz, M. Sooriyabandara and S. Gormus, Content Centric Cross-Layer Scheduling for Industrial IoT Applications Using 6TiSCH, IEEE Access 6 (2018), 234-244.

[17]   Y. Gao, T. Kitagawa, S. Ata, S. Eum and M. Murata, On the Use of Naming Scheme for Controlling Flying Router in Information Centric Networking, 2018 IEEE International Conference on Communications Workshops (ICC Workshops), 2018, pp. 1-6.

[18]   Z. Ren, M. A. Hail and H. Hellbrück, CCN-WSN – A lightweight, flexible Content-Centric Networking protocol for wireless sensor networks, 2013 IEEE Eighth International Conference on Intelligent Sensors, Sensor Networks and Information Processing, Melbourne, 2013, pp. 123-128.

[19]   J. P. Meijers, M. Amadeo, C. Campolo, A. Molinaro , S. Y. Paratore, G. Ruggeri, M. J. Booysen, A two-tier Content-Centric Architecture for Wireless Sensor Networks, 21st IEEE International Conference on Network Protocols (ICNP), 2013, pp. 1-2.

[20]   C. M. Park, R. A. Rehman and B. Kim, Packet Flooding Mitigation in CCN-Based Wireless Multimedia Sensor Networks for Smart Cities, IEEE Access 5 (2017), 11054-11062.

[21]   M. Mahdian and E. M. Yeh, Throughput and Delay Scaling of Content-Centric Ad Hoc and Heterogeneous Wireless Networks, in IEEE/ACM Transactions on Networking 25 (5) (2017), 3030-3043.

[22]   C. Pham and D. A. Tran, CRES: A Content-Based Routing Substrate for Large-Scale Data-Centric Sensor Networks, 2010 7th Annual IEEE Communications Society Conference on Sensor, Mesh and Ad Hoc Communications and Networks (SECON), 2010, pp.1-3.

Author

Fawaz Alassery received his M.E. in telecommunication engineering from University of Melbourne, Australia. He also received his Ph.D. degree in Electrical and Computer Engineering from Stevens Institute of Technology, Hoboken, New Jersey, USA. Nowadays, Alassery is working as assistant professor and the dean of E-learning and Information Technology at Taif University in Saudi Arabia. His research interests include energy-efficient design of Smart WSNs and the network design of Internet of Things (IoT).

Leave a Reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s

Information

This entry was posted on June 14, 2019 by .

Shortlink

https://wp.me/p6jqfO-5pG

Navigation

Blog at WordPress.com.

%d bloggers like this: