Next-Generation Applications on Cellular Networks: Trends, Challenges, and Solutions

INV ITEDP A P E R

Next-Generation Applicationson Cellular Networks: Trends,Challenges, and SolutionsThis paper discusses models and innovations for applications in mobile multimedia

services, including application usage models and agile design workflows.

By Nimish Radia, Ying Zhang, Mallik Tatipamula, Senior Member IEEE, and

Vijay K. Madisetti, Fellow IEEE

ABSTRACT | Applications over cellular networks now range

from operator–consumer applications (e.g., mobile television,

voice-over-ip, video conferencing), peer-to-peer applications

(e.g., instant messaging), machine-to-machine applications

(e.g., data telemetry and automotive applications), mobile web

services (e.g., music and video streaming), and social network-

ing applications. The current approach for developing mobile

applications appears to focus on utilizing template-based

application-development kits provided by platform developers

(e.g., Google’s Android, Apple’s iOS, or Nokia’s Symbian) to

capture application designs and install them on the runtime

platforms through use of code generators tied to particular

versions of the platform. It is still unclear as to how an appli-

cation developer (or network operator) conceptualizes the

features of a mobile application in a platform-independent

way, identifies its utility and explores its impact on the user,

or further refines the choice of technology, platform, and

mobility/interactivity requirements. This paper attempts to

offer some guidelines, based on recent research in the industry

and academia in these areas, toward the design and develop-

ment of successful mobile applications that can utilize the

capabilities of the next generation of cellular networks. We

provide an overview of the growing trends of the rich multi-

media and real-time mobile applications, including the diver-

sity of application types, their impact on the enterprise and

consumer, their traffic volumes, and their load and communi-

cation patterns. In addition to the overall trend analysis, we

also study the design choices that are to be made, and how they

are realized, and also describe how the platforms (client and

server) may be implemented. Additionally, we focus on mobile

video applications according to their communication charac-

teristics and their distinct demands on the cellular network. We

also present an analysis of device and network application

programming interfaces (API) that form the basic building

blocks for efficient and secure mobile application development

of the future.

KEYWORDS | Android; mobile applications; mobile usage

models; mobile web; wireless networks

I . BACKGROUND AND INTRODUCTION

Applications developed for mobile platforms, e.g., for

iPhone’s iOS, Google’s Android, or RIM’s Blackberry, have

been the focus of intense business, market, and technical

interest in the past few years. Mobile applications, targeted

for both the consumer and the enterprise space, have been

primarily focused on migrating popular applications

already utilized by users in the wired network world to

the wireless world (i.e., smartphone or automobile). Whilea few applications, e.g., location-based applications and

services, did not have an existing counterpart in the wired

world, this set of uniquely mobile applications has consti-

tuted a smaller fraction of the universe of applications

developed for the mobile market.

The focus of the platform-basedmanufacturers has been

on developing efficient code generators for applications

Manuscript received May 16, 2011; revised September 8, 2011; accepted October 20,

2011. Date of publication February 24, 2012; date of current version March 21, 2012.

N. Radia, Y. Zhang, and M. Tatipamula are with Ericsson Research Silicon Valley,

San Jose, CA 95134-1300 USA.

V. K. Madisetti is with Georgia Institute of Technology, Atlanta, GA 30332 USA

(email: [email protected]).

Digital Object Identifier: 10.1109/JPROC.2011.2182092

Vol. 100, No. 4, April 2012 | Proceedings of the IEEE 8410018-9219/$31.00 �2012 IEEE

targeted to their platform (e.g., Android’s App Inventor).In other words, each platform developer has offered a

model or Bdesign pattern[ for developing applications

that can be ported to their platform. They have also re-

leased code generators that capture specifications of the

mobile application provided by the application developer

within design pattern/template model and generate code,

which can be installed on their platform runtime envi-

ronment over-the-air (OTA) or through a wired interface(i.e., USB).

A. MVC or PAC?The model-view-controller (MVC) model or design

pattern (see Fig. 1) has been used widely in the mobile

application software development community, wherein,

the model encapsulates the functional data and the under-

lying logic (application code), while the controller cap-tures the input from the user and updates the model,

which then updates the view to present the results to the

user. Since the view and the controller are coupled closely,

together representing an interface to the user on one side,

and to the functional application (model) on the other

side, the application developer often finds it difficult to

capture his or her specification effectively within the MVC

model in a manner that can support multiple platforms in aplatform-independent manner. In mobile applications,

multimodal inputs (in addition to user inputs, such as

keyboard and touch events) include various sensors (i.e.,

global positioning system (GPS) or accelerometer), further

adding to the complexity of writing code for the controller

and the view [1].

The presentation–abstraction–controller transformer/gateway (PAC-TG) model (see Fig. 1) provides an alterna-

tive to the MVC for the development of more platform-

independent representations of a mobile application. The

controller provides a link between the abstraction

(model) and the presentation components. Various trans-

formers and transcoders support customization of the

interface to certain target platforms, while protocol gate-

ways allow easy integration of various types of commu-nication interfaces to inputs, outputs, and sensors. The

entire mobile application is composed as a collection of

components, each of which is modeled as a PAC-TG

template [2], [3].

Consequently, current application development envir-

onments, or BMobile App Builders,[ consist of an appli-

cation composer that the application developer uses to

assemble building blocks (i.e., buttons, sliders), and thedeveloper also defines how each block reacts to user input,

and the action that is taken as a result, followed by a

description of what is to be updated with respect to the

information presented to the user, and what changes are

made to the state of the model. The code generator then

maps this specification to a runtime included with the

mobile platform [4].

In this paper, we focus more on how next-generationmobile applications may be designed to suit specific needs

within the enterprise and consumer arenas, and how the

wireless network, mobility requirements, and business

processes (and standards) are driving mobile application

development, as opposed to focusing on platform-specific

code generation technologies.

Fig. 1. Two design patterns: MVC and PAC.

Radia et al. : Next-Generation Applications on Cellular Networks: Trends, Challenges, and Solutions

842 Proceedings of the IEEE | Vol. 100, No. 4, April 2012

B. What Makes a Mobile Application Successful?A succinct description of a modern enterprise is de-

fined by its six main functional activities: 1) inbound lo-

gistics and supply chain; 2) outbound logistics and supply

