mango: low-cost, scalable delivery of rich content on mobile devices

primary communications interface in the developing

world, and clearly, providing access to rich media on

people’s cell phones is a natural next step. But low-

cost delivery of rich content to and from mobile

devices has remained an elusive goal. (Indian con-

sumers are highly price conscious, and an operator’s

average revenue per user (ARPU) is $6 to $7 in India

[12], as compared to $51 in the United States). There

is a lack of easy-to-use applications to search for and

access rich media content on mobile devices (less than

Introduction and MotivationIn several emerging countries such as India, there

is high user interest and demand for rich media such

as movies, music video clips, and pictures. In recent

years there also has been a remarkable proliferation of

cellular services and handsets. For example, in India

alone there are more than 500 million cellular sub-

scribers, with about 10 million more added every

month, and penetration is projected to rise to 700 million

by 2012. (In contrast there are only 20 to 30 million per-

sonal computer [PC] users [12]). Cell phones are the

◆ mango: Low-Cost, Scalable Delivery of Rich Content on Mobile DevicesSharad Jaiswal, Anirban Majumder, Naidu K.V.M., Girija Narlikar,Viswanath Poosala, Nisheeth Shrivastava, and Ankur Jain

We present mango, a novel low-cost and highly scalable content deliveryservice for mobile phones. The service is targeted at emerging countries such asIndia where users are highly price sensitive, and there is considerable demandfor rich media content. mango is designed as a content “synch-up” service.Users install an application (app) on the phone, and through a simple menuselect content for download, upload, or sharing. Then, in order to actuallytransfer content to and from their phones, users visit or opportunisticallyconnect with mango hotspots. The hotspots are short range cells (installed inshops, cafes, or as an app in other users’ phones) with a backhaul connectionand a wireless interface (such as Bluetooth/Wi-Fi, and down the roadfemtocells) to communicate with the phones. Given a large number of suchlow-cost, short range access points, the mango network delivers content to thevery edge of the network, within a few feet from the user. Such a contentdelivery architecture is faster, cheaper, and can support a much larger numberof users than macrocellular data networks. In this paper we present the mangoservice architecture, discuss technical challenges to shorten download times andlower content delivery costs, and outline our plans to develop and deploy thisservice. We also discuss a variety of interesting applications and services thatcan be deployed over the core mango system. © 2011 Alcatel-Lucent.

Bell Labs Technical Journal 15(4), 63–78 (2011) © 2011 Alcatel-Lucent. Published by Wiley Periodicals, Inc. Published online in Wiley Online Library (wileyonlinelibrary.com) • DOI: 10.1002/bltj.20472

64 Bell Labs Technical Journal DOI: 10.1002/bltj

one to two percent of the ARPU is due to data services

[12]). An important reason is that current-day wire-

less data networks do not have the capacity to support

such bandwidth-hungry services for millions of users

at low price points. Operators have instead focused

on voice networks and low data rate data applications

such as email, ring tones, and wallpaper. The advent

of third generation (3G) wireless will alleviate the

problem, but its major impact will be to relieve the

pressure on highly congested voice networks, and to

reach out with attractive services to high-income

mobile users. But how can we successfully serve the

several hundreds of millions of very low-income

mobile users?

This paper describes mango, a novel application

and service that is designed to serve rich content on

mobile devices for low-income users in emerging

countries. Given our target demographic, the service

is designed to keep the user experience simple and

cost of delivery low. As first outlined in [10], users

download an application (app) on their phones that

allows them to browse and select content from a

menu and/or mark items to be uploaded or shared

with their friends. Then, to transfer content to and

from their phones, users visit or opportunistically con-

nect with a mango hotspot. The hotspots are a net-

work of inexpensive short range cells. Each cell has an

air interface to deliver content to and from mobile

handsets (Bluetooth*, Wi-Fi*, short range, cellular,

femto interface), and a backhaul connection (wired

broadband, 2.5/3G cellular data). The cells can be

physically installed in shops, cafes, bus stops, or other

public places, or can be implemented as a software

manifestation installed in user phones. The basic idea

behind mango is a content “synch-up” service, where

users select content when they are offline (i.e., when

the user is not in the vicinity of a mango cell). These

selections are sent over a low-capacity channel such

as short message service (SMS), or whenever a user

visits a mango cell. The actual transfer of the selected

content occurs when users travel to a mango hotspot.

These short range mango cells, in aggregate, have

sufficient capacity to serve content in a scalable fash-

ion. The cost of the service is kept low by deploying

inexpensive access points (in the case of physical

deployments), and low bandwidth, carefully managed

backhaul links. The mango service does not aim for

complete coverage (unlike a cellular service), thus

deployment is organic (i.e., users, shops, cafes and

other establishments deploy cells as demand grows)

and does not require any network planning or man-

agement.

The design of the mango service presents several

interesting technical challenges. Since users currently

have to visit a mango cell to access content, minimiz-

ing the time spent at a cell and keeping the user expe-

rience simple and hassle-free is key. Therefore, data

transfers need to be made seamless and reliable across

Panel 1. Abbreviations, Acronyms, and Terms

3G—Third generationAPI—Application programming interfaceapp—ApplicationARPU—Average revenue per userBT—BluetoothCDN—Content distribution networkDSL—Digital subscriber lineEDGE—Enhanced data rates for GSM EvolutionGSM—Global System for Mobile

CommunicationsHSDPA—High speed downlink packet accessHSPA—High speed packet accessI/O—Input/output

ISM—Industrial, scientific, and medicineJ2ME—Java 2 Micro EditionLTE—Long term evolutionMMS—Multimedia message serviceNFC—Near field communicationOS—Operating systemPC—Personal computerPIN—Personal identification numberSIM—Subscriber identity moduleSMS—Short message serviceTV—TelevisionUMTS—Universal Mobile Telecommunications

System

DOI: 10.1002/bltj Bell Labs Technical Journal 65

visits to multiple mango cells. Another important

challenge is intelligent prefetching of content at

mango cells to minimize the user’s wait time, while

making optimal use of the backhaul and storage

resources at the cells.

We explore data placement algorithms to meet

user demands in a timely fashion by mining the user’s

