Cloudlet-Aware Mobile Content Delivery inWireless Urban Communication Networks

Hassan Sinky and Bechir HamdaouiOregon State University, Emails: sinkyh@oregonstate.edu, hamdaoui@eecs.oregonstate.edu

Abstract—LinkNYC is a first-of-its-kind urban communicationsnetwork aiming to replace all payphones in the five boroughs ofNew York City with kiosk-like structures providing free sup er fastgigabit Wi-Fi to everyone. This work proposes and investigates theapplicability of shifting LinkNYC from a traditional IP net workto a content-centric network by upgrading all or a subset of theirkiosks with standalone cloudlets, which cache content as itdis-seminates throughout the network, and content delivery cloudletswhich are geographically distributed throughout the boroughsand store popular internet content. With this shift content isbrought much closer to the end user than traditional methodswhich is essential in highly mobile environments. Analysisshowsthat adopting multiple content delivery cloudlets dramaticallyimproves overall network performance and stability. Finally,given a cloudlet-aware path a mobile content delivery scheme isdesigned to offset service continuity issues that are amplified whena mobile user encounters multiple cloudlets with intermittentconnectivity. Results show an overall improvement in a mobileuser’s throughput, response time and cache hit percentage.

I. I NTRODUCTION

The proliferation of internet devices has resulted in effortsto integrate various wireless access technologies for improvedperformance, increased services and inter-connectivity of endusers. The recent growth in data demand has prompted re-searchers to come up with new wireless techniques (e.g.,MIMO [1], [2], cooperative communication [3], femtocells [4],etc.) and develop new technologies (e.g., cognitive radio [5]–[7], LTE [8], etc.) to be able to meet this high demand. Thisintegration allows for large geographic locations to be servicedproviding millions of end users with continuous connectivityand optimal quality of experience (QoE). However, the worldhas seen unprecedented urban population growth over theyears. In fact, the number of urban residents has increasedby nearly 60 million a year. By 2050, it is estimated that70% of the world’s population will be living in cities1. Urbancommunication networks and content delivery networks havebeen introduced to leverage these technologies to better servicecities and users alike. Content delivery networks are designedto improve overall network performance by bringing datacloser to the geographical locations of users. Urban com-munication networks have evolved over the years to addressurban challenges through the use of information, communi-cation technology and the Internet. Building such a networkinfrastructure capable of adequately servicing urban locations

This work was supported in part by the US National Science Foundation(NSF) under NSF award CNS-1162296.

1World population data sheet: http://www.prb.org/

has become increasingly difficult due to the shear number ofinternet devices and users.

Traditionally, content delivery nodes are geographicallydis-tributed throughout the world servicing different regions. Inlarge networks such as LinkNYC the same content may be re-quested by multiple users resulting in the content traversing theentire network multiple times to and from a remote content de-livery node hosting the content. This work, however, proposesand analyzes the placement of content delivery cloudlets withinLinkNYC’s infrastructure to bring content closer to consumers.This is especially helpful for mobile LinkNYC users naturallyexperiencing intermittent connectivity as they associatewithdifferent cloudlets across a path. Thus, a cloudlet-aware mobilecontent delivery scheme is proposed to address mobile servicecontinuity issues. Contributions of this work are:

• Performance analysis of the proposed shift of LinkNYC’sinfrastructure from a traditional communications networkto a content-centric network.

• Establishes that LinkNYC’s communications networkvastly improves with not only a content-centric shift butalso the placement of multiple content delivery cloudletsgeographically distributed throughout LinkNYC.

• Designs and evaluates a cloudlet-aware mobile contentdelivery scheme for mobile users undergoing frequenthandoffs and intermittent connectivity within LinkNYC.

• To our knowledge, this work is the first to analyzeand leverage LinkNYC’s urban communications networkthrough content delivery cloudlets improving overall net-work performance and stability as well as mobile contentdelivery and service continuity.

The rest of this paper is organized as follows. In Section IIa content-centric LinkNYC infrastructure is introduced andanalyzed. A cloudlet-aware mobile content delivery schemeisdesigned and evaluated in Section III. Finally, the articleisconcluded in Section IV.