chain; 3) sales and marketing; 4) services; 5) operations;

and 6) relationships. These six functional activities are

supported by a secondary functional set that includes:

1) infrastructure; 2) human resources (including social

networks); 3) product development and technology;4) management; and 5) procurement [6], [7].

Successful enterprise mobile applications are likely

to be those that allow their customers to gain signifi-

cantly when measured in the context of the following

metrics:

1) Business transformation: Business transformation is

achieved by automation of tasks, sharing and net-

working of information and people, transforma-tion of processes and relationships, and creating

new revenue opportunities.

2) Efficiency: Efficiency is obtained through produc-

tivity gains and cost reduction, primarily through

process automation and information sharing. The

ability to perform independent decisions based on

high available information is also based on

adoption of a mobile approach to architecting anorganization.

3) Effectiveness: Effectiveness is a subjective term and

is related to a perception of improved realization

of business objectives and goals.

Similarly, in the consumer context, successful mobile

applications are those that can positively impact interre-

lated areas of life and work, including 1) productivity (e.g.,

Bon-the-go e-mail,[ cloud-based documents, travel-basedservices); 2) utility services (e.g., navigation, communi-

cations, alerts, expense, and bill management); 3) enter-

tainment (e.g., games, music, video, TV); 4) information

gathering (e.g., web browsing); and 5) social networks.

The success of a mobile application is best judged based

on how well it performs a valuable task in terms of realiz-

ing its functionality (i.e., it is useful) and in aligning with a

business or consumer purpose or goal; how well it usestechnology to deliver high quality and good performance;

and how well it is accepted by users as being user-friendly,

secure, powerful, and satisfactory to use. Successful mo-

bile applications, such as a mobile web browser, or mobile

e-mail, are useful, deliver excellent performance, and are

easy to use, while providing a relatively secure model for

usage.

C. Choosing the Interactivity Features fora Mobile Application

Next-generation mobile application developers have to

choose the right features for interactivity between users

themselves, and between users and resources (data, infor-

mation, etc.). Examples of such interactivity and control

choices include the following [7].

Structuring mobile interactions: Mobile communi-cations can be treated as either mediated or situated. Amediated interaction allows communication between any

two points with a certain spatial location and/or time, as in

transactions at a bank with its customer, that can be

handled during normal hours locally and during after-

hours through a call center, while a situated commu-

nication requires support for a certain location in space

and time.Control style: The requirement whether control over

the organization or user’s activities is centralized or distri-buted has to be integrated into the mobility and mobile

application strategy from early on in the design. For in-

stance, a call center that supports mobile taxis is operated

via centralized control, while a network of healthcare pro-

viders in a chain of hospitals may operate in an autono-

mous manner, resulting in the change of the mobileapplication specifications.

Collaboration style: The requirement that workers

work in a team or as individuals has to also be integrated

early on into the design of the mobility application strategy

of the corporation. Ability to do individual work or col-

lective work or both has significant implications on the

information sharing, interactivity, and connectivity models

for the mobile application suite.Communications style: The requirement that each

communication event be either a transaction (with no

memory of previous communications, or stateless) or a

relationship (has memory of previous communications,

e.g., is state-full) is another important factor that must

be included in the mobile application design strategy by

the enterprise.

D. Technology Requirements for Mobile ApplicationsMobile applications, once their functional scope has

been identified, are then designed according to their tech-

nology requirements, as follows [8].

1) Connectivity requirements: The choices for connec-tivity span: online, online-on-demand, online-

when-available, and offline. Certain applications,

such as Skype, may have to be continuously con-nected to be useful, while other applications, such

as Stock Quotes, could connect on demand. Mo-

bile applications relating to cataloging inventory

may have to be able to download updates when

connectivity is available. Other applications, such

as consumer games, may be able to function on the

mobile device without any requirement for

connectivity for a long period of time.2) Access requirements: The choices span: read, write/

create, update, or alert. Certain mobile applica-

tions may operate only as consumers of data,

while others can be consumers and producers of

data, while others only require an alert as to when

selected information is available in the cloud or if

the information has been changed.

Radia et al.: Next-Generation Applications on Cellular Networks: Trends, Challenges, and Solutions

Vol. 100, No. 4, April 2012 | Proceedings of the IEEE 843

3) Content type: The choices for content span:corporate/structured or unstructured (multi-

media). Access to certain types of content at the

enterprise (e.g., payroll or sales data) may require

standardized connectors following database ap-

plication programming interfaces (APIs), while

access to unstructured data, such as music, could

utilize standard streaming protocols for use.

4) Data size: The choice depends on where the appli-cation utilizes a large or small database. If mobile

applications need access to a lot of data, they may

be better structured in the form of a client utiliz-

ing a cloud-based server, as opposed to having all

data stored locally, given the limited resources

available on the device.

5) Location information: Many popular mobile appli-

cations, e.g., local search, benefit from havinglocation information available.

6) Device management requirements: a) synchroniza-tion requirements; b) partitioning requirements

(business/personal); c) user roles assignment

and policies; d) backup and security features; and

e) loss and theft prevention.

E. Impact of Operators on Mobile ApplicationsSo far we discussed the design considerations for

different mobile applications. On the one hand, diverse

classes of applications generate different load on the net-work, and the network condition and the computation/

storage characteristics of devices influence the perceived

quality and usage of mobile application. The authors have

studied the changing behavior of users and the type of

applications as a function of their operator data plan and

their platform as shown in Fig. 2.

Fig. 2 shows the breakdown of different applications as

well as their absolute usage volume with an increasingsubscriber data plan quotas. Each data plan is associated

with a given monthly limit of maximum bandwidth

consumption value shown in the x-axis.Interestingly, we observe that not only the traffic vol-

ume increases, but also the distribution changes among

four types of applications. When the data limit is 2 GB,

web browsing is the most dominant mobile application.

When the limit increases to 5 and 10 GB, online media

(audio, video) become more and more dominant. Such

knowledge can enhance more intelligent resource provi-

sioning by network operators, enhancing user satisfaction

and increasing revenues.Besides the impact from the network, the user equip-

ment has more direct impact on the pattern of how user

uses mobile applications. Fig. 3 presents different appli-

cation usage distribution by platform type based on mea-

surements from one week of data collected from Gateway

GPRS Support Node interfaces from a major European