content access patterns, subscriptions, and mobility

patterns. An important aspect of the mango service

is to keep the cost of the content delivery low. Instead

of serving all content from a central server, with an

expensive fat network pipe, we explore a content

delivery architecture that will cache and source con-

tent from across the distributed network of mango

cells. Within such a content distribution network

(CDN), we investigate efficient algorithms to serve

content given the constraints of the backhaul links

and storage capacity of individual cells. Finally, given

the location of mango hotspots in semi-public places

with unmonitored access, securing content and user

transactions is an interesting challenge.

We view mango as an open platform to bring

content and applications to users, independent of

providers. The goal is to provide local administrators

with access to mango cells through a set of application

programming interfaces (APIs), which allows them to

install and serve content and applications. This makes

it possible to deploy customized services, such as those

of particular interest to users within a local geo-

graphical area. We believe that in an emerging market

with a wide diversity of literacy levels, languages, cul-

tures, and interests (such as India) such customiza-

tion will play a vital role in both attracting new

customers and engaging existing ones. We also believe

that such short range cellular architectures will

become more common in the future (to account for

cost and scalability), and the design and operational

lessons that will be learned from the mango service

will be invaluable in designing small-cell systems of

the future.

The paper is organized as follows. We describe the

mango system architecture, provide an overview of

the developed prototype and its performance, and

review deployment status. Next, through comparisons

with existing solutions, we elaborate on how the

mango architecture enables faster, lower-cost, and

substantially more scalable delivery of rich media on

mobile phones. We then describe some novel appli-

cations that can be enabled by the mango system, and

outline some interesting technical challenges towards

improving the user experience and lowering the opera-

tional costs of the mango system. We briefly summa-

rize related work and offer our conclusions.

mango ArchitectureThe mango system, shown in Figure 1, has three

basic components, an application on the phone, a

hotspot through which the app interacts with the rest

of the mango system, and a back-end content server

that is a repository of all content served through the

mango system, the mango user profiles, and all user

activity within the mango system. For our system to

work, we need users with phones that have a

Bluetooth/Wi-Fi radio, an ability to view multimedia

content, and a camera to make use of some mango

features. Such features are now finding their way

even to the lower-end models available in India, start-

ing at less than $50, and soon will be available in the

secondhand markets for less than one-third of this

price.

Figure 2 illustrates various mango applications.

The major components of the mango system include

the

• mango app, a mobile application which is installed

on the user’s device either over SMS/multimedia

message service (MMS) or by visiting a mango

cell. It serves the following functions. First, it pro-

vides an easy-to-use menu through which a user

can 1) browse and search for popular content

offered through the mango service or shared by

their friends, and mark it for download, 2) select

content on their phones, and mark it for upload

or sharing with friends, 3) access other content

on the mango system such as applications, adver-

tisements, or promotions. The menu is populated

either through a low data-rate channel (such as

SMS) or whenever a user visits a mango cell. This

allows the user to make selections without having

to visit a mango cell. Also, importantly, the app is

designed for seamless and opportunistic opera-

tion across user visits to a mango hotspot.

Checkpointing enables data transfer to resume


Easy to use menu(downloadable app)on phone with list ofcontent (music, videos),and friends list

Goes to small shop/kiosk

mango hotspot withBluetooth/femto access,

and DSL backend

mango contentserver

Broadband

Offline search over SMS(actual download

over hotspot)

Phone with amango soft app

(anyone canbecome a mobile

hotspot)

GPRS/3G/sync withmango soft app

3G—Third generationapp—ApplicationDSL—Digital subscriber line

GPRS—General packet radio serviceSMS—Short message serviceWiMAX—Worldwide Interoperability for Microwave Access

Figure 1.mango architecture.

First screen Content menu Multiple languages

Select content

Play and view

Figure 2.Screenshots of the mango application.


automatically in case an app is interrupted or the

user moves to a new hotspot. The app can also

keep track of and upload a user’s viewing patterns

to enable detailed analysis.

• mango hotspot. A mango user registers, authenti-

cates, and downloads/uploads content from the

mango system through a hotspot. The hotspot

may be an inexpensive access point with

Bluetooth, Wi-Fi, or 3G interfaces and storage, or

a software manifestation that can be installed on

user phones. It will have either wired backhaul

such as digital subscriber line (DSL), or a 2.5/3G

wireless data connection. Typical installation loca-

tions for physical mango hotspots include small

shops, malls, airports, college campuses, hospi-

tals, and railway stations. The software manifes-

tations can be installed by any user with storage

space and a data connection on their phone or

PC (which may be subsidized for selected users

by the mango service). The hotspot examines user

download requests and ascertains if they are

cached locally. If not, the content is fetched from

the back-end content server. The hotspot is also

aware of the user’s phone parameters, and when

relaying content carries out appropriate transcod-

ing to make it suitable for viewing on the phone.

• mango content server, which is the repository of

1) all content stored and served on the mango

system, and 2) all necessary information about a

user. The mango content server tracks user selec-

tions and activity within the social graph, as well

as frequented hotspots and usage history. Based

on the information collected, the content server is

ultimately responsible for making decisions about

what content to prefetch, and where to place it

among the mango hotspots frequented by a user.

Current StatusFor the first release of mango, we have written a

Java* 2 Micro Edition (J2ME) application for the

phones. The application offers a view of various types

of rich content (e.g., television [TV] shows, movies,

and songs) in various Indian languages. It also allows

users to browse and select content when offline.

The app has provisions for uploading user pictures

and sharing them with other mango system users.

We have also put together an inexpensive physical

hotspot (over Intel Atom* motherboards, with uni-

versal serial bus (USB)-based Bluetooth dongles) and

a back-end content server. We offer the following ser-

vices: 1) a selection of video content in four Indian

languages, 2) network storage for user content (e.g.,

photos), and 3) content sharing across a user’s phone

contact list. Whenever the user associates with a

mango hotspot, the content is fetched from the back-

end system, transcoded and adapted for the user’s

phone parameters in the hotspot, and served to the

mobile. We use storage available on online services

such as Flickr* and Picasa* to upload user content.

The Bluetooth-based mango system is designed

