Device Mobility Management in Content-Centric Networking

I

NTRODUCTION

Various embedded features, like messaging, browsing, cameras, and media players, and wire-less capability have transformed mobile devices into multimedia computers [1]. Through such high-end mobile devices, users are now capable of creating their own content easily and fast, and are likely to share their content with other peo-ple, as an extension of the human need for com-munication and experience sharing. That is, content dissemination to mobile devices has recently attracted much attention. Accordingly, mobile devices play roles as content consumers as well as content sources. Moreover, content consumers do not care where and how to obtain a piece of content [2]. Instead, they make much of how fast and reliably the requested content can be accessed.

However, to meet such demand and trends, the current Internet inherently requires addi-tional operations and control overheads such as multistage address resolution, add-on security mechanisms, frequent location update, conges-tion control, and so on. Hence, an efficient net-working model has been considered: information-centric networking where content queries and data are routed based on content name itself instead of destination address. Typi-cal examples are DONA [3], PSIRP [4], 4WARD [5], and CCN [6]. Among these proposals, this article focuses on the content-centric networking (CCN) scheme because it is regarded as a glob-al-scale new networking paradigm.

From basic characteristics such as receiver-driven communication, named data, and in-net-work caching, content-centric netin-net-working (CCN) is expected to realize the key goals in today’s Internet. However, there has been little consid-eration for the effects due to device movement in CCN environments. CCN also needs to have mapping information between the name-based topology and the physical network topology because content data needs to be located on the original physical source or cache. Moreover, as the processing power of mobile devices has increased, some implementations of personal servers for mobile devices and an increasing need for mobile devices to access information on other mobile devices have emerged [7]. Howev-er, such growth of mobile devices having service hosting platforms leads to the complicated situa-tion in CCN.

Content consumer mobility may be handled well due to CCN’s receiver-driven nature. After handover, a mobile consumer just resends inter-est packets that have not been satisfied yet. This can occur seamlessly because there is no need for any location update. However, it may incur some overhead such as resource consumption, long service latency, discovery of local cached data, and so on. Especially, the case where a mobile content source roams is more challeng-ing. That is, content source mobility brings about big problems such as frequent routing update and long service disruption because it needs to update routing tables of all relevant content routers. Moreover, many mobile con-tent sources would pollute the routing tables with specific prefixes, tarnishing the advantages of prefix aggregation using hierarchical name structure.

Thus, this article presents the solution to con-tent source mobility in CCN environments that can provide both low network convergence time and low service disruption. The proposed approach has similarities with Mobile IPv6 [11] in terms of the name binding architecture of the routing table. However, by virtue of content caching in content routers, the proposed approach can provide seamless reachability and network overhead reduction for the mobile con-tent sources in CCN environments.

A

BSTRACT

Due to rapid developments in mobile tech-nologies as well as various embedded multimedia features, user created mobile contents are on the increase, in terms of both quality and quantity, and at the same time are shared in real time. To keep pace with such trends, a new networking technology called content-centric networking has appeared. However, it does not consider the extra requirements to support device movements. Thus, this article proposes a mobility manage-ment scheme for CCN to provide faster service access latency and lower routing overhead.

INFORMATION-CENTRIC

NETWORKING

Jihoon Lee, Sangmyung University

Sungrae Cho, Chung-Ang University

DaeYoub Kim, The University of Suwon

Device Mobility Management in

Content-Centric Networking

M

OBILITY

M

ANAGEMENT IN

C

ONTENT

-C

ENTRIC

N

ETWORKING

CCN B

ASICS

The CCN protocol is based on two packet types, namely interest and data packets [6]. Interest packets are similar to “content query” in a pub-lish/subscribe system, which carries a name that identifies the desired data. Data packets are analogous to “content response,” which is uti-lized to carry the actual content. Meanwhile, CCN does not need any name resolution servers to resolve the name of content data with its loca-tion or the publisher of the content data, which is instead done by content name-based routing.

Routing table configuration is done by the announcement of name prefix [6]. That is, con-tent publishers announce their name prefix via CCN broadcast. A content router hears such an announcement, installs a CCN routing forward-ing information base (FIB) entry for the name prefix pointing at the face where it heard the announcement, and then delivers to all content routers the prefix by the routing protocol.