ISP. One observes that users on laptops or personal

computers (PCs) using mobile network data access cardsconsume most of the bandwidth, since this platform

(including display size) is user-friendly and preferable

from the viewpoint of both battery life and computational

capability. The most dominant application on a mobile

PC, or a tablet in the near future, is web browsing. On the

other hand, on HTC Nexus One, which targets the

consumer smartphone market, the dominant application

is in the use of social networks. For a Blackberry-typedevice, the dominant application is e-mail, as it is mainly

used for business and enterprise users.

II . DESIGN GUIDELINES FORMOBILE APPLICATIONS

Mobile applications, by definition, are utilized in challeng-

ing and changing user environments. The user (whether

enterprise or consumer) is unable to provide full attention

to the device (e.g., while walking), uses the applications in

many different contexts and scenarios (in a corporatemeeting or during a flight), the user may not be able to

utilize hands completely in utilizing the features of the

application and the device (e.g., driving while using the

application), and there may be multiple distractions and

interferences during mobile tasks. Extensive research has

categorized these guidelines into three broad classes [6],

[7], discussed next.Fig. 2. Change in user behavior with size of data plan.

Fig. 3. Change in user behavior with platform type.



A. General UI Guidelines for Mobile ApplicationsA general set of guidelines has been developed for user

interface (UI) design in mobile applications. Mobile

applications should 1) provide shortcuts for experienced

users and wizards for new users; 2) provide feedback

(haptic, audio, visual, etc.) constantly to keep the user

engaged and attentive; 3) create good dialogs by creating

predictable and intuitive sequences of interaction with the

application; 4) allow to maintain control by having theability to control the application (or abort it) at any point;

5) create a consistent look and feel of the application

across multiple platforms (e.g., desktop and mobile);

6) attempt to reduce the number of errors in usage through

careful error checking dialogs that allow confirmation and

reversal of steps; and 7) minimize dependence on user’s

memory through grouping information in Bchunks[ at a

time, limiting the need for scrolling.

B. Mobility GuidelinesSpecific mobility guidelines for mobile applications

include 1) creating designs suitable for multiple contexts

(home, business, travel, etc.) including support for run-

time adaptation of the application; 2) allowing for mul-

timodal interactions with the device; 3) allowing for

convenient use with the ability to handle multiple andfrequent interruptions with limited attention from the

user; 4) designing for speed of operation so that requests to

respond are speedy and compact; 5) presenting informa-

tion in a hierarchical form, allowing top–down interac-

tion; 6) allowing ability to personalize the application to

suit the user; 7) providing an ability to synchronize the

application with desktop and cloud data stores; 8) design-

ing with built-in security at device, application, and sys-tem levels; and 9) allowing privacy for single or multiple

users.

C. Organizational GuidelinesCorporation and enterprise-specific guidelines for mo-

bile applications include 1) consistency with the organi-

zation’s standards and systems; 2) support for business

models and strategies of the organization; and 3) linkageof mobility-related technology to the existing tasks and

social structures within the organization to encourage

adoption.

III . MOBILE AND SERVERPLATFORM ARCHITECTURES

Mobile application models are supported on mobile andserver platforms, and it is important not only to under-

stand how mobile platforms have evolved, but also the

increasing role that networking and communication

resources on the network side, and increasing adaptation

on the server side, are contributing to the design, building,

test, and usage of advanced mobile applications of the

future [10].

A. Mobile Platform Architectural EvolutionMobile platforms are characterized by increasing

capabilities and functionalities in the following areas of

technology.

1) Communication and networking architecture: The

data and voice communication platforms increas-

ingly tend to move toward an all-IP model with

multimegabit upload and download data rates,

with multiple simultaneous communicationpipesVfourth generation (4G) for cellular links,

WiFi links for the local area network (LAN) con-

nectivity, and short-range personal area networks

(PANs) for creating networks with local devices

embedded in most electronics systems. The smart

mobile platform of the future is expected to inter-

act closely with land-based televisions; set-top

boxes; video game consoles; automotive plat-forms; travel, airport, and hotel kiosks; supermar-

ket checkout registers; and business systems (e.g.,

payment and shopping), both in the online world

and in the real world. The current usage model,

where most mobile platforms can integrate with

automobile audio systems, will be extended to in-

clude its integration into other electronics systems

that the consumer typically interacts with, includ-ing PCs, laptops, TVs, and a wide variety of pay-

ment systems, located in shopping malls,

groceries, and at colleges or at the workplace.

2) Data and content storage architecture: Local storageon the mobile platform is increasing, being aug-

mented by cloud-based storage that provides prac-

tically unlimited capacity that can be downloaded

on demand, either in a batch mode or in a stream-ing mode of access. Many of these storage and

synchronization options are based on a subscrip-

tion model, both for storage and also for content,

and ensure that the mobile consumer of appli-

cation sees the same Bcloud-top[ view of their

contentVentertainment, data, or applications,

irrespective of which mobile platform they are

currently using (e.g., a smartphone, a tablet, or alaptop computer). The smart mobile platform may

encapsulate most of the features of a set-top box, a

DVR that supports time shifting, a television, and

a game console, in addition to its usual usage in

communications and productivity support.

3) User and platform inputs: The user interface is

driven by the keyboard, touch screens, motion of

the device itself, to capture the user-driven input,while GPS, multiple high-resolution cameras,

proximity sensors, accelerometers, and gyro-

scopes provide the additional contextual inputs

needed to drive an immersive mobile experience,

that is, capability of augmenting the content and

application view with personalized layers of addi-

tional information of interest to the consumer.



Advanced image processing to directly acceptgestures and environmental inputs from the user,

e.g., as in Microsoft’s Kinect, is also expected to

become mainstream.

4) The platform outputs: High-quality audio and vi-

deo, coupled with advanced video displays, capable

of rendering video in high-definition (HD) for-

mats, have become mainstream, and when com-

bined with the ability to drive multiple screens(e.g., TV or automobile video), provide a truly

mobile environment for the streamed entertain-

ment (mobile TV) from traditional providers and

ensure a high-quality game or application (including

3-D visualization and graphics acceleration) expe-

rience while in a standalone mode of operations.

5) Advanced application usage models: Advanced mod-

els for applications include peer-to-peer models(e.g., video conferencing), star-based social net-