II. CONTENT-CENTRIC URBAN COMMUNICATION

NETWORKS

Coupling urban communication networks with content-centric and delivery principles greatly benefit content produc-ers, consumers and the cities they reside in. Improving their in-frastructure using practical approaches to provide more reliableand responsive communications can assist in the technology’soverall success. The underlying concept behind content-centriccommunication networks is to allow a consumer to focus onthe desired named content rather than referencing the physical

Figure 1: Microsoft Azure CDN point of presence locations

location or named hosts (IP) where that content is stored. Thisshift is a product of empirical research resulting in the fact thatthe vast majority of Internet usage involves data being dissem-inated from a source to multiple users. The potential benefitsof a content-centric adoption include in-network caching toreduce congestion, improved delivery speeds, simpler networkconfiguration and network security at the data level [9]. Thispaper combines content-centric and content delivery principlesto improve LinkNYC performance and reliability.

A. Content Delivery Networks or CDNs

The principle behind CDNs is to bring data as close to thegeographic location of the user as possible to improve overallnetwork performance. This helps eliminate the need to traversethe Internet for content which reduces infrastructure and band-width costs while improving network robustness and QoE. Forinstance, Microsoft Azure’s content delivery network consistsof 36 points of presence locations2 distributed throughout theworld as shown in Figure 1. However, in addition to beinggeographically limited, CDN nodes are generally placed atthe Internet edges over multiple backbones servicing differentregions remotely. Although the concept of bringing contentcloser to the consumer through caching copies in variousgeographic locations improves overall network performance,mobile users in large urban communication networks such asLinkNYC naturally endure additional latency due to increasedmobility, congestion and hops traversed within the network.This can be improved by placing content even closer to therequesting consumer through content-centric networking anddelivery principles and is discussed next.

B. LinkNYC

In November 2014 LinkNYC announced a project plan toprovide a first-of-its-kind communications network offeringsuper fast free gigabit Wi-Fi to everyone in New York Citythrough the replacement of thousands of payphones withkiosk-like structures calledLinks with deployment underwaybeginning January 2016. Once completed, LinkNYC will bethe largest and fastest free public Wi-Fi network in the world.The Links are designed as an update to the standard phonebooth and act as Wi-Fi hotspots while also providing basic

2Figure 1 provided by Microsoft Azure: https://azure.microsoft.com/en-us/documentation/articles/cdn-pop-locations

Borough # Payphones Avg. distance

Manhattan 3409 43.2 mQueens 1042 136.8 mBrooklyn 1004 150.8 mBronx 591 125.5 mStaten Island 51 606 mTotal 6097 212.5 m

Table I: Payphones in the five boroughs of NYC

services such as advertisements, free phone calls, device charg-ing, touchscreen for Internet browsing to access city services,maps and directions. Revenue generated by the Links, throughkiosk Ads that are displayed on 55 inch displays, is used tomaintain the LinkNYC infrastructure. Each Link is equippedwith 802.11ac Wi-Fi technology yielding download and uploadspeeds of 300 and 320 Mbps respectively with an averagelatency of 5 ms and coverage area of up to 45 meters dependingon location. This promising urban communications networkprovides cities with revenue and analytics while offering con-sumers free, continuous and reliable connectivity.

In order to leverage content-centric and content deliverynetworking with LinkNYC’s communications infrastructurethis work proposes an architectural addition of cloudlets tobetter service end users. Cloudlets are small-scale cloud data-centers that aim to bring data closer to mobile users and aretypically located near the edge of the Internet [10]. UpgradingLinkNYC’s Links with cloudlets offers a different dimensionto content delivery networking. Naturally, the number of po-tential cloudlets depends on the number of currently installedpayphone locations3 summarized in Table I. Manhattan isthe most dense of the five boroughs with 3,409 payphonesand an average distance between them of 43 meters. Unliketraditional CDNs, where a limited number of remote serversor nodes are distributed throughout the world, the proposedapproach geographically places cloudlets within LinkNYC’snetwork. This work proposes the placement of cloudlets in allor a subset of LinkNYC Links. Specific Links are selectedas content delivery cloudlets or producers of content and areequipped with anL2 storage cache that is much larger thanthe L1 storage cache available on other cloudlets. In order todecide which cloudlets will provide content delivery servicesa hierarchical clustering technique is used.