so an end user has fast access to the hotspot. The user

is not required to pair with the Bluetooth radio on

the hotspot at the same time, so security on the

mango system is not compromised. The Bluetooth

radio on the hotspot is configured with a special

device class value and the hotspot software runs as a

Bluetooth RFCOMM service on a pre-selected port.

Periodically, the hotspot scans for mobile devices

with mango applications in the vicinity, and

conversely—when the application is launched—it

scans for mango hotspots. Since the hotspots have a

special device class value, the application is quickly

able to filter and select from all other Bluetooth

devices in the vicinity. The mobile application recog-

nizes the hotspot service port and can directly contact

the hotspot server without going through a time-

consuming and unreliable service discovery phase. Since

the RFCOMM server is initialized with authorization dis-

abled, communication can be initiated without any

exchange of personal identification numbers (PINs).

However, to ensure the security of the system is

not compromised, the server and the application

implement a challenge-response protocol above the

Bluetooth RFCOMM layer. The user’s login and pass-

word (which could be cached in the application) is

transmitted back to the mango content server via

the hotspot backhaul to authorize the user, and the

hotspot subsequently presents a secret key, known

beforehand to the application, to confirm it is not a

“rogue” hotspot. This key can also be periodically

refreshed (e.g., conveyed to the application through

out-of-band mechanisms, such as SMS).


In short, the user experience is designed to be

hassle-free, requiring minimal intervention from the

end user.

Performance MeasurementsBased on extensive tests and measurements, we

have found that in the vicinity of a hotspot, the

mango application is able to connect and start com-

municating within 10 to 20 seconds. When tested

over phones with Bluetooth 2.0 radio (typically availa-

ble even in low-end phones in India), we observe

download speeds of about 800 Kb/s to 1200 Kb/s,

depending on the phone operating system (OS), and

file input/output (I/O) rates). A typical five minute

Bollywood music video of about 5 MB in size thus

takes about 40 seconds on average to download. Also,

the Bluetooth radio on a hotspot is a Class I device

with a range of 100 meters, while phones typically

have a Class II radio, with range of 10 meters.

However, because of the heightened receiver sensi-

tivity on the Class I radio, we have found communi-

cation persists in a range of 30 meters to 40 meters.

Finally, we have experimented with multiple

Bluetooth radios on the hotspot. Given that the

Bluetooth radio hops across frequencies to find an

interference-free section of the available spectrum in

the 2.4 GHz ISM band, we have found the radios can

coexist without interfering with each other. This way,

hotspot performance and capacity can be enhanced

by adding more low-cost radios.

A prototype mango system was deployed in the

Alcatel-Lucent building in Bangalore. We set up a

detailed feedback and measurement system to moni-

tor system performance and usage in order to prepare

the system for a larger rollout within the city of

Bangalore. Our goals for the second release also

include a software version of the mango hotspot,

which will be deployed on select data-enabled phones.

Alcatel-Lucent has a company wide transportation bus

service in Bangalore, and these software hotspots can

act as content relays for employees while commuting.

A mango hotspot prototype is shown in Figure 3.

While the current system is designed for access

over Bluetooth, we will soon have a Wi-Fi version

and we are also exploring building a proof-of-concept

over femtocells.

Comparison With Existing TechnologiesIn this section, we compare the mango content

delivery service with the traditional mechanism for

mobile content delivery—the cellular data network.

We believe the design of the mango app, as a content

“synch-up service” with an easy-to-use interface is a

crucial factor that will determine adoption in emerg-

ing markets. We also believe the mango system

enables content to be downloaded faster and cheaper,

and by substantially more users as compared to tradi-

tional cellular data services. We present the results for

back-of-the envelope comparisons of some crucial

performance metrics for mango versus existing cellu-

lar content architectures. While the benefits of small-

cell architectures, versus macrocellular architectures

are well documented, in the following section, we

carry out some simple calculations to illustrate the

benefits of a mango-like system across different access

technologies. We consider various air interfaces for

both types of networks in an urban setting. The cel-

lular technologies that we look at are a) Enhanced

Data Rates for GSM Evolution (EDGE), b) Universal

Mobile Telecommunications System (UMTS), and

c) High Speed Packet Access (HSPA) (peak 7 Mb/s

and 14 Mb/s). We do not include Long Term Evolution

(LTE) since it is unlikely to be available in emerging

markets in the near future.

Figure 3.mango hotspot prototype.


We evaluate three mango air interfaces:

a) Bluetooth (BT), which will be the first version and

immediately compatible with the most handsets,

b) UMTS femto, and c) HSPA femto. Based on assump-

tions of the size of downloads of a typical user, aver-

age download rates, number of simultaneous users,

and number of cells per square kilometer, we com-

pute the number of users that can be supported, and

subsequently the average download time per user.

We assume a user will download about 30 min-

utes of rich content (average bit rate 60 Kb/s) every

day and view some fraction of it. Peak download data

rates assumed for the air interfaces are: EDGE 384

Kb/s, UMTS 2 Mb/s, HSPA-7 7 Mb/s, high speed

downlink packet access (HSDPA)-14 14 Mb/s,

Bluetooth 500 Kb/s. Average download rates are: 1/4

of peak for macrocells and 2/3 of peak for mango cells

(given their short range). Services are compared in an

urban setting, with small macrocellular cell sizes.

EDGE cells are assumed to be 600 meters in radius,

while UMTS and HSPA cells are 500 meters in radius.

mango cells are assumed to be on average 250 meters

apart. We assume three sectors per cell, with frequency

reuse. The average number of simultaneous users is

assumed to be six in macrocells and two in mango

cells. Downloads can occur over a 24 hour period on

the cellular network, and in 9 hours for mango.

ScalabilityWe examine the number of users that can be sup-

ported per square kilometer by each architecture for

a rich media download service in an urban environ-

ment. Given the large number of short range but high

bandwidth mango cells, we expect that mango will

have the capacity to support a large number of users.

As quantified in Figure 4, mango using Bluetooth

can support an order of magnitude more users than

existing cellular data networks (EDGE) and signifi-

cantly more users (30 percent) than the first genera-