working models, and collaborative models (i.e.,

multiplayer video games across the network or in

a distance-based learning environment), in addi-

tion to the more traditional models where the

mobile platform serves as a mobile substitute for

desktop-based usage of consumer and enterprise

applications. Virtualization of applications to sup-port cloud-based functionality and data storage

while retaining only the user interface compo-

nents on the mobile device is likely to be the pre-

ferred model for deployment.

6) Device content and application management: Bothoperator and mobile platform vendor supported

platforms that serve as a marketplace and distri-

buting point for mobile applications to the device,as well as device management servers that can

apply corporate and business policies to a fleet of

corporate devices, have become common place.

Changes seen in the future include the ability to

emulate multiple mobile platforms (e.g., Android

emulating an iPhone or a Blackberry platform)

and cloud-based deployment and control of appli-

cations that run on multiple platforms, throughlocal adaption layers).

B. Mobile Application Usage ModelsThe industry has converged on four major models for

mobile applications in terms of their usage [10].

1) Mobile web content browsing: Primarily for con-

suming rich online and/or live content from the

web via a mobile platform, with a limited amountof client side processing and storage

2) Mobile web application: Applications running on

the mobile platform that consume content as well

as do a considerable amount of client-side process-

ing and data storage.

3) Mobile widgets: Widgets provide views of applica-

tions that are capable of independently running on

themobile platform, and can also be executed insidea browser, enhancing portability across multiple

platforms.

4) Standalone mobile applications: Independent ap-

plications running independently on the mobile

platform, but which are capable of accessing and

aggregating data and content from the web. It is

similar to the Android and Apple models for ap-

plications (Bthere is an app for that![).

IV. RUNTIME PLATFORMS FORMOBILE APPLICATIONS

Our view of the runtime software architecture of the

mobile application as deployed on the mobile device/client

and on the mobile application server is shown in Figs. 4

and 5 for the mobile and server side of the deployment.

A. Device-Side Mobile Application ArchitectureThe device-side mobile application architecture con-

sists of the following components.

1) Device content flow control endpoint: This module is

responsible for managing rich media content flow

to and from the client device.

2) Device signaling flow control endpoint: It is respon-sible for setting up sessions and associated flow con-

trol [including quality of service (QoS)] related to

connectionmanagement for rich content (i.e., multi-

media streaming or multiway video conferencing).

3) Client-side adaptation engine: It adapts web contentfor optimal use by the client platform.

4) Renderer: Processing engine to drive display

efficiently.5) Client-side application processing: Client-side appli-

cation engine to perform local processing, either

to implement local functionality of the application

or to supplement network-based functionality.

6) Client-side data content storage: Client-side access

to local and cloud-based/network storage.

7) System utilities: Utilities for ensuring effective

application performance include application datamanager, security manager, user awareness man-

ager, resource manager, experience manager, and

delivery context manager.

B. Server-Side Mobile Application ArchitectureThe server-side mobile application architecture con-

sists of the following components.

1) Server-side adaption engine: It allows server toadapt responses to suit requests from a variety of

mobile clients, based on adaption rules.

2) Server application: It performs server-side pro-

cessing on behalf of the mobile application,

offloading processing from the client.

3) Content and signaling flow control endpoint: It pro-vides support for media and signaling flow for rich



multimedia content across the network to and

from the clients.

It is expected that the server side also has system

utilities for security, resource management, and ensur-

ing QoS.

C. Mobile Application Support UtilitiesThe mobile application, on the client side, is supported

by advanced system utilities as noted below.

The application data manager: It supports the mobile

application through personalization cookies, client-side

storage APIs, and provides improved offline access via

client data replication.

Security manager: It filters execution of unsecured

data and also parsers data to support various security

filters.User awareness manager: It supports partitioning of

private and business data, and also provides data managers

and digital rights management services. It also provides

networking support for client platform with its environ-

ment (including automotive and consumer electronics

devices).

Fig. 5. Server-side model for a mobile application platform.

Fig. 4. Device-side model for a mobile application platform.



Resource manager: It provides a number of utilitiesthat optimize resource usage on the mobile platform, in-

cluding content compression, memory optimization for

applications, and minimal use of local resources through

aggregating and caching data.

User experience manager (UEM): It provides utilitiesthat maximize user experience satisfaction, including re-

ducing latency for offline startup and improving perceived

latency through incremental rendering and user status up-dates. The UEM also provides support for multiple inter-

action models, including focus-based, pointer-based, and

touch-based models of user interaction. The UEM will also

provide APIs to initiate web communications through

features such as Bclick-to-call,[ over-the-air (OTA) device

management, short message services (SMSs), and phone. In

addition, UEM enforces thematic consistency through ap-

plication preferences, awareness of the state of the client,and the state of the application through personalization data.

Delivery context manager: It provides utilities for ad-justing content on the mobile platform, adjusting naviga-

tion and page flow to provide seamless user experience, in

addition to detecting server-side and client-side capabilities.

Advanced features and utilities: It includes support formobile platform profiles (e.g., learning profile, communica-

tion profile, entertainment profile, utility profile) that areused and driven by typical user cases. For instance, in the

entertainment profile, the platform is optimized for video

reception (e.g., video streaming) and multiplayer game

playing with accelerated graphics usage. New features, such

as augmented reality, advanced graphics, and game-player

models, can also be provided through these utilities.

D. Network Operations Center (NOC)Given the growth of mobile applications and subscriber

population, cellular data network of today and tomorrow

will be difficult to manage effectively unless new manage-

ment capabilities (see Fig. 6) are introduced into thenetwork operations center (NOC). As the traffic demand

increases, resource contention can exist due to unexpected

and transient traffic spikes or intentional attacks. Further-

more, application performance may be affected by the

network failures. Given a fixed amount of resource, QoS

techniques are indispensable to optimize the resource uti-

lization. Besides resource control, the network also con-

tains information such as user identity, location, mobility,and contextual information. Such subscriber-related data

can enhance operator revenues through the use of targeted

mobile advertising and provision of new services.

1) Video Application and Network Infrastructure: Internetvideo today is dominant by the low-quality, user-generated

content sites, such as YouTube(tm), which have managed to

capture millions of regular viewers. Providers of such over-the-top (OTT) video services are able to take advantage of the

rich interactivity and viewer profiling capabilities of IP

