Abstract
As the number of mobile devices and IoT (internet of things) devices has explosively increased, various contents are created anytime and anywhere. To meet such trend, current internet architecture has exposed many limitations such as high control overhead due to multistaged address resolution, frequent location updates, and network congestion. Recently, information centric networking (ICN) is considered as new networking architecture to redesign current internet’s content exchange paradigm. In current ICN architecture, whenever a mobile node moves to a new domain, it needs long latency to configure and confirm the temporary name prefix. So, this paper presents an efficient name prefix configuration mechanism in mobile CCN to reduce the latency needed for the name prefix configuration during MCS’s handover. From the performance analysis, the proposed mechanism is shown to provide lower control overhead and lower resource consumption.
1. Introduction
As the volumes of various internet of things (IoT) devices and mobile devices have rapidly grown, the device movements have become the key research point. Mobile devices may link to information about IoT devices or may transmit real-time sensing data from them anytime and anywhere. It is expected that global mobile data traffic will increase 18 times from 2011 to 2016 [1]. Through such trend, mobile-connected devices lead to huge volume of data traffic and network resource consumption. However, the current internet architecture based on the host-based model cannot keep pace with such trend due to various additional operations (i.e., frequent location updates, multilevel address resolution, etc.).
To solve such limitations, many researchers have paid attention to the new networking architecture like information centric networking (ICN), at which content is accessed by a content name itself instead of IP address for the node having the content. There are typical examples for ICN: DONA [2], 4WARD [3], NetInf [4], PSIRP [5], and CCN [6]. Among these studies, this paper focuses on the content-centric networking (CCN) architecture because it is regarded as efficient networking architecture for content sharing [7].
However, there has been little consideration for the effects due to device movement. In CCN, content consumer mobility can be handled well because of CCN’s inherent receiver-driven natures, at which there are no needs for location updates. That is, after content consumer moves into another domain, it just retransmits interest packets relevant to data packets that have not been downloaded yet. Meanwhile, the content source mobility in CCN causes many problems such as frequent routing updates, repeated transmission of interest packets, and long content download time because it requires fully updating routing tables of all content routers.
To overcome these problems, some solutions have been proposed. The tunnel-based approach [8, 9] is based on MIPv6. The locator/ID-based approach [10, 11] uses the concept of location and identifier separation to support the provider mobility in the ICN. The forwarding information base (FIB) update-based approach [12, 13] is also based on the MIPv6 concept, but instead of using a tunnel to redirect interest packets to the new location of the content source, it uses the FIB updates to redirect interest packets. However, these approaches still remain inefficient in terms of handover latency and high interest packet drop rate due to long latency for the new name prefix configuration. That is, such redirection schemes need the new name prefix to consistently receive the interest packets from content consumers. However, current CCN architecture assumes interest-data exchange model for the new name configuration and confirmation process to guarantee the name uniqueness, which results in long latency (i.e., over 5 seconds). So, fast duplicate name prefix detection (fDND) mechanism is presented to reduce the latency for the new name configuration [14]. But, it also requires over second unit for the new name configuration. So, this paper proposes an efficient preallocated name configuration mechanism using a naming pool architecture to reduce long handover latency of mobile content sources. The proposed scheme does not need any additional latency to check the name uniqueness by using a stateful name pool architecture.
The rest of the paper is organized as follows. Section 2 briefly describes CCN architecture and then shows what happens while mobile content source moves into another domain. Section 3 presents the design and detailed operations of the proposed mechanism. Then we present the evaluation results and then make a conclusion.
2. Mobility Management in CCN
2.1. Basic CCN
Basically, CCN is composed of two packet types, interest and data (Figure 1). Interest packet acts as a query for content. Data packet is utilized to carry the actual content. Interest packet contains a unique identifier (content name), a set of parameters such as the order preference (selector), and a random nonce value to prevent the packet from looping and so on. Each name prefix has a hierarchical structure, and “/” character represents delimiter between different components (i.e., “/smu.ac.kr/jyl/doc/pDND.txt”).
Content name is utilized for content identifier and routing lookup.
Each CCN node basically has three functional blocks for packet forwarding: content store (CS), pending interest table (PIT), and forwarding information base (FIB). The FIB is utilized to forward interest packets toward potential content holder(s) with matching data. It is almost similar to an FIB table of existing IP routers, at which the critical difference is that the object identifier is the content name itself, not IP address. The CS has the role as the content cache. It stores data packets to be used in future by other content requesters. So, CCN can provide localized transmission near content requesters. The PIT keeps track of interests forwarded toward content source(s) so that returned data can be sent back to its requester(s). PIT entries are eliminated as soon as they have been consumed to forward a matching data packet. PIT entries for interests that never find matching data are eventually timed out and naturally eliminated.
The content retrieval and forwarding procedures are depicted in Figure 2. When an interest packet arrives at Face 0, a content store lookup is conducted based on its content name. If matched data is found in CS, the data packet is delivered. Otherwise, it searches a PIT entry to check whether it has already received another request for the same content. If a matched entry is found in the PIT, the CCN node adds into the existing entry the face on which the new interest packet arrived. When the data packet arrives at any node, it is replicated and sent out on all faces in the PIT entry for the content. If the content name in interest packet does not match either the CS or the PIT, the FIB is looked up to determine the outgoing face where the interest packet should be forwarded. Furthermore, the PIT adds one entry for the forwarded interest packet. In other words, data packet just simply follows the order of PIT entries back to the content requester.
2.2. The Relevance of CCN with Mobile IoT
In IoT world, numerous heterogeneous devices are interconnected and transfer data to each other over a network [15–18]. So, large quantities of heterogeneous data that need to be processed in real time are dynamically generated. Also, the smart devices with various sensors (i.e., accelerometer, GPS, gyroscope, magnetometer, etc.) generate lots of information keeping in motion. Therefore, additional networking and service mechanisms are required to handle the huge volume of various kinds of heterogeneous information from IoT devices. Thus, inherent characteristics of CCN like hierarchical content name prefix and cache-and-forward architecture can efficiently handle the relevant traffic and service cases in IoT environment.
However, in mobile environment, it hardly appears possible that mobile nodes know the exact name of the content data that it needs when interacting with local networks. Content name prefix in CCN environment is configured as hierarchical structure with various components and application-relevant naming. It facilitates more rapid content lookup. Content consumers do not care about where and how to obtain a piece of content data. So, to keep continuity of content delivery, new CCN naming configuration mechanism is required to handle various mobile IoT environment.
2.3. The Problems due to Content Source Movements
Although CCN architecture is efficient for content sharing, some problems may take place to support mobile content sources. That is, as content consumer does not know the content source movement, mobile CCN requires an update of the FIB entry to forward interest packet towards the current location of mobile content source. It takes much time to update the FIB entry of all content routers and causes too many dynamic routing updates. So, interest packets may not be delivered due to long latency when the route to related content source is changed.
Redirection based schemes like TBR [8, 9] are utilized to redirect interest packets and data packets between MCS’s home domain and the content router in the moved domain. However, existing redirection based schemes just consider normal interest-data sharing based name configuration and confirmation procedure, at which they do not care about the long latency required to guarantee name uniqueness. In the IoT environment where up-to-date information especially is very important, long handover latency incurs unnecessary deliveries of content request and provides bad experience to users.
3. The New Preallocated Duplicate Name Detection Mechanism
The main point of the proposed mechanism is to use a preallocated prefix from naming pool to provide fast and seamless content source mobility in CCN environments in order to reduce long handover latency.
The proposed mechanism is based on the redirection model to handle content source mobility, which redirects incoming interest packets towards MCS from the MCS’s home content router () to content router (CR) in the currently located domain. For that, it is assumed that CRs periodically broadcast their information within their service range in order to decide whether MCS sends the “name request (NR)” message to configure a new tentative name prefix. Through the preallocation of tentative name prefix from new content router (), the proposed scheme reduces the handover latency due to new name configuration and confirmation procedures. Thus, it provides MCS’s seamless handover and low network resource consumption.
The proposed preallocated duplicate name prefix detection (pDND) mechanism starts when a MCS sends a NR message to to request tentative name prefix. It is assumed that each CR creates and manages a unique naming pool. CRs randomly generate globally routable name prefixes as background process. On generating a new name prefix, CR performs DND on the name prefix within its domain area. Only after successful DND does CR reserve the name prefix into its naming pool and regard the reserved name prefix as a unique name prefix. Afterwards, CR when receiving NR message sends the “name request acknowledgement (NRA)” message toward MCS to provide the uniqueness of tentative name prefix from naming pool and the allocated tentative name prefix. Also, when receiving the NRA message, intermediate CRs manage a binding table that records the relevance between the MCS’s prefix and tentative prefix. So, MCS’s current content router () and intermediate content routers can simultaneously deliver incoming interest packets towards the MCS to both and its serving range. The proposed pDND mechanism using naming pool is composed of 3 steps. The detailed operation procedures are as follows.
Step 1 (name configuration). To perform the pDND mechanism, it is assumed that the initialization data like signal strength or physical link information or network domain name containing a collection of network nodes is provided to MCS by the wireless access point. Through the report of the received signal strength, the MCS decides whether it initiates the transmission of the NR message towards to ask for a new tentative prefix. If it is imminent to move into another network domain, the MCS asks for the new name prefix to the content router in by sending NR message. The new NR message format is shown in Figure 3. field indicates the target location name prefix to route the NR message. For the packet identifier, NR field is designed. CS prefix field is utilized to keep track of the MCS’s prefix. Finally, current tentative prefix is to indicate MCS’s current tentative name prefix to identify the binding between current tentative prefix and new tentative prefix at intermediate CRs.
The content router in the new domain () receiving NR message sends the NRA message toward MCS’s current domain to guarantee the uniqueness of tentative name prefix from naming pool and the allocated new name prefix. Also, intermediate content router () receiving the NRA message manages a binding table that records the MCS’s home prefix and two tentative prefixes (i.e., current tentative prefix and new allocated tentative prefix). Thus, all interest packets toward the MCS can be delivered to through the preallocated name prefix routing information. The message format of NRA packet is shown in Figure 4.
After a successful name configuration process, MCS continuously checks the current location from initialization data by the wireless access point. If the movement into another domain network is detected, the MCS sends a PU message indicating its new location to . That is, the PU message includes the tentative name prefix as well as MCS’s signature to validate the PU originator.
The process of the name configuration is shown in Figure 5. When the MCS detects when the movement is imminent, the MCS sends the NR message to the c.com to receive a new tentative prefix. The content router in c.com domain receiving NR message sends the NRA message toward b.com to provide the uniqueness of tentative name prefix from the naming pool and the allocated new name prefix. Also, b.com receiving the NRA message manages a binding table that records the MCS home prefix and two tentative prefixes. So, b.com can simultaneously deliver interests to both b.com and c.com. Thus, all interest packets toward the MCS can be delivered to through the preallocated name prefix routing information.
Step 2 (path redirection). The CR receiving a PU message compares its name prefix with that of the PU message. On receiving the PU message, checks the name prefix information from the received PU message and then looks up its routing table about the entry for . Each intermediate CR sends the PU message toward based on its FIB reference if its domain prefix is different from that of the PU message. Otherwise, it does not forward the PU message and then sends a PUA message to the MCS. That is, when receiving the PU message, the intermediate CRs identify the domain name prefix information from received PU message and check its routing table to decide whether the PU message is for its domain or not. Then the PIT entry is created with prefix in PU message. receiving PU message sends a PUA message indicating that the prefix update is successful. When receiving the PUA message, intermediate CRs look up the routing table again. If the relevant PIT entry exists that corresponds with the name prefix in the received PUA message, intermediate CR consumes the PIT entry and forwards the PUA message to the next hop.
Step 3 (interest redirection). After that, a content consumer requests content data generated by the MCS. The interest packets are delivered to . redirects incoming interest packets from the lookup of its routing table towards the domain where the MCS is currently located. In other words, generates new interest packet encapsulating received interest packet and then sends the encapsulated interest packet to MCS’s current location. between and moved domain sends the encapsulated interest packet according to the FIB reference. After receiving the encapsulated interest packet, the MCS decapsulates it. The MCS transmits the data packet in response to the interest packet to . Intermediate CRs decapsulate the tunnel header and then do content caching with the original name prefix of the requested content object. Therefore, the proposed scheme can keep localizing traffic delivery through CCN’s content caching.
Figure 6 shows the simplified example of the proposed pDND operation. It shows that the new name prefix allocation is done through the name configuration procedure to new content router and then contents are shared by encapsulating and decapsulating both interest and data packets at and content routers at foreign domain ( and ).
4. Performance Evaluation
To evaluate the performance of the proposed pDND, a series of simulations are conducted through discrete event simulator based on the named data networking (NDN) module in NS-3 [19, 20]. However, as the current NS-3 NDN module does not support a device mobility management functionality, a tunnel-based mobility management model is supplemented consisting of various content routers (i.e., 10 to 200 content routers), in which each content router is connected to wireless router. The initial location of content consumers is randomly selected at the considered network topology and MCS frequently changes its location. That is, when a MCS moves between and , it makes handover between content routers. As the simulation proceeds, an MCS moves according to the modified vehicle-to-vehicle (v2v) mobility model [21–23] because it makes user movement faster, smoother, and more realistic than other models. To evaluate the impact of the movements for the MCS, we check the interest retransmission packets, delivery ratio at the MCS, and content retrieval time against varying network sizes through the comparison with existing fDND mechanism.
Figure 7 shows the comparison results of the proposed pDND with the fDND in terms of the interest message overhead against varying network nodes. Interest overhead means total interest packets that include the number of original interests and retransmitted interests, which is presented to indicate the waste of network resource consumption. As the network topology size (i.e., the number of content routers) increases, the efficiency of existing fDND degrades rapidly when compared to the proposed pDND. As fDND requires uniform second unit latency for duplicate name detection whenever a movement into another domain happens, it leads to high drop rate of interest packets during MCS handover. So, it causes large number of retransmitted interest packets. Moreover, as the number of network size increases, the delivery latency of interest packets is also increased, which results in the increase of interest retransmission as well as high network resource consumption. Meanwhile, the proposed pDND scheme does not require any latency for DND operation because it conducts the new name configuration and confirmation before a handover event happens. So, the proposed mechanism leads to shorter handover latency and lower transmission of interest packets including retransmitted interest packets.
The interest packet delivery ratio is presented to indicate the efficiency of the name configuration mechanism in mobile CCN environment as shown in Figure 8. The delivery ratio of interest packet is the ratio of the number of interest packets received by MCS over the total interest packets (including original and retransmitted interest packets) sent by all content consumers. As the network size increases, the interest delivery ratio of fDND is decreased when compared to the pDND. Because the proposed pDND mechanism uses a preallocated naming pool architecture for tentative name prefix, it does not generate any additional latency for a DND operation, which leads to reduced delivery latency as well as reduced drop rate. However, fDND assumes a uniform waiting latency so it causes high drop rate of interest packets. Moreover, as the number of network nodes increases, the successful rate for interest packets in fDND becomes lower. It leads to the fact that the proposed pDND mechanism supports lower network resource consumption than fDND.
Figure 9 shows the contents retrieval time. It is shown to indicate how fast the proposed mechanism is to support the movement of the mobile contents source. It shows the average content retrieval time against various network sizes. The content retrieval time means the total time until a content consumer receives all data packets. As shown in Figure 9, the proposed pDND becomes stable irrespective of the number of network nodes because it needs low handover latency by using the preallocated name prefix. On the other hand, existing fDND scheme requires any second unit DND operation time. This leads to the high drop rate of interest packets during handover and high volume of interest retransmission. It shows that the proposed pDND mechanism can provide stable network performance for the mobile content source in CCN environment irrespective of the network sizes.
Finally, the delivery ratio is shown to indicate how efficient the proposed scheme is to support the types of mobile content sources. Figure 10 shows the average delivery ratio in mobile IoT environment against the frequency of movement of mobile content sources. Normal is defined as average pedestrian walking speed and high as average vehicle driving speed. As shown in Figure 10, existing fDND shows lower delivery ratio as the frequency of a movement is high. This is due to the fact that existing fDND mechanism requires a uniform second unit when a handover event happens. On the contrary, the proposed pDND mechanism shows little performance difference irrespective of the moving frequency. That is, the proposed scheme is influenced only on the number of the handover events because it conducts the new naming configuration in advance.
5. Conclusion
This paper shows the following points. First, it indicates the possibility as to whether mobile CCN scheme can be considered into high movement scenarios like mobile IoT environments. Second, it shows that the frequent network change of MCS’s movement causes waste of high network resource consumption and the network’s performance drop and high control overhead in CCN environments. Third, to solve such problems for supporting contents source’s movements, the proposed mechanism is based on TBR scheme and pDND mechanism. The proposed pDND mechanism utilizes the preallocated name prefix using a naming pool architecture to provide seamless MCS’s movement in mobile CCN environment. It can save resource consumption of network devices by limiting the range of routing updates only to the home domain CR. Also, it can save network resource consumption due to low interest message overhead compared to fDND mechanism. This feature is important in CCN based mobile IoT networks since various mobile content sources inherently cause dynamic topology change, high resource consumption, and low route aggregation.
Conflict of Interests
The authors declare that there is no conflict of interests regarding the publication of this paper.
Acknowledgment
This research was supported by a 2015 Research Grant from Sangmyung University.