C. Hierarchical Clustering

As consumers become increasingly mobile the placement ofcontent delivery cloudlets within a large network is crucial.Specifically, mobile users that undergo frequent handoffs asthey move across a path results in transport layer issues thatreduce service continuity and overall QoE [11]. Placing asingle content delivery cloudlet or content producer withinthe network is insufficient to meet the demand of the mobileconsumer. Having content readily available in multiple nearbycontent delivery cloudlets helps avoid the additional costs of

3NYC Open Data: https://nycopendata.socrata.com

Figure 2: Geographic locations of payphones in NYC

traversing the network for the content. In an effort to analyzeLinkNYC’s network and decide for the placement of contentdelivery cloudlets a hierarchical clustering technique isappliedto the borough topologies.

LinkNYC cloudlets are categorized based on their boroughas shown in Figure 2. Since physical characteristics of NewYork City’s payphone backhaul connectivity are unknownpractical assumptions are made. First, we assume cloudletsare physically connected by fiber optic cables to their nearestneighbor. Given a particular NYC borough, i.e. Brooklyn, aeuclidean minimum spanning tree (EMST) is constructed asshown in Figure 3 using Prim’s algorithm where edge weightsequal the geographic distance between cloudlets. This resultsin a network topology withN−1 edges whereN is the numberof cloudlets in a particular borough. Second, content deliverycloudlets are geographically distributed throughout the boroughnetwork based on an edge-betweenness hierarchical clusteringtechnique. This technique, known as the Girvan–Newman algo-rithm, progressively removes edges from the original topologythat are least central to clusters to form network communi-ties [12]. Edges are ranked based on the number of shortestpath combinations that run through them. Higher ranked edgesare assumed to be most ”between” communities. The edge withthe highest edge-betweenness is removed. Edge-betweenness isthen recalculated for the edges that are affected by the removal.This process is repeated until no edges remain resulting ina set of communities. As shown in Figure 4, the number ofcommunity clusters created for Brooklyn’s topology is 24.

D. Content Delivery Cloudlet Placement

Given the resulting cloudlet communities from Section II-Cone node is selected per community as the content delivery orproducer cloudlet which stores content in itsL2 cache. The

Borough Clusters CDN %

Manhattan 64 1.9%Queens 37 3.6%Brooklyn 24 2.4%Bronx 30 5.1%Staten Island 9 17.6%Total 171 2.8%

Table II: Content delivery cloudlets in each borough

producer cloudlet is selected based on its distance from theremaining cloudlets within its respective cluster. That is, thenode with the minimum sum of shortest paths to the othernodes is selected as the content delivery cloudlet. This ensurescontent is placed as close to the geographic location of potentialconsumers within a cluster as possible. Table II shows theresults after applying this technique to the remaining boroughs.LinkNYC’s overall communications network yields 171 totalcontent delivery cloudlets which makes up 2.8% of the totalnumber of cloudlets within New York City.

Figure 3: Brooklyn’s LinkNYC Network

E. Borough Analysis

Different Internet architectures have been introduced forcontent-centric networking which shifts from the standardIPdata packets to Named-Data Networking (NDN). NDN is a fu-ture Internet architecture focusing on a content-centric Internetas opposed to today’s host-centric network architecture [9],[13], [14]. These architectures rely on named-content withinthe Internet to route and direct the flow of data within anetwork. In these architectures the content is the focus ratherthan the physical location where the content is stored.ndnSIMis an NDN simulator based on NS-3 and was used to analyzethe proposed urban communications network infrastructure.ndnSIM consists of content consumers and producers. Con-

sumers generate interest requests for specific content chunkswhereas producers respond to interest requests with data pack-ets. Every node is equipped with a Content Store (CS), PendingInterest Table (PIT), and Forwarding Information Base (FIB).When interest packets are received it is first placed into the