networks, without having to make heavy investments

associated with traditional telecom or cable TV.

Video content in standard video-on-demand (VoD)

systems has been historically created and published by a

limited number of resource-rich media producers, such as

licensed broadcasters and large movie and TV or cableproduction companies. Furthermore, popularity of a chan-

nel or a certain type of media offering was somewhat con-

trollable through professional marketing campaigns. The

advent of OTT video publishing has reshaped the video

market enormously. Today, hundreds of millions of Inter-

net users are self-publishing consumers. Typical length of

mobile video content has been shortened by two orders of

magnitude and so were the production time and cost. Theattention span of the typical user for a particular type of

content has been reduced to days (or even hours) as op-

posed to weeks or months in traditional news media.

Fig. 6. Network operation center as part of the mobile application platform.



One of the keys to YouTube’s success appears to be itsuse of Adobe’s Flash Video (FLV) format for video delivery.

While users may upload content in a variety of media

formats (e.g., WMV, MPEG, and AVI), YouTube converts

them to Flash Video before posting them. This enables

users to watch the videos without downloading any addi-

tional browser plug-ins provided. To enable playback of the

flash video before the content is completely downloaded,

YouTube relies on Adobe’s progressive download technol-ogy. Traditional download-and-play requires the full FLV

file to be downloaded before playback can begin. Adobe’s

progressive download feature allows the playback to begin

without downloading the entire file. This is accomplished

using ActionScript commands that supply the FLV file to

the player as it is being downloaded, enabling playback of

the partially downloaded file. Progressive download

supported video content is delivered using HTTP/TCP.From a technology viewpoint, standard video stream-

ing protocols can be used for OTT video. However, for the

ease of deployment, HTTP-based common protocols may

be applied. For example, YouTube appears to use HTTP/

TCP to buffer video into the Flash Player on the user’s PC

for wired distribution of content stored on the Google

Video’s content distribution network. However, for 3G

mobile handsets, m.youtube.com appears to use RTSP tostream video. RTSP is not always supported through

routers on the Internet, while HTTP/TCP is more widely

supported throughout the Internet. Thus, it is the most

common choice for transport protocols for OTT videos.

Today, the OTT video traffic is treated as any other IP

traffic indifferentially. However, the network provider

may have incentives to provide differentiated services to

OTT video providers given their business relationships.For instance, a network operator may partner with an OTT

provider to establish business partnership. In this case, the

OTT providers can benefit from delivering the content in a

more efficient manner with a higher guaranteed quality.Furthermore, the network providers may share a subset of

the revenue with the OTT provider, which also increases

its own network profitability. In the following, we will

elaborate on which functions of infrastructure can be

optimized for differentiated delivery of OTT video through

a multitiered delivery and pricing model for the mobile

Internet.

Generally speaking, TCP is the transport protocol fortypical Internet application protocols such as HTTP, FTP,

and SMTP. UDP appears to be the more popular transport

protocol for commercial streaming media connections.

Unlike typical Internet traffic, streaming video is sensitive

to delay and jitter, but can tolerate some data loss. In

addition, streaming video practitioners typically prefer a

steady data rate rather than the bursty data rate often

associated with window-based network protocols (e.g.,TCP). On the other hand, UDP packet losses should be

handled appropriately at the application level, reducing

the impact of loss on the quality of the video connection by

the user. For instance, the multimedia applications may

lower their bitrate in the presence of packet loss during

congestion.

Different applications have diverse requirements on

the network performance. For instance, the VoIP applica-tion is sensitive to delay and jitter, while the on-demand

video applications have high requirements on bandwidth.

Fig. 7 shows that, in general, average TCP throughput for

sampled data points on a base station correlates with the

load on the infrastructure. The x-axis is the load after nor-

malization. The figure illustrates rapid degradation in

throughput as the load increases. The figure demonstrates

vividly how the voice application is affected by thatnetwork throughput.

Fig. 8 is a direct comparison between a mobile TV

application throughput shown on z-axis in comparison

Fig. 7. Mobile application performance versus load on the operator network.



with the radio quality level, consisting of the Ec/No on

x-axis and received signal code power (RSCP) on y-axis.It is clear that the performance becomes worse (on the

bottom scale of the color bar), as the Ec/No and the

RSCP decrease. These impairments occur quickly, showing

that the application performance does not change linearlywith the network performance metrics, adding to users’

dissatisfaction with mobile application performance, if

operators do not track these sensitive metrics continuously.

V. MOBILE APPLICATIONS AND4G NETWORKS

A. QoS and Network Resource OptimizationGiven the increasing traffic demand with multiple and

often conflicting demands (e.g., delay versus bandwidth),operators need to look for new technologies to efficiently

utilize the available network resources, in particular, the

resource allocation and flow management for providing

QoS for diverse applications. Driven by business need and

technology limitations, operators have started to provide

subscriber differentiation. In some cases, there is a need

for differentiating the treatment received by different sub-

scriber groups for the same applications. These subscribergroups can be defined in any way that is suitable to the

operator, for example, corporate versus private subscri-

bers, postpaid versus prepaid subscribers, and incoming

roaming subscribers. The next-generation 4G or LTE net-

work has shifted to an all-IP flat network architecture that

has traditionally support the Bbest effort[model of service.

New mobile applications requiring real-time support and

high-speed response from the network will coexist withapplications that only require lower value best effort ser-

vices (i.e., e-mail). We now discuss how some of the QoS

considerations will play a major role in supporting the

deployment of next-generation mobile applications.

1) Resource Control Parameters in 4G Radio Access Net-work (RAN): The basic unit in cellular network for QoS

management is called bearer. A bearer uniquely identifiesflows that receive a common QoS treatment between the

terminal and the gateway. A flow is defined by a five-tuple-

based packet filter installed in the gateway by the policy

control (PCRF). The packet filters are configured both on

the UE for uplink traffic and on the 4G/LTE Gateway for

downlink traffic to determine the mapping between packet

flows and the corresponding bearer. The bearer is the basic

enabler for traffic separation, providing differentialtreatment for traffic with differing QoS requirements.

The QoS class identifier (QCI) is the parameter to

identify different classes of applications such as conversa-

tional, interactive, streaming, and background traffic

types. QCI is a scalar that is used as a reference to param-