tion of 3G data networks that will be deployed in

emerging countries in the near future. Also, in time,

as mango evolves to a 3G femto-based architecture it

will continue to far outperform a cellular infrastruc-

ture with the same air interface.

Download TimeFigure 5 shows the time to download a day’s

worth of rich media content for each user. Lowering

the total download time significantly saves on battery

life by reducing the amount of time a mobile device is

in an active connection. Moreover, in the case of

204 1528

5348

10695

2037

8149

28521

0

10000

20000

30000

EDG

E

3G (U

MTS

)

HSP

A 7

HSP

A 1

4

man

go B

T

man

go U

MTS

man

go H

SPA

7

# u

sers

/sq

uar

e km

3G—Third generationBT—BluetoothEDGE—Enhanced data rate for GSM Evolution

GSM—Global System for Mobile CommunicationsHSPA—High speed packet accessUMTS—Universal Mobile Telecommunications System

Figure 4.Capacity to support users of a rich media delivery service in an urban environment.


mango, since a user may have to visit a hotspot, this

can be a key factor in determining the user experi-

ence. Once again, we observe that mango outperforms

both EDGE and first generation 3G technologies.

Cellular technologies are built to provide a shared air

interface with fair scheduling, therefore application

and network-aware scheduling [4] will be needed to

bring per-user download times on such systems close

to those on mango. mango with Bluetooth takes about

11 minutes to download 30 minutes worth of content.

We believe that given the ability of the mango app to

opportunistically connect with hotspots (say, when

the user is sitting in a cafe, or in a supermarket, or

through other user phones), some of this transfer time

can be pushed into the background, without the user

having to explicitly visit and wait in a hotspot.

Cost to User3G data services have only recently been intro-

duced in India and their cost is about Rs. 3,000 P.M.

($60) for unlimited access, and about Rs. 600 P.M.

($12) for limited download. In comparison, as men-

tioned previously, current ARPU for Indian service

operators is $6 to $7.

The service is currently available on high-end

handsets. Clearly the cost of equipment and spectrum

for deploying such services is exorbitant, and thus it

will take some time for it to penetrate into smaller

towns and villages. Cheaper data plans on EDGE net-

works (around Rs. 300 P.M.) are limited to web access

and do not allow arbitrary downloads or uploads.

For mango, our fixed costs are determined by the

cost of the hotspots, and the back-end hosting plat-

form. We will design a hotspot around commodity

Linux* single-board computers with the necessary net-

work interfaces, storage (about 100 GB) and reason-

able computing power. Putting together such a box

with off-the-shelf components currently costs about

$200 to $250, and down the road when such boxes

are mass-produced, we believe the costs can be

brought down to below $100 per hotspot. Supposing

an initial deployment in a city involved 5,000 hotspots,

the total cost will be less than $1 million, a fraction of

a comparable cellular deployment. A significant frac-

tion of the cost of running a mango network will be

due to the backhaul link. In India, the cost of a 256

Kb/s backhaul link starts at Rs. 3,000 P.M ($60) for a

business connection. If the link utilization is carefully

managed, per user cost, spread over all users of a

mango hotspot, can be kept fairly low.

We envision mango as a “pay-as-you-go” service,

and while the exact price of the service will depend on

EDG

E

3G (U

MTS

)

HSP

A 7

HSP

A 1

4

man

go B

T

man

go U

MTS

man

go H

SPA

7

Dai

ly d

ow

nlo

ad t

ime

(min

ute

s)

100

120

22

6 1120

40

60

80

3 3 10

113

3G—Third generationBT—BluetoothEDGE—Enhanced data rate for GSM Evolution

GSM—Global System for Mobile CommunicationsHSPA—High speed packet accessUMTS—Universal Mobile Telecommunications System

Figure 5.Total time required to download 30 minutes of rich content per day.


several other factors such as content-licensing costs,

hosting costs, and profits—components of any similar

service on a cellular network—given the points above,

we strongly believe mango can be offered at much

lower costs compared to conventional cellular data

services.

Services on mangoSome of the services and features planned for the

mango system are listed below. Apart from allowing

users to download popular (and personalized) rich

media content such as TV serials and music videos,

we believe that given the distributed nature of the

mango system, and our goal of an “open” architec-

ture, several novel services can be built over the

underlying mango system. Moreover, we think such

an open and distributed architecture can seed appli-

cation development customized for local interests and

demands.

• Create and share personal content. A user can share

content such as pictures, audio, and video files by

uploading it at mango hotspots. This content is

then delivered to the recipients when they visit

another mango hotspot. Users can also create new

multimedia content such as picture slide shows,

add text/voice comments or karaoke recordings,

and share them with friends.

• Inexpensive video or voice calls. A mango hotspot can

also serve as a “phone booth” to make inexpen-

sive video or voice calls. Video calls can be made

via a user’s personal camera phone or via a web-

cam connected to the mango hotspot.

• Mobile mango hotspot. A user carrying a phone with

either wireless connectivity or by frequently vis-

iting mango hotspots, can himself act as a mobile

mango hotspot. He can then offer mango services

to locations where a backhaul connection for the

hotspot is not possible, such as remote villages,

and long-distance buses and trains.

• Local advertisements. The mango network can host

a localized yellow page service. Any user can walk

to a hotspot and add advertisements, announce-

ments, offers, or reviews about local services such

as shops, events, or news. mango will allow sim-

ple creation of text, audio, and video yellow page

ads which will be displayed at specific local

hotspots and a simple search/browse interface for

users to view these ads.

• Content customization. The owner of a mango

hotspot (who keeps it in his shop or home)

should have access to the content and services

listed at his hotspot through a simple interface.

This enables him to tailor the content and ser-

vices at his hotspot according to the needs of fre-

quent visitors. For example, he could create a few

easily accessible packages of locally-relevant con-

tent, or offer special calling or money transfer

rates during local festivals.

• mango apps store. Emerging markets users have lit-

tle awareness of and access to new applications

for their mobile devices. Currently the only appli-

cations most customers use are those supplied by

the manufacturer on the handset or by the opera-

tor on the SIM card. The mango hotspot can serve

as an apps store and new applications can be