●●●●●●

●

●●

●

●● ●●●●●●●●●

●

●●●●●●●

●●●

●●●

●●

●●●

●

●●

●● ●

●●

●

●●●●

●●●●

●

● ●●●

●●●●●●●●●●●●●

●

●●●●●●

●●●

●●●●

●●

●

●●

●●●

●●

●●

●●●●●● ●

●●●●●

●

●●

●●●●●

●

●●●●●●●●

●●

●●●●

●●●

●●●●●●●●

●●●●●

●●●

●

●●●●●●●●

●

●●

●

●●●

●●

●

●●●●●●●●

●●●●

●●●●

●

●●●

●

●

●●●

●

●●●●

●●●●●●●●●●●●●●●

●●●

●●●

●

●

● ●●●●

●●●

●●●●

●●●

●●

●●●

●●●●●●●●●●●●●●●●●●●●

●●●●

●●

●●

●

●●●

●●●●

●

● ●●●

●

●●

●●●

●

●●●●●●●●●●

●

●●●●

●●

●●

● ●●●●●●●●●

●

●●●

●●●●

●●

●●●●

● ●●●●●●●

●●●

●●

●●●●●●

●●

●

●

●●●

●●

●

●●

●

●●●

●

●●●●

●●●

●●●

●●

●

●

●●

●●

●●●

●

●

●●●●●●●

●●●●●●●●

●

●●●

●●

● ● ●●

●●●

●●●● ●

●

●●●●●●●

●●

●●●●●●●●●

●●●●●●●●●●

●●●●●●●●●●●●●●

●●

●●

●●●●●●●

●●●

●●●●●●

●●●●

●●●

●●●●●●

●

●

●●

●●

●

●

●●●

●●●●●●●

●

● ●●

●●

●

●

●●●

●● ●●●●●

●

●

●

●●●●

●●●●●●●●●●●

●●●●●●●●

●●

●

●

●

●●●●

●

●●

●

●●●

●●●

●●●● ●

●●●●●

●

●●●●●●●●●●●●

●●

●●

●

●●●●

●●●

●

●●

●●●●

●●●●●●●●●●

●●●●●●● ●

●●

●●●●●●

●●●●●●●● ●●●●

●●

●●●

●●

●

●●●●

●●●

●●●

●●●

●

●●●●

●●●●

●

●●

●●●

●●●●●●●●●●

●●●

●●●

●

●●

●

●●●●●●●

●●●

●●

●

●●●

●●

●

●●

●

●●●

● ●

●●●●●●

●●●

●

●

●

●●●

●●●●●●●●

●●●

●

●

●●

●●●●●●●●●● ●●●●●●●●●●●●

● ●● ●●

●

●●● ●●●

●●

●

●●

●

●●●●●●●●●●●●●●●● ●●●●●●

●●●

●

●●

●

●●

●

●●●●

●●●

●

●●●●●●●●●●●●●●●●●●●●●●●●

●●●●●●

●●

●●●●●

●

●●

●●●●●●●●●●●●●●

●

●●

●

●●●

●●●●●●

●

●●

●●●●●●●●●

●●

●

●●

●●●●●

●●●●●●●●

●●●●●●●

●

●●●

●●●●●●●●●●●●

●●●●●●

●

●

●

●

●●●

●●●

●●

●●

●

●

●

●

Figure 4: Clustering of Brooklyn’s LinkNYC network

Parameter Value

Producers 24Consumers 60L1 Cache 1 GBL2 Cache 1 GBRequests 100 per secondsMax SeqNo 3000MTU 1400 bytesLink Rate 10 MbpsLatency 5 ms

Table III: Brooklyn Simulation parameters

PIT and the CS is checked for data correlating to this interest.If there is a match the interest request is discarded and thecorresponding data packet from the CS is returned. Otherwisethe interest packet is forwarded based on information in theFIB. Incoming data packets corresponding to pending interestsin the PIT are stored in the node’s CS. Otherwise, the datapacket is dropped.