eters that control bearer level packet forwarding behavior

in both radio and the EPC. Different network domains

have their interpretation of a particular QCI value, such asscheduling weights, admission thresholds, queue manage-

ment thresholds, and link layer protocol configuration.

QCI is a uniform scalar replacing many other parameters

in the 3G/UMTS network, e.g., transfer delay and SDU

error ratio. In the LTE/4G network, eNodeB implements

the bearer level QCI. While the bearer is established,

eNodeB first locks the resources on the air interface. Sub-

sequently, eNodeB handles the bearer traffic to enforce theresource allocation [14].

2) QoS Support in Transport: There are two principal

approaches to implement QoS in packet-switched net-

works: a) a prioritizing system, where each packet identi-

fies a desired service level, and b) a parameterized system,

based on an exchange of application requirements with the

network. The well-known examples of these two systemsare the differentiated services (DiffServ) and the integ-

rated services (IntServ) architectures.

The DiffServ architecture, defined in RFC 2475, pro-

vides QoS by handling different classes of traffic in dif-

ferent ways. To do so, edge nodes classify the flows by

assigning different classes to them, which is done by

marking packets and setting their QoS bits in the headers

accordingly. This allows the interior nodes to differentiatebetween different packets, in terms of the assigned band-

width and buffering policy, based on their classes. In IPv4,

the type of service (TOS) octet carries the DiffServ

marking. In IPv6, this information is carried in the traffic

class octet (at the MAC layer, VLAN IEEE 802.1Q and

IEEE 802.1p can be used to carry essentially the same

information).

The InterServ architecture proposes a mechanism forproviding QoS on a per-flow basis (RFC 1633). In this

architecture, applications explicitly request their service

requirements, which include traffic characteristics such as

traffic peak rate, maximum packet size, and token bucket

parameters (token rate and token bucket size). Network

resources (bandwidth and queuing resources) are then

allocated to individual applications in response to their

Fig. 8. Sensitivity of the mobile application performance to

radio channel characteristics.



requests. If enough resources exist, resource reservation ismade.

3) QoS in Evolved Packet Core: The QoS policy is con-

trolled in the packet core of the cellular network. It deter-

mines how each packet flow for each subscriber is handled

by specifying the QoS parameters to be associated with. It

issues policy and charging control (PCC) rules to the

gateway, which in turn are used to establish new bearers ormodify existing bearers. One bearer exists per combination

of QoS class and IP address of the terminal. One terminal

can have multiple IP addresses and bearers.

The PCC functionality comprises the functions of

the policy and charging enforcement function (PCEF), the

bearer binding and event reporting function (BBERF), the

policy and charging rules function (PCRF), the application

function (AF), the online charging system, the offlinecharging system, and the subscription profile repository

(SPR). The policy and charging control rule (PCC rule)

comprises the information that is required to enable the

user plane detection of the policy control and proper

charging for a service data flow. Using the information

from the AF, the PCRF defines the PCC rules and pushes it

to PCEF either dynamically in real time or statically in

advance. The PCEF module is usually implemented to-gether with the LTE gateway to carry out the PCC rules.

The efficient use of these QoS features is one of the most

challenging tasks for the network operators of the future,

in ensuring that operators be able to thrive in a market

where new models appear to include the options for un-

locking smartphones from their operators [14].

B. Operator APIs for Mobile ApplicationsIn search of new revenue increases, mobile operators

must adapt from selling voice and SMS services to a more

diversified set of services, and not just focus on the tradi-

tional retail or business subscriber. The key challenge

today is to equip operators with tools to enable simple,

commodity, and flexible data access for third parties.

Mobile network operators today have the unique advan-

tage of becoming the strategic partners and informationsuppliers to the third-party application developers. The

advantage resides in their unique position in the manage-

ment of connectivity, session, and subscriber information

at the same time. Operators have realized that to utilize

these new opportunities for wholesaling mobile data, the

business model employed by the current service providers