offered to each user as part of the personalized or

localized content for their handsets.

• mango payment gateway. mango hotspots installed

in shops can act as secure mobile payment gate-

ways. Thus payments for retail transactions in the

shop can be made more convenient by replacing

cash with the mobile phone, similar to near field

communication (NFC)-based payment systems.

Person-to-person cash transfers can also be

enabled, with mango hotspots and their owners

acting as intermediary agents.

Research DirectionsWe now explore some technical challenges in

improving the mango system’s performance from the

perspective of a user, reducing the cost of content

delivery within the mango system, and investigate

some interesting security challenges posed by the

mango architecture.

Prefetching ContentEach mango hotspot has a dedicated backhaul

link, and the number of such short-range hotspots

could be substantially larger than in a typical macro-

cellular system. Thus, the cost of each backhaul link

has to be kept low, and as a consequence capacity will

be low as well. In fact, compared to the short range


high-rate wireless interface, the wired backhaul link

may actually be a bottleneck (e.g., typical broadband

speeds in India are 256 Kb/s, compared to the 500

Kb/s that can be easily achieved over a Bluetooth

radio). Since we expect the user to visit a mango

hotspot to transfer content to and from their mobile

device, it is imperative that the time spent at a hotspot

is minimized. Given that the backhaul link may be a

bottleneck, prefetching content on the hotspots

becomes crucial to reduce download times, and useful

for other reasons as well, such as to mitigate the load

on the back end servers.

The mango system presents some novel prefetch-

ing issues. The system not only has to decide what to

prefetch, but considering that users are mobile, also

where to prefetch content. The first aspect can be

ascertained based on the user’s selection through an

app in offline mode, or by predicting his preferences

using his viewing history. Further, given that content

would be shared by users in their social network, we

can also predict the demands of a user by mining his

social graph and sharing history. The obvious

approach is to exploit the user’s mobility patterns in

order to determine the hotspot(s) to which content

should be pushed. Studies have shown that most users

follow a very predictable mobility pattern in terms of

the geographic areas they cover [8]. Therefore, based

on the user’s historical mobility data, (which can be

collected by his past connectivity with various

hotspots), a straightforward policy would be to iden-

tify the set of hotspots a user has a high chance of

visiting and prefetch content of interest in those

hotspots. We illustrate this concept in Figure 6.

However, there are other aspects to keep under

consideration. Both the storage space and backhaul

capacity of a mango hotspot is limited. Also, the time

spent by a user at a single hotspot may not be suffi-

cient to transfer all the content the user desires, and

there may also be a limit on the number of hotspots a

user would be willing to visit in the course of a day.

Finally, each hotspot has to satisfy the requirements of

multiple users. This means prefetching the content

common to many users might reduce the load on the

backhaul link, but at the same time, the system must

ensure fairness among different users so that each user

gets the content of their choice in a timely fashion.

Using its knowledge of demand, the mobility pat-

terns of multiple users, and the constraints on storage

and bandwidth in the hotspots, the system has to

decide upon an appropriate set of hotspots in which

to place the content to maximize the likelihood of a

user downloading his content in a timely fashion.

User route

mangocells

Prefetch content alongthe route

Figure 6.Prefetching content onto mango hot spots based on user mobility patterns.


Reducing Delivery CostsAs described in the section on mango architec-

ture, the mango system has a back-end content server

that, among other things, serves as a repository of all

content to be served to the end users. Whenever a

hotspot or an end user makes a request for content,

the naive implementation would be to retrieve it

directly from the content server. However, this implies

that the network link at the content server has to be

an expensive, fat pipe that can scale to serve hun-

dreds or thousands of mango hotspots. Therefore, it is

worth investigating if there is a way to reduce the cost

of content delivery. Simply caching the content locally

on the hotspots will have a limited impact because of

the dynamic nature of content popularity—e.g., popu-

lar content remains popular only for few days,

whereas the popularity of user-generated or shared

content decays at an even faster rate.

We know that the hotspots have a dedicated

backhaul link with a certain sunk cost. Typically, e.g.,

in India, broadband connections have a monthly fixed

cost which permits a limited amount of data

uploads/downloads, beyond which the connection

incurs a significantly higher per-unit cost. There may

be backhaul links in the mango network which do

not utilize the monthly usage quota. Therefore, one

natural option to reduce the cost of a fat pipe to the

content server is to cache or place content on the dis-

tributed network of mango hotspots, and when

required, to serve it from another hotspot which has

spare backhaul capacity, as shown in Figure 7.

Although content caching has been studied exten-

sively for minimizing latency and maximizing avail-

able bandwidth [2, 18], we believe that the limited

monthly transfer capacities on the hotspots pose a

novel and practical problem formulation very differ-

ent from existing literature. To summarize: Given a

set of current and future user demands, limited stor-

age, and monthly backhaul link capacities at mango

hotspots, we are posed with an optimization problem

to find efficient content-routing algorithms that will

minimize the content delivery costs.

We will now summarize our findings along this

research direction. Along the way, we will describe

our assumptions and attempt to formalize the result-

ing optimization problem.

First, we make the observation that a user’s con-

tent access pattern at the mango hotspots will consist of

primarily visiting popular video/image sites such as TV

episodes or watching newly-popular user-generated

content on YouTube* or Flickr. In general, we believe

that there will be a strong predictive element to the

mango cells: low-capacity,inexpensive links

Content server: fat butexpensive network link

Figure 7.Sourcing content from a distributed network of caches.


popularly-requested items in the system, and mango

is designed to exploit this opportunity. Based on

parameters such as usage statistics at each hotspot,

the sharing and mobility patterns of users, and the

popularity of content items, over a time frame

referred to as an epoch, the mango server periodically

predicts the demand at each hotspot. Based on these

predictions, the mango server then places the content

at the hotspots and redirects requests for content items

to the appropriate hotspots or to the content server.

Although the prediction of demand at hotspots is an

important area of research, it is beyond the scope and

goal of our current direction of research. Therefore,

we simply assume that the prediction model is given

to us as an input.

We are now in a position to formally define the

problem. Our system consists of n mango hotspots

C � {C1, C2 . . . Cn} with C0 being the mango server.