One content is fragmented to multiple seg-ments and each piece of content is addressable. Each CCN node basically has three functional blocks for content delivery: content store (CS), pending interest table (PIT), and FIB. The FIB is used to forward interest packets toward poten-tial content holder(s) of matching data. It is almost similar to an FIB table of an IP router. The CS looks like a content cache. CCN allows data caching in intermediate nodes along the path between a content source and a content consumer. Hence, CCN can provide localized transmission near content requesters. The PIT keeps track of interests forwarded toward

con-tent holder(s) so that data can be sent back to its requester(s). PIT entries are eliminated as soon as they have been consumed to forward a match-ing data packet. PIT entries for interests that never find matching data are eventually timed out and naturally eliminated.

The content retrieval in CCN is as shown in Fig. 1. When an interest packet arrives on one face, a CS lookup is done based on its content name. If a matched data is found in the CS, the data packet is served. Otherwise, it is compared against a PIT to check whether it has already received another request for the same content. If a match is found in the PIT, the CCN node adds the face on which the new interest packet arrived. When the data packet that consumes the interest arrives at the node, it is replicated and sent out on all faces in the PIT entry for the content. If the content name matches neither the CS nor the PIT, the FIB is referenced to deter-mine the outgoing face where the interest packet should be forwarded. Moreover, an entry is added to the PIT for the forwarded interest packet. From the added entry, the received data packet can be sent back to the content requester. That is, data packet processing is relatively sim-ple since a data packet is not routed but simply follows the chain of PIT entries back to the con-tent requester.

P

ROBLEMS

D

UE TO

M

OBILE

C

ONTENT

C

ONSUMERS Even though CCN is efficient for content shar-ing, there may be cases in which such inherent benefits are lost if content consumer/source is a mobile device. For mobile CCN clients (i.e., mobile content consumers), there may be an unnecessary network resource consumption [8].

Figure 1.CCN forwarding model.

Name Data

/s.com/video/a.mpg/v3/s1 /s.com/video/a.mpg/v3/s2

Lifetime Content store

Face 0 (1) Interest/s.com/video/a.mpg/v3/s2

(10) Deliver data (9) Cache the data

Name Incoming face(s)

(3) No matched entry (8) Consume the PIT entry

/s.com/video/a.mpg/v3/s2 0

Lifetime Pending interest table (PIT)

(5) Add an entry to PIT

A A Face 2 (6) Forward interest (7) Receive data A A Face 3 Face 1

Domain prefix Outgoing_face(s)

/s.com/ FIB

2

(4) Check FIB entry (longest matching entry)

The CCN protocol is based on two packet

types, namely inter-est and data packets.

Interest packets are similar to “content

query” in a publish/subscribe

sys-tem, which carries a name that identifies the desired data. Data packets are analogous to

“con-tent response,” which is utilized to

carry the actual content.

During the content sharing phase, the previous content router does not know the movement of the mobile consumer device. Thus, data packets from content holders are unnecessarily transmit-ted around the old location of the mobile con-sumer device. Interest packets are repeatedly transmitted after handover to request data pack-ets that were already requested at the old loca-tion but not yet received.

Meanwhile, as data packets stored near the old location are not available until the routing table is updated, the data packets re-requested after handover may be delivered from the remotely located content source, not from near-by CCN devices with cached content. To find locally cached content, significant routing updates are required. This results in the high complexity of CCN routing on hierarchical iden-tifiers and long latency during device movement.

P

ROBLEMS

D

UE TO

M

OBILE

C

ONTENT

S

OURCES Contrary to client mobility, content source mobility in CCN creates a complicated situation. When moving away, a mobile content source (MCS) requests all content routers (CRs) to update their routing tables for the successful reception of future/ongoing content requests. However, it takes much time to update the rout-ing tables of all content routers. Thus, the inter-est packets may not reach if the route to the relevant content source changes; hence, the interest packets are unnecessarily sent again because content requesters do not know whether no data receptions are brought about by a net-work problem or node movement. Furthermore, if there are too many MCSs, it leads to the pol-lution of the routing tables for their prefixes, which counters the advantages of prefix aggrega-tion. Consequently, there may be a number of false routing entries in CCN networks, which leads to unnecessary resource consumption and long communication setup latency. This implies the following problems.