needs to be changed from Bunlimited[ flat-rate data ser-

vices to Bsmart-pipe[-based tiered services. Providingtiered services further stresses network functions such as

policy configuration, network enforcement, resource con-

trol, and billing integration. Various attributes can be

associated with different tiers of services, including data

caps, download speeds, overage charges, and types of

supported applications. Such parameters can be used as

key APIs to expose to third-party application providers.

Although proposals such as voice calling or IMS-basedrich media applications have been proposed as new types

of operator-managed communication services, today the

most popular applications are still OTT third-party appli-

cations, such as YouTube. Thus, the most feasible way for

operators to find new revenue streams is to partner with

third-party application providers to bundle connectivity

with high-value end-user products. The network and ser-

vice APIs are critical enablers for such business model. Theoperator-supported NOC provides a number of functions

on behalf of the mobile application and the mobile appli-

cation server, as will be described below.

Location APIs: The network gateways have functions to

deliver a core set of APIs to let developers use the ISP’s

most popular network capability, the real-time location,

and context information. For instance, AT&T provideslocation APIs to allow leverage AT&T’s location-based

services for a wide range of business applications. The

terminal’s location and the device capability information

enable the developers to retrieve device capability and

location without writing any device-specific code. It allows

location discovery for non-GPS-enabled devices. Equipped

with such knowledge, the developers can easily create

device-independent applications.

SMS APIs: The service provider today simplifies the

development of messaging applications by offering web

service APIs to enable access to SMS and MMS services.

Therefore, the development of the messaging-based appli-

cation is largely simplified. For instance, it can be built on

HTTP protocol by calling the APIs instead of using com-

plex SMPP protocol. It also simplifies the server sidecommunication, without relying on an SMPP-enabled

gateway to send/receive messages.

WAP Push APIs: The network gateways can accept HTTPPOST connections directly from web applications. Devel-

opers can use WAP Push interfaces to send messages and

alert any changes in network resource needed.

Given the personal nature of the device, its capabilities,and the content on the device, network, and cloud-based

storage, access to such APIs needs to have enforceable

security policy that is configurable by the device manu-

facturers and network providers. For instance, the network

provider can work with device manufacturers to set a po-

licy on which application can access which APIs based on

the creator of the application and its functionality. Such

policies, of course, ultimately need to be enforced in col-laboration with the userVthe owner of the device and the

application and content on the device. The enforceable

policies need to enable various access security scenarios

that use the identity of the application provider and user-

controlled permission for application access to the APIs,

e.g., once by the application, for the application session,

or always by the application.



Each mobile operating environment, in conjunctionwith the device and the network provider, provides its own

APIs and implementation of the security model. Such APIs

are inconsistent and they evolve at their own pace. To-

gether with other integration challenges, this increases the

complexity and time-to-market for mobile applications.

Wholesale application community (WAC) initiative, sup-

ported by many global carriers, represents one such effort,

toward unification of these device and platform APIs thatare expected to be utilized by the next-generation mobile

applications [10], [11], [13].

Similar to device APIs, for network-specific capabili-

ties, uniformity and consistency are provided via WAC

including GSMA OneAPI as part of its roadmap. GSMA

OneAPI provides uniform and consistent access to net-

work capabilities such as location, in-app carrier billing/

payment, messaging (SMS/MMS), voice call control, dataconnection profile, and device profiles.

C. Building Blocks of the Next-Generation Deviceand Network APIs

The functional requirements for device and network

APIs, as shown in Fig. 9, can be categorized around the

following key dimensions.

• Which application is accessing the APIs and on

whose behalf? (Identities)

• Who controls and authorizes the access and how?

(Policies)

• How is privacy of information accessed preserved?(Privacy)

In the following, we present five building blocks for the

device and network APIs: application identity, application

reputation index, network-based OpenID, device and

application privacy, and policy storage and enforcement

[10]–[12].

1) Application Identity: Access to APIs and ensuingresources are dependent on the identity of the application

accessing it and the identity of the user. For example, user

needs to know the application that wants to access its

camera, wants to turn on its audio, access the contacts

database and other personal information stored on the de-

vice, or access networked-based services such as location,

SMS, and charging. The user grants particular access to

device and network APIs based on the context of therequest and application identity.

For the device APIs, the application identity needs to

be enforced by the device runtime environment, e.g., WAC

Runtime, WebKit, Widget runtime environments, or other

device-specific operating environments. In the past, this

was achieved by operator controlling the applications that

can be deployed on a given device. However, this approach

is not scalable and feasible in the emerging device andapplication ecosystem, and much new work is needed.

One solution is to require application to be signed by

root-able digital certificates that identify a given applica-

tion. The device runtime, e.g., WAC runtime, could use

the PKI infrastructure to validate the identity of the appli-

cation and present it to the user for a user to grant access

rights to the APIs and ensue resource access.

2) Application Reputation Index (ARI): In addition to the

application identity, given the plethora of available appli-

cations, the user also needs to know the Breputation[ of

the application. For example, what is application’s reputa-

tion requesting access to her contacts? What is its overall

reputation and what is its reputation with the users she

knows and trusts? Currently, there are no such standards

for measuring the reputation of the application. An appli-cation reputation index (ARI) needs to be created for the

overall application ecosystem and/or for the specific

Fig. 9. Proposed architecture for the policy-based mobile platform/network management.



application provider domain, e.g., Apple’s AppStore orAndroid Marketplace, or other third-party provided appli-

cation market places. A Bcrowd-sourcing[-based approach

could be used to socially derive applications’ reputations.

3) Network-based OpenID: For the network APIs, the

application as well as the user identity needs to be verified

to enforce associated policies including access to informa-

tion relevant to that user or group of users. The PKI-basedsigned application approach for the device API does not

translate well when it comes to identifying application for

network APIs. Typically, an application is given a secret

from the network API provider to identify the application.

The network API also needs to identify the user. The user

identity is not the same as the device identity or the

network IP address associated with the device. Typically

the user identity is fragmented across various applicationsand network domains creating challenges for accessing

APIs across various providers. A cross-domain solution for

user identity and authentication is needed. One solution is

to use emerging technologies such as OpenID for user

identity and authentication. Such identity can be mapped

to specific user representation in a given application and

network domain to provide domain-specific, e.g., stron-

ger, form of identity and authentication. For example,user’s OpenID can be mapped to user’s identity within a

mobile network domain represented by SIM or other iden-

tities assigned to her for the usage of the network [10]–[12].

4) User, Device, and Application Privacy: Current and

future devices and networks will collect, store, and reveal a

lot more information about the user, her behavior, and

data. For example, the location information obtained fromthe device and network can reveal information about user’s

whereabouts as well as typical movement patterns of an

individual, specific groups, or population at large. The

camera and other sensors on the device capture and store a

lot more information about the user. Access to such capa-

bilities on the devices and information from them through

device and network APIs may compromise privacy concerns.

Therefore, APIs would have to involve the user in con-trolling how and by whom such information can be used.

This requires the runtime environment, e.g., a WAC run-

time, to validate the identity of the requestor and allow the

user to statically and dynamically configure the usage of

the APIs and ensue information by the requestor. Today,

this is done in an ad hoc manner and applications police

themselves, or the user has to manually manage the access

and usage. In the era of thousands of apps, a more usableand scalable solution needs to be developed. Moving for-

ward, the device runtime environment will also need to

function as the privacy agent for the users.

One solution could be an OAuth-based authorization

framework. This framework can encapsulate the APIs to

enable user and agent-based control of access to device and

network capabilities and information. Similarly, the net-

work API providers will also need to enforce the privacyrequired by the user and the local government policies and

regulations. Using OAuth, or other such de facto standardtechnology, for device as well as network APIs, would

provide consistent programming model for the application

developer and support management of privacy require-

ments and audits of the privacy enforcement.

5) Policy Storage and Enforcement: As discussed before,access to device and network APIs and privacy of the

capabilities and information accessed need to be enforced

through policies. The device and network need to imple-

ment the policies in their own contexts. As shown in

Fig. 9, device has the policy-store (PS) and policy en-

forcement point (PEP) that implement device-specific

policies for access and usage of device APIs.

Typically, PS and PEP are embedded inside a givenruntime environment, e.g., WAC runtime or Android. The

runtime environment accesses PEP when a given API is

used by the application. PEP will use policies stored in PS

to enforce the usage of the API. The policies in PS enforced

by PEP need to support multiple model, e.g., user-defined

policies, device-provider-defined policies, and network-

provider-defined policies. As the complexity and number

of applications on the device increase, it will also need tosupport delegation models, similar to how today’s desktop

antivirus software works, and will work as a privacy agent