For this analysis a comparison is made between traditional,random and cluster-based content delivery cloudlet placementsin Brooklyn which comprises of 1004 nodes. The traditionalapproach randomly selects and places a single content deliverycloudlet to service this specific borough. This is done with andwithout intermediate cloudlets caching content to emphasizethe improvement in performance when shifting to the content-centric paradigm. The random approach randomly selects 24content delivery cloudlets whereas cluster-based selectsonecloudlet per cluster as mentioned in Section II-C. For eachsimulation 60 consumers are randomly selected and initiaterequests for the same content at different time intervals between0–60 seconds. Results of this analysis are shown in Figure 5.

Figure 5a shows the network at equilibrium when all con-sumers have received the final sequence number. This is apromising result as the difference between traditional contentdelivery placement with and without caching is quite dramaticand emphasizes the improvement of a content-centric shiftwithin LinknNYC’s network. The average number of hops

traveled by the traditional method with caching is slightlyover 10 hops compared to over 50 hops for the traditionalmethod without caching. Without caching, content is forcedto traverse the entire network to reach the regional contentdelivery cloudlet resulting in a much higher hop count. Inaddition, randomly distributing 24 content delivery cloudletsimproves the average number of hops to a little under 8. Finally,the cluster-based approach achieves better results yielding onaverage around 6 hops. Figure 5b shows the average hopcount midway through the simulation. This is an importantdistinction to make as it highlights the practical scenarioswhere, since consumers request content or join/ leave thenetwork at different time intervals, higher sequence numbershave yet to be requested and fully disseminate throughoutthe network. This results in high sequence numbers not beingavailable in cloudletL1 caches causing intermediate cloudletsto request the content from their neighbors and in turn requiringmore hops to traverse.

Figures 5d and 5c show the total number of cache hitsand ratio of hits to misses respectively at the content deliverycloudlets over time. A cache hit occurs when data correspond-ing to an interest packet is fulfilled from the in-network localcache,L1 or L2, of the cloudlets rather than from the producerapplication. As more users join the network the cluster-basedapproach achieves a higher number of cache hits as wellas a higher hit to miss ratio for requested content. This isattributed to the cluster-based placement of the content deliverycloudlets as opposed to a random selection. That is, the like-lihood that the cluster-based approach would place cloudletscloser to potential consumers is higher than other approaches.Eventually when equilibrium is reached, the cache hit to missratios converge for random and cluster-based approaches ashigher sequence numbers have fully disseminated the networkresulting in higher cache hits. However, traditional methodsyield poor results as they experience low cache hit percentages.

This analysis shows that LinkNYC can benefit greatly withnot only the adoption of a content-centric infrastructure (tradi-tional with caching) but also with the incorporation of multiplecontent delivery cloudlets within its urban communicationsnetwork. Overall a cluster-based placement approach exhibitspromising and more stable results yielding lower hop countsand achieving on average a higher rate of cache hits which inturn improves content delivery speeds. In a mobile environ-ment, where network conditions and service continuity issuesare amplified due to mobility, network stability and contentdelivery speeds are essential to a user’s QoE. Section IIIintroduces a cloudlet-aware mobile content delivery scheme forLinkNYC’s communications network given a user’s mobilitywithin a cluster serviced by a content delivery cloudlet.

III. L INK NYC MOBILE CONTENT DELIVERY

It is clear from Figure 2 that New York City is denselyequipped with thousands of potential cloudlets within an areapopulated with multiple mobile users. Within this environmentmobile users naturally experience frequent handoffs during

10

20

30

40

50

0 1000 2000 3000

Sequence Number

Ave

rage

Hop

Cou

nt

ClusterRandomTraditional W/CacheTraditional W/O Cache

(a) Average HopCount per sequence number at equilibrium

20

40

60

0 1000 2000 3000

Sequence Number

Ave

rage

Hop

Cou

nt

ClusterRandomTraditional W/CacheTraditional W/O Cache

(b) Snapshot of average HopCount midway

0.00

0.25

0.50

0.75

1.00

0 25 50 75 100

Time (Seconds)

Rat

io o

f Cac