• The content consumers may encounter a service disruption since they are not aware of the domain change of the content source. If content consumers want to continue the service with the MCS, all content routers have to register for the roaming content source (i.e., the content source with the new domain prefix). Consequently, a recon-struction of the entire routing information will occur.

• The content source mobility is critical for protocols that construct routing information because the reconstruction of the entire routing table is costly and inefficient for MCS.

• If a renaming method may be considered, it gives up naming persistence and then leads to too many service access failures. That is, whenever a movement of content source happens, the content data generated at the previous location cannot be served due to the domain name prefix change.

For example, if the device responsible for a specific content name prefix moves, it may re-register its name prefix using a prefix announce-ment. However, it can jeopardize scalability and aggregatibility of the routing system by causing

too many dynamic routing updates. Because the whole network must be informed of every move-ment by all MCSs, it is feasible only in small-scale networks with a small number of MCSs. That is, the increasing number of MCSs is direct-ly related to the increase in the routing table size as well as long latency on name prefix lookup at the PIT and FIB.

There are some methods to solve such prob-lems. Reference [9] shows one method for sup-porting mobile devices in CCN environments. It makes only one extended path from the original domain router to the router in a moved domain. However, it invokes routing scalability and route failure problems. Moreover, [10] indicates the problem for the routing-based mobility support method. It assumes that content sources do not often move, and then content source mobility is unlikely to be a big problem. However, as this article is targeting the mobility of mobile devices acting as both content consumers and sources, the movement of content sources may be a com-mon practice.

N

EW

M

OBILITY

M

ANAGEMENT FOR

M

OBILE

C

ONTENT

S

OURCE IN

CCN

The point of the proposed scheme is to redirect incoming interest packets using tunneling between the MCS’s home domain content router (CR) and the CR in the moved domain to han-dle content source mobility in CCN environ-ments. CRs are assumed to periodically broadcast their prefixes to announce their pres-ence. Through the comparison of name prefix information announced from CRs, mobile CCN devices can detect whether the CCN network attachment point is changed and when they initi-ate a prefix updiniti-ate phase to the home domain CR (CRH). CRHis the content router that

ini-tially announces the name prefix of the MCS to other content routers. Thus, all interest packets toward the MCS can be delivered to the CRH

through the preconfigured name prefix routing information.

The proposed scheme starts when an MCS sends a prefix update (PU) message to its CRH

to inform it of its movement event. At that time, an MCS locally announces its tentative name prefix to advertise its presence in the moved domain. The CR in the moved domain forwards the PU message toward the home domain of the MCS. Through the exchange of PU and prefix update acknowledgement (PACK) messages, the redirect path can be configured from the original home domain to the moved domain where the MCS is currently located. Afterward, interest and data packets are exchanged between the MCS and the CRHusing the name prefix

encap-sulation.

The operation of a tunnel-based redirection (TBR) scheme is largely made of three steps. The detailed procedures are as follows.

Step 1. Movement indication: An MCS detects whether to change network status by using underlying physical link information or network address information. Generally, the MCS enters the network via wireless access points. It is assumed that the initialization data

Content source mobility in CCN cre-ates a complicated situation. When moving away, a mobile content source (MCS) requests all content

routers (CRs) to update their routing

tables for the suc-cessful reception of future/on-going

con-tent requests. How-ever, it takes much time to update the routing tables of all content routers.

is provided to the MCS by the wireless access points that would contain a collection of CRs available inside the access domain network. From the initialization data, the MCS can decide whether a prefix update message is required. Upon detecting a change in network location through the comparison of domain name prefix-es, the MCS first configures a tentative name prefix based on the moved domain CR’s prefix for interest packet tunneling from CRHto the