for the users.

Similarly to the device side APIs, the network APIs

runtime environment will also need policies. As shown in

Fig. 9, similar to the device side, the network side also has

its own PS and PEP. For developer’s and user’s ease of use,

billing and charging, and other such requirements, theuser and application representation across these two policy

domain needs to be consistent and provider agnostic. This

area is also a subject of active research and development in

the industry.

VI. SUMMARY

We have provided a detailed look at the impact of mobilityon the consumer and enterprise applications, as well as the

metrics that drive their success. We have also presented

design guidelines for effective mobile applications of the

future based on recent research in the industry and aca-

demia, and have also proposed conceptual platform archi-

tectures for the device, server, and cellular network for

their efficient deployment. A detailed look at the infra-

structure issues, related to QoS, and how they drive andare driven-by application requirements and functionalities

is then presented, with a description of the challenges

faced in 4G networks. The need for standardized APIs at

the user, application, device, and network-level is empha-

sized, if operators plan to see new revenues from

nontraditional wholesale customers from their network,

and some solutions for these APIs are also presented. h



REFERENCES

[1] T. Reenskaug, Models, Views, Controller, XeroxPARC Technical Note, May 1979. [Online].Available: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf.

[2] J. Coutaz, BPAC: An implementation modelfor dialog design,[ in Proc. Interact Conf.,Stuggart, Germany, 1987, pp. 531–436.

[3] R. B’Far, Mobile Computing Principles.Cambridge, U.K.: Cambridge Univ. Press,2005.

[4] Google App Inventor, 2011. [Online]. Available:http://appinventor.googlelabs.com

[5] F. Buschmann, R. Meunier, H. Rohnert,P. Sommerlad, and M. Stal, PatternOriented Software Architecture, Vol 1:A System of Patterns. New York: Wiley,1996.

[6] R. C. Basole, Ed., Enterprise Mobility:Applications, Technologies, and Strategies,vol. 2. Amsterdam, The Netherlands:IOS Press, 2008, ser. Tennenbaum InstituteSeries on Enterprise Systems.

[7] P. Tarasewich, J. Gong, F. Nah, andD. DeWester, BMobile interaction design:Integrating individual and organizationalperspectives,[ Inf. Knowl. Syst. Manage.,vol. 7, pp. 121–144, 2008.

[8] P. Brans and R. Basole, BA comparativeanatomy of mobile enterprise applications:Toward a framework for software reuse,[ Inf.Knowl. Syst. Manage., vol. 7, pp. 145–158,2008.

[9] E. Scornavacca and S. Barnes, BThe strategicvalue of enterprise mobility,[ Inf. Knowl.Syst. Manage., vol. 7, pp. 227–241, 2008.

[10] W3C, Mobile Web Application Best Practices,W3C Recommendation, Dec. 14, 2010.[Online]. Available: http://www.w3.org/TR/mwabp/.

[11] OpenID Foundation. [Online]. Available:http://openid.net/

[12] OAuth. [Online]. Available: http://oauth.net/

[13] Wholesale Applications Community (WAC).[Online]. Available: http://www.wacapps.net/

[14] P. Beming, L. Frid, G. Gall, P. Malm,T. Noren, M. Olsson, and G. Rune,BLTE-SAW architecture and performance,[Ericsson Rev., no. 3, pp. 98–107,2007.

ABOUT THE AUTHORS

Nimish Radia received the B.E. degree in electri-

cal engineering from L. D. School of Engineering,

Ahmedabad, India, in 1987 and the M.S. and Ph.D.

degrees in computer science and engineering from

Syracuse University, Syracuse, NY, in 1992.

He is a Distinguished Researcher at Ericsson

Research Silicon Valley, San Jose, CA, where he

leads research and development activities in the

area of next-generationmobile broadband services.

Ying Zhang received the Ph.D. degree from the

Electrical Engineering and Computer Science

Department, University of Michigan, Ann Arbor,

in 2009.

She is a Researcher in the Packet Technologies

Research group, Ericsson Research Silicon Valley,

San Jose, CA. Her research interests are in net-

working and systems, including Internet and cellu-

lar network management, Internet routing and

measurement, next-generation routing design,

and network security.

Mallik Tatipamula (Senior Member, IEEE) re-

ceived the B.Tech. degree in electronics and

communication engineering from the National

Institute of Technology (NIT), Warangal, India, the

M.S. degree in communication systems and high

frequency technologies from Indian Institute of

Technology, Chennai, India, and the Ph.D. degree

in information science and technology from the

University of Tokyo, Tokyo, Japan, all in 2007.

He is Head of Packet Technologies Research,

Ericsson Silicon Valley, San Jose, CA. He leads a research team

responsible for innovation and implementation of leading edge

technologies including Openflow, next-generation routing architectures,

application-aware networking, and Cloud computing/networking/

services. Prior to Ericsson, he was Vice President and Head of Service

Provider Sector at Juniper Networks, Sunnyvale, CA. He authored/

coauthored over 100 patents/publications. He is lead editor for Multi-

media Communication Networks: Technologies and Services (Norwood,

MA: Artech House, 1998) and coauthor of Advanced Internet Protocols,

Services, and Applications (New York, NY: Wiley, 2012).

Vijay K. Madisetti (Fellow, IEEE) received the

B.Tech. (honors) degree in electronics and elec-

trical communications engineering from Indian

Institute of Technology, Kharagpur, India, in 1984,

and the Ph.D. degree in electrical engineering and

computer science from the University of California

at Berkeley, Berkeley, in 1989.

He is a Professor of Electrical and Computer

Engineering at Georgia Institute of Technology,

Atlanta, GA. His interests are in wireless and mo-

bile systems, digital signal processing, computer engineering, systems

engineering, ASIC design, and software engineering, and has published

extensively in these areas. He is author or coauthor of several books,

including VLSI Digital Signal Processors (Piscataway, NJ: IEEE Press,

1995) and is Editor-in-Chief of the Digital Signal Processing Handbook

(Boca Raton, FL: CRC Press, 2011). He is a frequent consultant to the

industry.

Dr. Madisetti received the 2006 Frederick Emmons Terman Medal

from the American Society of Engineering Education (ASEE) and HP

Corporation.



Documents

Next-Generation Applications on Cellular Networks: Trends, Challenges, and Solutions