he H

its to

Mis

ses

ClusterRandomTraditional W/CacheTraditional W/O Cache

(c) Content delivery cloudlet cache hit to miss ratio

0

20

40

60

80

0 25 50 75 100

Time (Seconds)

Cac

he H

its

ClusterRandomTraditional W/CacheTraditional W/O Cache

(d) Total cache hits on content delivery cloudlets over time

Figure 5: Content-centric LinkNYC performance results

a connection lifetime resulting in intermittent connectivitywhich is detrimental for mobile service continuity and overallQoE [11]. Content interest requests must go through a mobileuser’s point of attachment (PoA) or currently connected tocloudlet. This real world scenario risks frequent disconnectsand disruptions in a user’s service especially near the edges ofa cloudlet’s coverage area. In this case, even though a handoffmay be imminent, interest requests must still be requestedthrough the PoA. This causes potential packet losses, increasedresponse times and re-transmissions. Although the placementof content delivery cloudlets improves overall network per-formance, the physical characteristics and consequences of amobile user are inevitable. This requires the need to counterthese service continuity issues and disruptions by prefetchingcontent on the requesting user’s expected path.

A. Design

This work uses the architecture from Figure 6 to addressthe mobile issue by prefetching content on candidate cloudletslocated on a mobile user’s path. A cloudlet-aware GPS isassumed to provide a mobile user with a path containingmultiple cloudlets. In addition, each content delivery cloudletwithin a cluster is responsible for maintaining critical cloudletinformation such as location, throughput, coverage area andexpected traveling speed. This information is shared betweenthe content delivery cloudlets. A cloudlet-aware pathPN ,whereN is the number of cloudlets on a mobile user’s path,consists of a 4-tuple,(Ci, Ri, di, si), representing cloudletCi,

L1

Cache

D9

D8

D7

L2

Cache

F3

F2

F1

L1

Cache

D3

D2

D1

Cloudlet

Content delivery cloudletConsumer

Consumer

Figure 6: Mobile content delivery cloudlet architecture.

whereRi anddi areCi’s throughput and coverage area, andsi is the expected speed traveled withinCi’s coverage area. Inorder to prefetch chunks of content Algorithm 1 is applied bya mobile user as it moves within a cluster of cloudlets.

First, a mobile user obtains a cloudlet-aware path,PN = (C1, R1, d1, s1), ..., (CN , RN , dN , sN ), through a cen-tral server where cloudlet details are maintained while also con-tinuously monitoring its connection rate and speed within thecurrent PoA cloudlet coverage area. Second, a content specificmanifest file, which contains content details such as file size,is requested from the cluster content delivery cloudlet. Oncereceived, the mobile user parses the manifest file to acquirethe content size and in turn the maximum sequence number,

Parameter Value

L1 Cache 1 GBL2 Cache 2 GBFile size 200 MBRequests 1800 per secondMTU 1449 bytesRi 54 Mbps (802.11a)di 20 meterssi 1-2 m/s∆0 20 meters

Table IV: Simulation parameters

C3C1 C2 C4

C5 C6

C7

300 Mbps

1 ms

300 Mbps

1 ms

100 Mbps

10 ms

100 Mbps

10 ms

100 Mbps

10 ms

100 Mbps

10 ms

M

Figure 7: Simulation cluster topology.

Algorithm 1 Mobile Content Delivery

1: Input:2: PN = {(C1, R1, d1, s1), ..., (CN , RN , dN , sN )}3: M = content manifest file4: F = content size from manifest file5: Start:6: let Smax = ⌈ F

MTU⌉

7: let Scur = 18: let i = index of current cloudlet9: let j = index of candidate cloudlet

10: let dc = distance to candidate cloudlet11: while j ≤ N do12: if dc < ∆0 & F > 0 then13: Get 4-tuplePi andPj

14: Calculate content chunk to prefetch15: let E[Di] =

di

si×Ri

16: let E[Dp] =dj

sj×Rj

17: let Scur = ⌊E[Di]MTU

⌋+ Scur

18: if j==N then19: Cj → PreFetch(M , Scur, ⌊ F

MTU⌋)