moved domain. The tentative name prefix is composed of the moved domain name prefix and MCS’s original name prefix. The MCS then per-forms duplicate name prefix detection (DND) to check the validity of this tentative name prefix. To perform DND, first, the MCS broadcasts an interest packet to all devices on a physical link in the moved domain CR asking if anyone is using its tentative name prefix. If the name prefix is already used by another device, that device must send a data packet to defend its name prefix. The MCS then has to configure a new tentative name prefix and repeat the DND process. Thus, DND can be conducted to guarantee only the uniqueness of the tentative name prefix within

one-hop neighbors. After a successful DND pro-cess, the MCS sends a PU message indicating its new location to its home domain CR. That is, the PU message includes the tentative name pre-fix as well as MCS’s signature to validate whether the PU originator is valid (as shown in Fig. 2). The pu component indicates which type this interest packet is.

Step 2.Path redirect configuration: The CR receiving a PU message compares its name pre-fix domain with that of the PU message. If its domain prefix is different from that of the PU message, the CR just forwards the PU message to the content source’s CRHbased on FIB

refer-ence. Otherwise, it does not forward the PU message and then transmits a PACK message to the MCS. That is, when receiving the PU mes-sage, each intermediate CR draws out the name prefix information from the received PU mes-sage and then checks its routing table about the entry for the MCS’s home domain CR. Then the relevant PIT entry is created with the name pre-fix of the MCS’s home domain CR that is locat-ed at the front part before the pucomponent.

On receiving a PU message, the home domain

Figure 2.Operation of the proposed TBR scheme.

Home CR prefix pu Tentative prefixCS signature

Home CR prefix Message type MCS’s signature Tentative prefix (foreign + MCS prefix) * Prefix update (PU)

Home CR prefix Tentative prefix Data

Content name CS prefix

Interest (normal):

Content name Data CS signature CS prefix

Data (normal):

Tentative prefix CS prefix Content name Interest (tunnel): CS signature pu * PU acknowledgement (PACK) Example) /ss.com/alice/pu/ieee.org/comsoc/ss.com/alice/mobile/signature CR6 CR4 CR_H CR5 CR2 f2 f2 f2 f2 f2 f2 f1 f1 f1 f1 f1 f1 CR3 Content source (CS) Content source (CS) PU PACK Interest (normal) Interest (tunnel) Data (tunnel) Data (normal) f3 f3 f3 f4 Tunnel

Tentative prefix Content name Data CS signatureCS signature Data (tunnel): CS prefix

The point of the pro-posed scheme is to

redirect incoming interest packets using tunneling between the MCS’s

home domain con-tent router (CR) and the CR in the moved domain to handle

content source mobility in CCN

CR serving the MCS checks if the original initia-tor of PU message is valid. If the signature is proved to be valid, the CR sends a PACK mes-sage indicating that the prefix update is success-ful. Then the CRH’s routing entry for the MCS is

changed to the new face which the PU message is entered into and the tentative name prefix is together recorded. When receiving the PACK message, intermediate CRs look up the routing table again. If the relevant PIT entry exists that corresponds with the name prefix in the received PACK message, intermediate CRs consume the relevant PIT entry and then forward the PACK message to the next hop.

Step 3.Interest redirection: After a while, a content consumer may request a content data created by the MCS. The interest packets are delivered towards the original domain of the MCS. CRHcan deliver the interest packets from

the lookup of its routing table toward the domain where the MCS is currently located. At this time, CRHgenerates new interest packet

encap-sulating original interest packet and then for-wards the encapsulated interest packet to MCS’s tentative name prefix. Intermediate CRs between CRHand MCS’s tentative name prefix deliver

the encapsulated interest packet through a nor-mal CCN forwarding procedure such that the name prefix of the relevant PIT entry is related to the tentative name prefix. The MCS decapsu-lates the encapsulated interest packet from CRH,

and transmits the data packet in response to the interest packet to the CRH. Figure 2 shows the

simplified example of the proposed TBR opera-tion. It shows that contents can be shared through the encapsulation and decapsulation of both interest and data packets at CRH.

Interme-diate CRs decapsulate the tunnel header and then do content caching with the original name prefix of the requested content object. There-fore, the proposed scheme can keep the traffic reduction effect through CCN’s content caching.