For each hotspot Ci, as well as the mango server, let

ui and di specify the limit on data that can be

uploaded/downloaded from that hotspot free of cost.

For any data transfer beyond the limits, let ai and bi

denote the price per byte paid by the hotspot (and

the server) for exceeding upload and download lim-

its. Let si denote the amount of storage at each

hotspot.

We assume the knowledge of a set of m content

items O � {o1, o2 . . . om} that will be requested at the

hotspots over an epoch. The mango server makes

the prediction of the aggregated number of requests rik

of object ok at hotspot Ci.

For each hotspot Ci, let ui and di denote the

amount data that has been uploaded and downloaded

respectively. Any further request for item ok will incur

cost zero, if served locally. Otherwise the item will be

fetched from another hotspot Cj (or the mango

server), which will increase both, di and uj by the size

of ok. When all the requests are served, a hotspot Ci

incurs a cost of max{di � di, 0}bi � max{ui � ui, 0}ai.

Therefore, the overall cost of content delivery is

thus max{di � di, 0}bi � max{ui � ui, 0}ai and we

would like to minimize this cost.

We will now proceed to formulate an integer pro-

gram for the cost optimization problem. Before that,

we will make some observations that will simplify the

an

i�0

structure of the problem. Observe that the cost of the

data placement can be conceptually broken into two

parts—the cost of putting the desired items into the

hotspots from the server and the cost of serving

the requests at the hotspots. Therefore, to have a suc-

cessful data placement strategy, we need to minimize

the cost of both of these components. We will cap-

ture it in the integer programming formulation. Also

observe that in our setting, the mango server doesn’t

download anything—therefore, the values d0 and b0

do not play any role. Further, in a typical deployment

of mango, the server has a high data rate that is

bought in bulk from the service provider and hence

typically has a much lower per-byte transmission cost

compared to that of the hotspots. This essentially

means a0 � ai. As a consequence, if a hotspot’s upload

limit is reached, instead of further using its backhaul

link (for serving other hotspots), it is cheaper to

retrieve content from the server.

Further, it is easy to verify that the server’s upload

limit has no effect on the solution as we basically want

to minimize the number of requests going to the

server. For ease of exposition, we assume u0 to be zero.

It is easy to extend our approach to u0 � 0. We also

assume that objects are of unit size, without loss of

generalization.

Yet another assumption that we make relates to ui

and si at each hotspot. The system has some flexibility

with the storage space that can be utilized for coop-

erative caching at each hotspot, whereas the upload

limit of a hotspot is regulated by the broadband plan

at each node, and this determines the amount of data

that can be served by a particular hotspot to other

nodes. In our system, typically, si � ui, with the addi-

tional storage quantity to be used for serving repeti-

tive local requests. Intuitively, it makes sense to set

aside additional storage for hotspots which have

higher upload limits in order to facilitate cooperative

caching. In this work, we make the design decision to

assign storage proportional to upload limits, i.e., we

assume, si ∞ ui, and ui/si � t, where t (�1) is constant

across all hotspots of the system.

Based on the above discussion, our caching

problem can be formulated as the following integer

program.


Minimize

s.t.

Here yik denotes that the object ok is stored at

hotspot Ci and xijk is the number of requests for object

ok at hotspot Cj that are served from hotspot Ci. The

first two constraints express upload and storage limits.

The third constraint specifies that all the requests must

be satisfied, while the fourth makes sure that data is

only served from a hotspot that stores it.

The cost function has three terms; the first is sim-

ply the cost of serving all the requests from C0, the

mango server. The second term is the cost paid by

the caches when their data download crosses the

respective limits. The last term corresponds to the cost

of placing the objects from the server at the respective

hotspots.

We have proven that the integer program is NP-

hard. Below we briefly state our result through the

following theorem.

Theorem. For any given � � 0, there is an algo-

rithm that finds a solution to the integer program with

cost at most 16(1 � �) times the optimum cost and

requires (5si � 2) units of storage and (8ui � 4t) units

of storage at hotspot Ci.

In summary, we have devised an efficient algo-

rithm that can be used for mango hotspots to coopera-

tively cache and serve content, thus reducing the

operational costs of the system. Bell Labs simulations

have demonstrated that such a system can result in

about a 55 percent reduction in serving costs at the

central server.

yik � 50, 16, xijk � Z� h 506�i, j � C; �k � O0 � xijk � rjkyik

�j � C; �k � Oai

xijk � rjk

�i � Cak

yik � si

�i � Caj,k:i j

xijk � ui

aj,k

a0x0jk � aj

bj max e0, a ai,k:i j

xijkb � djf� ai,k

a0 yik

Securing Transactions and ContentHotspots installed in public locations like shops

and cafes are vulnerable to attacks. Previous work has

studied how to secure and authenticate public kiosks

[7, 16]. In the mango system, hotspots are crucial

intermediaries for both transactions as well as con-

tent delivery, with the handsets being the end points.

A user authenticates and is associated with the system

through the hotspot, and payments for all content

downloads, purchases of applications, and any other

services will be routed through the hotspot. Moreover,

since we envision mango as an open architecture—

content can be added and distributed locally by the

hotspot administrator—access to the hotspot has to

be carefully designed.

Securing the mango hotspots involves 1) securing

licensed content on the hotspots, 2) ensuring trans-

actions cannot be eavesdropped upon or user infor-

mation stolen, and 3) developing a framework in

which various applications with different access con-

trols can be sandboxed from each other.

Opportunistic Social NetworkingUsers naturally gather at the mango hotspots for

their content needs. For the duration of their stay

near the hotspot (a situation that we call an “oppor-

tunistic contact”), they share a common context that

can be used to encourage various social engagements.

Some examples of such engagements are a social

jukebox service that allows people to collaboratively

play media at a public TV/speaker system at a cafe,

or a recommendation service that connects people

with similar interests present at the same hotspot. The

mango system also enables us to study the structure of

such opportunistic contacts among individuals. These

interactions can be viewed as giving rise to a unique

opportunistic social network where the friendship

links (opportunistic contacts) among the users are

transient, since they appear and disappear frequently