20: E[Dp] = F

21: else22: Cj → PreFetch(M , Scur, ⌊E[Dp]

MTU⌋)

23: end if24: F = F − E[Dp]25: i = i + 126: j = j + 127: end if28: end while

Smax, based on the maximum transmission unit (MTU) of thenetwork. The mobile user also maintains a current sequencenumber,Scur, which is used to inform candidate cloudlets ofthe starting sequence number to begin prefetching at as theuser moves across a path. Each cloudlet is equipped with aprefetching service which takes as input the content manifestfile M , Scur, and the expected amount to be prefetched,E[Dp]. Based on the mobile user’s current speed,si, distancewithin the cloudlet’s coverage area,di, and throughput,Ri,the expected amount to be downloaded within the currentcloudlet isE[Di] = di

si× Ri. Thus, the expected sequence

number for the candidate cloudlet to begin prefetching at isScur = ⌊E[Di]

MTU⌋ + Scur. Information fromPj is then used

to calculate the content amount to be prefetched,E[Dp], bythe candidate cloudlet,Cj . Once a distance threshold,∆0,is reached the prefetching service on the candidate cloudletis initiated. For each iteration,Scur is updated based on theexpected amount of content downloaded within the currentcloudlet and is the starting sequence number for the candidatecloudlet’s prefetching service. This process is repeated untilthe entire content has been prefetched or the user has arrivedat its destination. Performance results of the proposed mobilecontent delivery scheme are discussed in Section III-B.

B. Evaluation

To evaluate the performance of the proposed mobile contentdelivery scheme the throughput, packet response times, numberof requests re-transmitted and cache hit to cache miss ratioswere measured on the simulated cluster topology shown in Fig-ure 7. Mobile userM requests 1,800 content chunks per secondfrom the content delivery cloudlet,C7, while moving across acloudlet-aware path consisting of cloudlets{C1, C2, C3, C4}.Table IV details the simulation parameters used.

Figures 8a and 8b show the throughput and packet responsetimes experienced by the mobile userM . The speed of themobile user varies between 1-2 meters per second in order tosimulate a brisk walk in an urban environment. Algorithm 1 isapplied as the mobile user moves across its path to proac-tively request content in anticipation of service continuityissues and intermittent connectivity. This improves contentdelivery speeds and minimizes response times as requestsare immediately fulfilled by the cloudlet’sL1 caches whichcontain the prefetched content. Without prefetching sharpdropsin throughput are visible when the mobile device associateswith C2, C3 and C4. This can cause issues with a user’sQoE especially with time sensitive content such as audio orvideo. Once the mobile user arrives at its destination theprefetching service is terminated. As shown in Figure 8c,prefetching also allows for the mobile device to experiencevirtually no re-transmissions during its movement across thepath, again due to the immediate fulfillment of requests fromthe L1 caches. This is better illustrated in Figure 8d whichhighlights the ratio of cache hits to cache misses on the cloudletpath. Algorithm 1 ensures content chunks will be availableand thus the cache hit ratio will always be 1 within the

19

20

21

22

0 20 40 60 80

Time (Seconds)

Thr

ough

put (

Mbp

s)With PrefetchWithout Prefetch

(a) Average throughput experienced over time.

0

25

50

75

100

0 10 20 30 40 50 60 70 80

Time (Seconds)

Res

pons

e tim

e (m

s)

With PrefetchWithout Prefetch

(b) Packet response times across path.

0

10

20

30

40

50

0 10 20 30 40 50 60 70 80

Time (Seconds)

Re−

tran

smis

sion

s

With PrefetchWithout Prefetch

(c) Number of re-transmitted requests.

0.00

0.25

0.50

0.75

1.00

0 20 40 60 80

Time (Seconds)

Rat

io o

f Cac

he H

its to

Mis

ses

With PrefetchWithout Prefetch

(d) Ratio of cache hits to cache misses.

Figure 8: Mobile content delivery performance results.