Meanwhile, the proposed scheme seems to have a similarity with the Mobile IPv6 (MIPv6) method [11]. The main difference between them is for data packet processing. MIPv6 needs to encapsulate and decapsulate packets toward the MCS. That is, for the requested data transfers, all packets must reach the MCS. Contrary to

that, the proposed TBR scheme is that interme-diate nodes between CRHand a moved domain

can serve the requested content through content caching functionality. This may allow stable con-tent delivery even when the wireless channels of MCS are prone to high bit error rates, strong variation in bandwidth, high interferences, high round-trip times, and so on. Especially, the most of-interest packets relevant to data packets gen-erated from MCS have to be relayed by CRH.

CRHcan directly deliver data packets to the

MCS thanks to its cache, which leads to traffic offloading at the MCS. Moreover, from CCN’s inherent security characteristics, the processing for location update can be done without addi-tional security mechanisms. That is, in MIPv6, binding update and binding acknowledgment messages exchanged between the mobile node and its home agent must be protected by IP security using Encapsulating Security Payload (ESP) protection with a non-NULL payload authentication algorithm [11], while the pro-posed scheme can do validity check of a PU message through an embedded signature.

In summary, the proposed scheme can reduce the number of control messages and service dis-ruption latency by making use of redirection based packet delivery for MCSs.

P

ERFORMANCE

E

VALUATION

To assess the improvements of the proposed TBR scheme, we created a series of simulations where the mobility speed of a mobile device was varied. We constructed a flat random network topology consisting of multiple content routers (i.e., 40 to 200 content routers), in which each content router is connected to one wireless router. The prefix update is assumed to be trig-gered by a new name prefix advertisement. Con-tent consumers and an MCS are initially placed at a random position. As the simulation pro-ceeds, an MCS moves according to the smooth random mobility model because it makes user movements smoother and more realistic than other models [12]. An MCS initially selects its speed among 9.7 m/s, 11.1 m/s, and 12.5 m/s with probabilities of 1/5, 3/5, and 1/5, respectively. The speed is updated at a time interval that fol-lows an exponential distribution with a mean of mu= 25 s. Whenever a new speed is determined, the MCS accelerates or decelerates until the new speed is reached or a new speed is decided again. From [12], the maximum acceleration and decel-eration speeds are obtained as 2 m/s2_{and –4}

m/s2_{, respectively. It also decides whether to}

change its movement direction or whether to keep it with probabilities of 1/6 and 5/6, respec-tively, at a time interval with an exponential dis-tribution and a mean of mfnew= 50 s.

We measure the cost of supporting a mobile content source in terms of the effects on the work and content consumer devices. The net-work effect is measured as message load introduced by reconstructing a routing table. Routing overhead is the number of individual transmission of routing packets. All routing mes-sages traveling at each hop are counted. In addi-tion, the route reconstruction latency is considered. A fast route reconstruction allows

Figure 3.Routing overhead due to mobile content source. Number of nodes 60

300

Routing load [number of messages]

0 600 900 1200 1500 1800 2100 40 80 100 150 200 Basic CCN Mobile CCN

MCSs to send data packets sooner after moving into a new network, and indicates lower network resource consumption by reducing the number of content query packets. The effect on the con-tent consumer is represented as the concon-tent retrieval latency, which means how fast the requested content data can be completely down-loaded. Moreover, the number of interest pack-ets generated at content consumers is considered to show how many interest packets are addition-ally required due to content source mobility.

The number of routing packets is presented to indicate the resource consumption efficiency. As shown in Fig. 3, routing overhead is propor-tional to the movement frequency of the MCS and the network size. As the network size increases, the routing effectiveness of basic CCN degrades rapidly compared to the proposed mobile CCN. At high network size, more routing messages have to be delivered to report these events as well as update name prefix configura-tion. That is, basic CCN invokes full routing update more often, which means generating more routing packets. On the contrary, the pro-posed scheme has a lower amount of routing control overhead due to its partial route update nature. That is, it brings less routing load because of only location update processing from moved domain to home domain, not full update.