(over a few minutes or hours), unlike the links in

social network that are almost never deleted. It would

be exciting to understand how such an opportunistic

social network affects the structure of the overall social

network.

The presence of mango users together in the same

hotspot can be utilized to: 1) provide opportunities


for social engagements and friend recommendations,

and 2) study such opportunistic contact patterns to

understand how they can compliment and contribute

to the structure of social networks.

Related WorkSeveral research projects have proposed kiosks

for information dissemination in rural areas [1, 14,

15, 17]. Their focus has been on creating novel multi-

model interfaces, inexpensive kiosk platforms, low-

bandwidth services, or highly delay-tolerant

mechanical backhauls. As far as we know, mango is

the first project to focus on quasi-real time, scalable,

and low-cost delivery of very large amounts of rich

personalized content to and from users’ handsets.

Several projects [3, 5, 6, 9, 11, 13] have also

investigated issues emerging from serving content

through a network of short-range hotspots. Perhaps

because the common use case considered is to pro-

vide opportunistic Internet access from within moving

vehicles, the primary focus of such work has been on

the performance of the wireless link between the user

and the hotspots. In the mango service, however,

users voluntarily visit and associate with a hotspot

and are willing to spend some time waiting to trans-

fer content.

Therefore, enhancing the performance of the last

wireless hop and issues around maintaining end-to-

end connectivity are less important.

ConclusionsWe believe that the small-cell, content-synch-up

architecture employed by mango will find applica-

tions in scenarios other than the obvious one of serv-

ing content through kiosks and other phones. A

natural extension is serving content along train tracks,

at train stations, or highway stops. Our innovations

and experiences with respect to prefetching and

caching content onto a distributed network of

hotspots, and serving users opportunistically, will be

very useful in such scenarios.

Moving forward, the design and logic of a mango

hotspot can transition into a femtocell or picocell

architecture, so that the pico/femto base stations will

no longer be used just for access, but can manage and

incentivize downloads through the base station to

reduce content delivery costs overall. Apart from sup-

porting content delivery, such small cells have another

piece of vital information: the proof-of-presence of a

user in a location. This information can be used for

a plethora of innovative applications: social networks

created opportunistically in an airport lounge, intelli-

gent location-based ad delivery, and so on.

In summary, intelligent services designed over

hotspots and small cells have great promise to enable

the deployment of rich and novel services scalably

and at low cost, thus introducing the vast multitudes

of mobile users in emerging markets to rich content

services.

*TrademarksBluetooth is a registered trademark of Bluetooth SIG,

Inc.Flickr is a registered trademark of Yahoo! Inc.Intel Atom is a trademark of Intel Corporation.Java is a registered trademark of Sun Microsystems Inc.Linux is a registered trademark of Linus Torvalds Picasa and YouTube are registered trademarks of Google,

Inc.Wi-Fi is a registered trademark of the Wi-Fi Alliance

Corporation

References[1] S. Agarwal, A. Kumar, A. A. Nanavati, and

N. Rajput, “VoiKiosk: Increasing Reachability ofKiosks in Developing Regions,” Proc. 17thInternat. World Wide Web Conf. (WWW ‘08)(Beijing, Chn., 2008), pp. 1123–1124.

[2] I. D. Baev and R. Rajaraman, “ApproximationAlgorithms for Data Placement in ArbitraryNetworks,” Proc. 12th Annual ACM-SIAMSymp. on Discrete Algorithms (SODA ‘01)(Washington, DC, 2001), pp. 661–670.

[3] A. Balasubramanian, R. Mahajan, A. Venkataramani, B. N. Levine, and J. Zahorjan,“Interactive WiFi Connectivity for MovingVehicles,” Proc. ACM SIGCOMM Conf. on DataCommun. (SIGCOMM ‘08) (Seattle, WA,2008), pp. 427–438.

[4] R. Bhatia, G. Narlikar, I. Rimac, and A. Beck,“UNAP: User-Centric Network-Aware Push forMobile Content Delivery,” Proc. 28th IEEEInternat. Conf. on Comput. Commun.(INFOCOM ‘09) (Rio de Janeiro, Bra., 2009),pp. 2034–2042.

[5] V. Bychkovsky, B. Hull, A. Miu, H. Balakrishnan, and S. Madden, “AMeasurement Study of Vehicular InternetAccess Using In Situ Wi-Fi Networks,” Proc.


12th Annual Internat. Conf. on MobileComput. and Networking (MobiCom ‘06) (Los Angeles, CA, 2006), pp. 50–61.

[6] R. H. Frenkiel, B. R. Badrinath, J. Borràs, andR. D. Yates, “The Infostations Challenge:Balancing Cost and Ubiquity in DeliveringWireless Data,” IEEE Personal Commun., 7:2(2000), 66–71.

[7] S. Garriss, R. Cáceres, S. Berger, R. Sailer, L. van Doorn, and X. Zhang., “Trustworthy andPersonalized Computing on Public Kiosks,”Proc. 6th Internat. Conf. on Mobile Syst.,Applications, and Services (MobiSys ‘08)(Breckenridge, CO, 2008), pp. 199–210.

[8] M. C. González, C. A. Hidalgo, and A.-L.Barabási, “Understanding Individual HumanMobility Patterns,” Nature, 453:7196 (2008),779–782.

[9] D. Hadaller, S. Keshav, T. Brecht, and S. Agarwal, “Vehicular OpportunisticCommunication Under the Microscope,” Proc.5th Internat. Conf. on Mobile Syst.,Applications, and Services (MobiSys ‘07) (San Juan, PRI, 2007), pp. 206–219.

[10] A. Jain, S. Jaiswal, A. Majumder, K. V. M.Naidu, G. Narlikar, N. Shrivastava, and V. Poosala, “mango: Low-Cost, ScalableDelivery of Rich Content on Mobiles,” Proc. 1stACM Workshop on Networking, Syst., andApplications for Mobile Handhelds (MobiHeld ‘09) (Barcelona, Esp., 2009), pp. 73–74.

[11] J. Ott and D. Kutscher, “Drive-Thru Internet:IEEE 802.11b for ‘Automobile’ Users,” Proc.23rd IEEE Internat. Conf. on Comput.Commun. (INFOCOM ‘04) (Hong Kong, Chn.,2004), pp. 362–373.