coverage area of candidate cloudlets. This proactive prefetchingtechnique results in improved delivery speeds, response timesand cache hit ratios providing mobile users, with intermittentconnectivity, a less strenuous transition which is essential formobile environments.

IV. CONCLUSION

In this paper, a detailed examination of LinkNYC’s urbancommunications network is performed to investigate the fun-damental benefits of shifting from a traditional IP network toa content-centric network where popular content is cached asit disseminates throughout the network. Traditionally, contentdelivery nodes are distributed globally to bring content ascloseto the geographic location of the user. However, promisingresults show that having multiple content-delivery cloudletswithin LinkNYC’s infrastructure dramatically improves overallnetwork performance and stability. Finally, mobile users withinLinkNYC are bound to experience intermittent connectiv-ity as multiple cloudlets are encountered. Thus, a cloudlet-aware mobile content delivery scheme is proposed to leverageLinkNYC’s infrastructure and improve a mobile user’s QoE.

REFERENCES

[1] B. Hamdaoui and P. Ramanathan, “Cross-layer optimized conditions forQoS support in multi-hop wireless networks with MIMO links,” SelectedAreas in Communications, IEEE Journal on, vol. 25, no. 4, 2007.

[2] B. Hamdaoui and K. G. Shin, “Characterization and analysis of multi-hop wireless mimo network throughput,” inProc. of the 8th ACMinternational symposium on Mobile ad hoc networking and computing,2007, pp. 120–129.

[3] W. Su, A. K. Sadek, and K. R. Liu, “Cooperative communicationprotocols in wireless networks: performance analysis and optimum powerallocation,” Wireless Per. Comm., vol. 44, no. 2, pp. 181–217, 2008.

[4] N. Chakchouk and B. Hamdaoui, “Uplink performance characterizationand analysis of two-tier femtocell networks,”Vehicular Technology, IEEETransactions on, vol. 61, no. 9, pp. 4057–4068, 2012.

[5] B. Hamdaoui and K. G. Shin, “OS-MAC: An efficient MAC protocolfor spectrum-agile wireless networks,”IEEE Transactions on MobileComputing, vol. 7, no. 8, pp. 915–930, 2008.

[6] B. Hamdaoui, “Adaptive spectrum assessment for opportunistic access incognitive radio networks,”IEEE Transactions on Wireless Communica-tions, vol. 8, no. 2, pp. 922–930, 2009.

[7] P. Venkatraman, B. Hamdaoui, and M. Guizani, “Opportunistic band-width sharing through reinforcement learning,”Vehicular Technology,IEEE Transactions on, vol. 59, no. 6, pp. 3148–3153, 2010.

[8] D. Dechene and A. Shami, “Energy-aware resource allocation strategiesfor lte uplink with synchronous harq constraints,”IEEE Transactions onMobile Computing, no. 99, pp. 1–1, 2014.

[9] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, k. claffy,P. Crowley,C. Papadopoulos, L. Wang, and B. Zhang, “Named data networking,”SIGCOMM Comput. Commun. Rev., vol. 44, no. 3, pp. 66–73, Jul. 2014.

[10] M. Satyanarayanan, P. Bahl, R. Caceres, and N. Davies, “The case forvm-based cloudlets in mobile computing,”IEEE Pervasive Computing,vol. 8, no. 4, pp. 14–23, Oct 2009.

[11] H. Sinky, B. Hamdaoui, and M. Guizani, “Handoff-aware cross-layerassisted multi-path TCP for proactive congestion control in mobileheterogeneous wireless networks,” inGLOBECOM 2015, pp. 1–7.

[12] M. Girvan and M. E. J. Newman, “Community structure in social andbiological networks,”Proceedings of the National Academy of Sciences,vol. 99, no. 12, pp. 7821–7826, 2002.

[13] A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM: NDN simulatorfor NS-3,” NDN, Technical Report NDN-0005, October 2012. [Online].Available: http://named-data.net/techreports.html

[14] S. Mastorakis, A. Afanasyev, I. Moiseenko, and L. Zhang, “ndnSIM 2.0:A new version of the NDN simulator for NS-3,” NDN, Technical ReportNDN-0028, January 2015.