Figure 4 shows the results obtained when measuring the time required by the proposed and basic CCN scheme to converge. The time until the basic CCN achieves stability varies deeply depending on both the number of CRs that form the network and the route refresh interval. That is, as the number of CRs increas-es, it takes long latency for every CR to config-ure the route to arrive at the MCS. That is, each CR refreshes its routing table by asking for the updated routing information. However, the pro-posed scheme keeps this latency more or less constant until it reaches stabilization. This is due to the fact that the route reachability is achieved in a short amount of time through a partial route update by which the redirection path infor-mation is managed only at the home domain CR. That is, the results for the proposed scheme are dependent on the network distance between the home domain CR and the moved domain CR at which the MCS is located.

The delivery ratio is the ratio of the number of interest packets received by the MCS over the total interest packets (including original and retransmitted interest packets) sent by all con-tent consumers. It is presented as a function of the velocity of MCS and the network size in Fig. 5. It shows that the proposed scheme remains better than basic CCN, irrespective of network size. The proposed TBR scheme does not suffer from convergence latency because only the two nodes need to know the routing information, which can be achieved with fewer routing update messages. Moreover, after receiving a PU mes-sage, redirected interest packets by the home domain CR are immediately retransmitted to the new location without waiting for PIT timeout. On the contrary, the basic CCN scheme issues all route updates that require a certain amount of time to converge; so for some period after movement, interest packet deliveries to the MCS

are disrupted until convergence along the routes traveled by the MCS has occurred. Moreover, if an MCS is moving quickly, the routing update traffic necessary to propagate the new route may not converge before the MCS hands over again. This could result in a cascading series of route updates that never converge. That is, the pro-posed scheme utilizes the path redirection that allows fast route convergence for the MCS, which leads to higher probability of content access and lower service disruption latency.

Finally, the content retrieval latency is shown to indicate how efficient the proposed scheme is to support the movement of content sources. Figure 6 plots the average retrieval time of the content for volume of network size. It shows that when the network size varies, the proposed scheme remains quite stable and always better than basic CCN scheme. That is, the proposed scheme can provide shorter service disruption latency due to partial location update than the basic CCN scheme. The basic CCN delivers con-tent query packets toward the new location of MCS only after full routing updates, which leads to long service disruption latency. This confirms the robustness of the proposed mobile CCN architecture to network dynamics created by node movements.

Figure 4.Convergence time.

Number of nodes 60

50

Routing update latency (ms)

0 100 150 200 250 300 350 40 80 100 150 200 Basic CCN Mobile CCN

Figure 5.Delivery ratio at the mobile content source Number of nodes 60

0.2

Interest delivery ratio

0 0.4 0.6 0.8 1 1.2 40 80 100 150 200 Basic CCN Mobile CCN

C

ONCLUSIONS

This article makes the following main points. First, it shows that the frequent network change of mobile devices causes high network resource consumption and severe performance degrada-tion in CCN networking environments. Especial-ly, the movement of content sources is far harder to manage. That is, the movement of content sources induces full routing updates for route reconfiguration, which prevents mobile content sources from providing seamless service reacha-bility. It may result in long download latency and high resource consumption. Second, it presents a path redirection scheme to compensate for the effects of content sources’ movement. The mobile content source informs its home domain content router of its movement by delivering a prefix update message. From that, it can save resource consumption of network devices by limiting the range of routing update only to the home domain CR. Moreover, as all communications are done via the home domain content router irrespective of its movement, it can act as a content proxy for the mobile content source through CCN’s inher-ent continher-ent caching functionality. This feature is important in mobile-centric content-based net-works since mobile content sources inherently cause dynamic topology change, high resource consumption, and low route aggregation.

As future work, some problems such as single point of failure of CRHas well as triangular

routing by tunneling-based redirection should be investigated. Enhancements such as distributed mobility management architecture and local redirection from old content router and new content router can be considered for improved routing efficiency.

R

EFERENCES

[1] C. Hu et al., “Design of Mobile Group Communication System in Ubiquitous Communication Network,” IEEE Trans. Consumer Electron., vol. 56, no.1, Feb. 2010, pp. 88–96.

[2] J. Choi et al., “A Survey on Content- Oriented Network-ing for Efficient Content Delivery,” IEEE Commun. Mag., vol. 49, no. 3, Mar. 2011, pp. 123–27.