[12] Pyramid Research, Communications Marketsin India, Country Intelligence Report, 2007.

[13] J. Scott, P. Hui, J. Crowcroft, and C. Diot,“Haggle: A Networking Architecture DesignedAround Mobile Users,” Proc. 3rd Annual Conf.on Wireless On-Demand Network Syst. andServices (IFIP WONS ‘06) (Les Ménuires, Fra.,2006).

[14] A. Seth, D. Kroeker, M. Zaharia, S. Guo, and S. Keshav, “Low-Cost Communication for RuralInternet Kiosks Using Mechanical Backhaul,”Proc. 12th Annual Internat. Conf. on MobileComput. and Networking (MobiCom ‘06) (LosAngeles, CA, 2006), pp. 334–345.

[15] H. Slay, P. Wentworth, and J. Locke, “BingBee,An Information Kiosk for Social Enablement in

Marginalized Communities,” Proc. Annual Res. Conf. of the South African Inst. ofComput. Scientists and Inform. Technol.(SAICSIT ‘06) (Somerset West, ZAF, 2006), pp. 107–116.

[16] S. Ur Rahman, U. Hengartner, U. Ismail, and S. Keshav, “Practical Security for Rural Internet Kiosks,” Proc. 2nd ACM SIGCOMMWorkshop on Networked Syst. for DevelopingRegions (NSDR ‘08) (Seattle, WA, 2008), pp. 13–18.

[17] R. Y. Wang, S. Sobti, N. Garg, E. Ziskind, J. Lai,and A. Krishnamurthy, “Turning the PostalSystem into a Generic Digital CommunicationMechanism,” Proc. ACM SIGCOMM Conf. onComput. Commun. (SIGCOMM ‘04) (Portland,OR, 2004), pp. 159–166.

[18] A. Wolman, G. M. Voelker, N. Sharma, N. Cardwell, A. Karlin, and H. M. Levy, “Onthe Scale and Performance of Cooperative WebProxy Caching,” Proc. 17th ACM Symp. onOperating Syst. Principles (SOSP ‘99)(Charleston, SC, 1999), pp. 16–31.

(Manuscript approved August 2010)

SHARAD JAISWAL is a technical manager in the Alcatel-Lucent Bell Labs ApplicationsResearch Domain in Bangalore, India. Hereceived a B.E. in computer science andengineering from Regional EngineeringCollege (now the National Institute of

Technology) in Trichy, India, an M.S. in computersystems engineering from Boston University, and aPh.D. in computer science from the University ofMassachusetts, Amherst. His research interests arefocused on mobile systems and applications, wirelessnetworks, and network performance measurementsand modeling. For the past few years, Dr. Jaiswal hasfocused on building novel systems and applicationsdesigned for emerging markets.

ANIRBAN MAJUMDER is a researcher in the Bell Labs Applications Research Domain in Bangalore,India. He has a degree from the IndianInstitute of Technology (IIT) in Kanpur,India. He has worked on several projectsrelated to mobile application development

and content distribution networks. His research interestlies in algorithm design and datamining on socialnetworks and CDNs.


NAIDU K.V.M. is a member of technical staff at Bell Labs Research India in Bangalore. Hereceived his B.Tech. degree in computerscience and engineering from the IndianInstitute of Technology, Guwahati, and hismaster’s degree in computer science and

engineering from the Indian Institute of Science,Bangalore. His research interests span the areas ofalgorithms, multimedia networking, and softwaresystems for mobile handsets.

GIRIJA NARLIKAR is a distinguished member of technical staff at Alcatel-Lucent Bell Labs inBangalore, India. She has a B.Tech. from theIndian Institute of Technology, Bombay, andan M.S. and Ph.D. from Carnegie MellonUniversity, Pittsburgh, Pennsylvania. Her

interests span a variety of areas related to wireline andwireless networking, as well as networked applications.Dr. Narlikar has worked on high-speed packetprocessing, next-generation cellular architectures,security, and mobile applications. Her current focus ison developing novel networking services andapplications for emerging markets. These include lowcost mobile content delivery, mobile crowdsourcing,and energy-efficient access networks.

VISWANATH POOSALA is the head of Alcatel-Lucent Bell Labs India, and is based in Bangalore. Inhis current role, he leads a world-class R&Dteam in delivering research breakthroughsand internal technology ventures, andhelping to grow Alcatel-Lucent’s business.

Dr. Poosala is passionate about entrepreneurship andinnovation in small and big companies. His currentfocus areas include creating novel applications andnetworking technologies, especially for the emergingmarkets. He was the founder and CTO of Geopepper,an Alcatel-Lucent venture delivering innovativelocation-based services, and is a recognized expert onthe business and technical aspects of mobileapplications, Web 2.0, and database systems. He haspublished over 20 technical papers, been granted 29patents, received the “Excellence in Innovation” awardin India in 2010, and won the Bell Labs President’s GoldAward three times. He received his B.Tech. in computerscience from IIT Madras, India, and M.S. and Ph.D.degrees from the University of Wisconsin-Madison.

NISHEETH SHRIVASTAVA is a researcher at Alcatel-Lucent Bell Labs India in Bangalore.His research focuses on content deliverynetworks, datamining on social networkgraphs, and pub/sub networks. He receivedhis B. Tech. in computer science from the

Indian Institute of Technology, Kharagpur, andcompleted his Ph.D. in computer science fromUniversity of California at Santa Barbara. His Ph.D.focused on the areas of information processing in datastream and sensor network models.

ANKUR JAIN received his B.Tech. in computer science and engineering from IIT Delhi, and workedfor Alcatel-Lucent Bell Labs for four yearsbefore moving to a startup called BoltellInfoMedia Pvt. Ltd. He is currentlydeveloping applications and content for the

travel industry. He has a significant amount ofexperience in mobile application development, hasdeveloped applications and drivers for mobile phones,and has also worked with technologies such as Wi-Fimesh networks and IPTV. ◆

mango: low-cost, scalable delivery of rich content on mobile devices

Documents