[3] T. Koponen et al., “A Data-Oriented (and Beyond) Net-work Architecture,” ACM Sigcomm Comp. Commun. Rev., vol. 37, no. 4, Oct. 2007, pp. 181–92.

[4] V. Dimitrov and V. Koptchev, “PSIRP Project: Publish-Sub-scribe Internet Routing Paradigm,”Int’l Conf. Comp. Sys. and Tech. (CompSys-Tech), June 2010, pp. 167–71. [5] M. Brunner et al., “4WARD: A European Perspective

Towards the Future Internet,” IEICE Trans. Commun., vol. E93-B, no. 3, Mar. 2010, pp. 442–45.

[6] V. Jacobson et al., “Networking Named Content,” ACM CoNEXT, Dec. 2009, pp.1–12.

[7] J. Nuriminen et al., “Drupal Content Management Sys-tem on Mobile Phone,” IEEE CCNC, Jan. 2008, pp. 1228–29.

[8] J. Lee and D. Kim, “Proxy-Assisted Content Sharing Using Content Centric Networking (CCN) for Resource-limited Mobile Consumer Devices,” IEEE Trans. Consumer Electron-ics, vol. 57, no. 2, May 2011, pp. 477–83.

[9] J. Lee et al., “Mobility Management for Mobile Con-sumer Devices in Content Centric Networking (CCN),”

IEEE Int’l. Conf. Consumer Electronics (ICCE), Jan. 2012, pp. 502–03.

[10] Z. Ming et al., “SIONA: A Service and Information Ori-ented Network Architecture,” AsiaFI Summer School, Aug. 2011, pp. 1–8.

[11] D. Johnson, C. Perkins, and J. Arkko, “Mobility Sup-port in IPv6,” IETF RFC 6275, July 2011.

[12] C. Bettstetter, “Mobility Modeling in Wireless Net-works: Categorization, Smooth Movement, and Border Effects,” ACM Mobile Comp. and Commun. Rev., vol. 5, no. 3, Jul. 2001, pp. 55–67.

B

IOGRAPHIES

JIHOONLEE([email protected]) received B.S., M.S, and Ph.D. degrees in electronics engineering from Korea Univer-sity in 1996, 1998, and 2001, respectively. From 2002 to 2011, he worked at Samsung Electronics as a senior research member. He is currently an assistant professor in the Department of Information and Telecommunication Engineering, Sangmyung University, Korea. His research interests include information-centric networking, secure M2M, and network security.

SUNGRAECHO([email protected]) received his Ph.D. degree in electrical and computer engineering from Georgia Institute of Technology in 2002, and B.S. and M.S. degrees in elec-tronics engineering from Korea University in 1992 and 1994, respectively. He is currently a professor in the School of Computer Science and Engineering, Chung-Ang Universi-ty, Korea. From 2003 to 2006, he was an assistant profes-sor in the Department of Computer Sciences, Georgia Southern University, and a senior member of technical staff at Samsung Electronics in 2003. From 1994 to 1996, he was a member of research staff of the Electronic and Telecommunication Research Institute, Korea. He is an edi-tor of Elsevier Ad Hoc Networks Journalsince 2012 and has served numerous international conferences as an orga-nizing committee member, such as IEEE SECON, ICCIN, ICTC, ICUFN, TridentCom, and IEEE MASS. His research interests include wireless networking, wireless sensor net-works, ubiquitous computing, pervasive computing, perfor-mance evaluation, and queueing theory.

DAEYOUBKIM([email protected]) received B.S., M.S., and Ph.D. degrees in mathematics from Korea University, Seoul, in 1994, 1997, and 2000, respectively. From 1997 to 2002, he worked for Telemann and Secui.Com as research staff. From 2002 to 2011, he was a senior research mem-ber in Samsung Electronics. In 2012, he joined the Univer-sity of Suwon, Korea, where he is currently an assistant professor in the Department of Information Security. His research interests include DRM/CAS, home networks, and Internet security.

Figure 6.Content retrieval time.

Number of nodes 60 20 Delivery latency (s) 0 40 60 80 100 40 80 100 150 200 Basic CCN Mobile CCN