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

Transcription

1 INVITED PAPER Next-Generation Applications on Cellular Networks: Trends, Challenges, and Solutions This 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 Manuscript received May 16, 2011; revised September 8, 2011; accepted October 20, Date of publication February 24, 2012; date of current version March 21, N. Radia, Y. Zhang, and M. Tatipamula are with Ericsson Research Silicon Valley, San Jose, CA USA. V. K. Madisetti is with Georgia Institute of Technology, Atlanta, GA USA ( Digital Object Identifier: /JPROC /$31.00 Ó2012 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 networking 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 application 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 development 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 multimedia and real-time mobile applications, including the diversity of application types, their impact on the enterprise and consumer, their traffic volumes, and their load and communication 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 characteristics 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). While a 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 constituted a smaller fraction of the universe of applications developed for the mobile market. The focus of the platform-based manufacturers has been on developing efficient code generators for applications Vol. 100, No. 4, April 2012 Proceedings of the IEEE 841

2 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 released 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 environment 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 underlying logic (application code), while the controller captures 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 a platform-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(seefig.1)providesanalternative to the MVC for the development of more platformindependent representations of a mobile application. The controller provides a link between the abstraction (model) and the presentation components. Various transformers and transcoders support customization of the interface to certain target platforms, while protocol gateways allow easy integration of various types of communication 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 environments, or BMobile App Builders,[ consist of an application composer that the application developer uses to assemble building blocks (i.e., buttons, sliders), and the developer 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-generation mobile 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. 842 Proceedings of the IEEE Vol.100,No.4,April2012

3 B. What Makes a Mobile Application Successful? A succinct description of a modern enterprise is defined by its six main functional activities: 1) inbound logistics 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 significantly when measured in the context of the following metrics: 1) Business transformation: Business transformation is achieved by automation of tasks, sharing and networking of information and people, transformation of processes and relationships, and creating new revenue opportunities. 2) Efficiency: Efficiency is obtained through productivity 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 an organization. 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 interrelated areas of life and work, including 1) productivity (e.g., Bon-the-go ,[ cloud-based documents, travel-based services); 2) utility services (e.g., navigation, communications, alerts, expense, and bill management); 3) entertainment (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 realizing its functionality (i.e., it is useful) and in aligning with a business or consumer purpose or goal; how well it uses technology 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 mobile applications, such as a mobile web browser, or mobile , are useful, deliver excellent performance, and are easy to use, while providing a relatively secure model for usage. C. Choosing the Interactivity Features for a Mobile Application Next-generation mobile application developers have to choose the right features for interactivity between users themselves, and between users and resources (data, information, etc.). Examples of such interactivity and control choices include the following [7]. Structuring mobile interactions: Mobile communications can be treated as either mediated or situated. A mediated 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 afterhours through a call center, while a situated communication 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 distributed has to be integrated into the mobility and mobile application strategy from early on in the design. For instance, a call center that supports mobile taxis is operated via centralized control, while a network of healthcare providers in a chain of hospitals may operate in an autonomous manner, resulting in the change of the mobile application 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 collective 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 Applications Mobile applications, once their functional scope has been identified, are then designed according to their technology requirements, as follows [8]. 1) Connectivity requirements: The choices for connectivity span: online, online-on-demand, onlinewhen-available, and offline. Certain applications, such as Skype, may have to be continuously connected to be useful, while other applications, such as Stock Quotes, could connect on demand. Mobile applications relating to cataloging inventory mayhavetobeabletodownloadupdateswhen 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 applications 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. Vol. 100, No. 4, April 2012 Proceedings of the IEEE 843

4 3) Content type: The choices for content span: corporate/structured or unstructured (multimedia). Access to certain types of content at the enterprise (e.g., payroll or sales data) may require standardized connectors following database application 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 application 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 utilizing 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 applications, e.g., local search, benefit from having location information available. 6) Device management requirements: a) synchronization 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 Applications So far we discussed the design considerations for different mobile applications. On the one hand, diverse classes of applications generate different load on the network, 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 theirplatformasshowninfig.2. Fig. 2 shows the breakdown of different applications as well as their absolute usage volume with an increasing subscriber data plan quotas. Each data plan is associated with a given monthly limit of maximum bandwidth consumptionvalueshowninthex-axis. Interestingly, we observe that not only the traffic volume increases, but also the distribution changes among Fig. 2. Change in user behavior with size of data plan. Fig. 3. Change in user behavior with platform type. 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 knowledgecanenhancemoreintelligentresourceprovisioning by network operators, enhancing user satisfaction and increasing revenues. Besides the impact from the network, the user equipment has more direct impact on the pattern of how user uses mobile applications. Fig. 3 presents different application usage distribution by platform type based on measurements 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 cards consume 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-type device, the dominant application is , as it is mainly used for business and enterprise users. II. DESIGN GUIDELINES FOR MOBILE APPLICATIONS Mobile applications, by definition, are utilized in challenging 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 corporate meeting 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. 844 Proceedings of the IEEE Vol.100,No.4,April2012

5 A. General UI Guidelines for Mobile Applications A 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 the ability 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 Guidelines Specific mobility guidelines for mobile applications include 1) creating designs suitable for multiple contexts (home, business, travel, etc.) including support for runtime adaptation of the application; 2) allowing for multimodal interactions with the device; 3) allowing for convenient use with the ability to handle multiple and frequent interruptions with limited attention from the user; 4) designing for speed of operation so that requests to respond are speedy and compact; 5) presenting information in a hierarchical form, allowing top down interaction; 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) designing with built-in security at device, application, and system levels; and 9) allowing privacy for single or multiple users. C. Organizational Guidelines Corporation and enterprise-specific guidelines for mobile applications include 1) consistency with the organization s standards and systems; 2) support for business models and strategies of the organization; and 3) linkage of mobility-related technology to the existing tasks and social structures within the organization to encourage adoption. III. MOBILE AND SERVER PLATFORM ARCHITECTURES Mobile application models are supported on mobile and server platforms, and it is important not only to understand 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 Evolution Mobile 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 increasingly tend to move toward an all-ip model with multimegabit upload and download data rates, with multiple simultaneous communication pipesvfourth generation (4G) for cellular links, WiFi links for the local area network (LAN) connectivity, 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 interact closely with land-based televisions; set-top boxes; video game consoles; automotive platforms; travel, airport, and hotel kiosks; supermarket checkout registers; and businesssystems(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 include its integration into other electronics systems that the consumer typically interacts with, includingpcs,laptops,tvs,andawidevarietyofpayment systems, located in shopping malls, groceries, and at colleges or at the workplace. 2) Data and content storage architecture: Local storage on the mobile platform is increasing, being augmented by cloud-based storage that provides practically unlimited capacity that can be downloaded on demand, either in a batch mode or in a streaming mode of access. Many of these storage and synchronization options are based on a subscription model, both for storage and also for content, and ensure that the mobile consumer of application 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 a laptop computer). The smart mobile platform may encapsulate most of the features of a set-top box, a DVRthatsupportstimeshifting,atelevision,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 gyroscopes 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 additional information of interest to the consumer. Vol. 100, No. 4, April 2012 Proceedings of the IEEE 845

6 Advanced image processing to directly accept gestures 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 video, coupled with advanced video displays, capable of rendering video in high-definition (HD) formats, have become mainstream, and when combined with the ability to drive multiple screens (e.g., TV or automobile video), provide a truly mobile environment for the streamed entertainment (mobile TV) from traditional providers and ensure a high-quality game or application (including 3-D visualization and graphics acceleration) experience while in a standalone mode of operations. 5) Advanced application usage models: Advanced models for applications include peer-to-peer models (e.g., video conferencing), star-based social networking models, and collaborative models (i.e., multiplayer video games across the network or in a distance-based learning environment), in addition 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 support cloud-based functionality and data storage while retaining only the user interface components on the mobile device is likely to be the preferred model for deployment. 6) Device content and application management: Both operator and mobile platform vendor supported platforms that serve as a marketplace and distributing 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 emulatemultiplemobileplatforms(e.g.,android emulating an iphone or a Blackberry platform) and cloud-based deployment and control of applications that run on multiple platforms, through local adaption layers). B. Mobile Application Usage Models The industry has converged on four major models for mobile applications in terms of their usage [10]. 1) Mobile web content browsing: Primarily for consuming rich online and/or live content from the web via a mobile platform, with a limited amount of 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 processing and data storage. 3) Mobile widgets: Widgets provide views of applications that are capable of independently running on the mobile platform, and can also be executed inside a browser, enhancing portability across multiple platforms. 4) Standalone mobile applications: Independent applications 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 applications (Bthereisanappforthat![). IV. RUNTIME PLATFORMS FOR MOBILE 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 Architecture The device-side mobile application architecture consists of the following components. 1) Device content flow control endpoint:thismoduleis responsible for managing rich media content flow to and from the client device. 2) Device signaling flow control endpoint: Itisresponsible for setting up sessions and associated flow control [including quality of service (QoS)] related to connection management for rich content (i.e., multimedia streaming or multiway video conferencing). 3) Client-side adaptation engine: It adapts web content for optimal use by the client platform. 4) Renderer: Processing engine to drive display efficiently. 5) Client-side application processing: Client-side application 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 data manager, security manager, user awareness manager, resource manager, experience manager, and delivery context manager. B. Server-Side Mobile Application Architecture The server-side mobile application architecture consists of the following components. 1) Server-side adaption engine: It allows server to adapt responses to suit requests from a variety of mobile clients, based on adaption rules. 2) Server application: It performs server-side processing on behalf of the mobile application, offloading processing from the client. 3) Content and signaling flow control endpoint: Itprovides support for media and signaling flow for rich 846 Proceedings of the IEEE Vol. 100, No. 4, April 2012

7 Fig. 4. Device-side model for a mobile application platform. 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 ensuring QoS. C. Mobile Application Support Utilities Themobileapplication,ontheclientside,issupported 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 environment (including automotive and consumer electronics devices). Fig. 5. Server-side model for a mobile application platform. Vol. 100, No. 4, April 2012 Proceedings of the IEEE 847

8 Resource manager: It provides a number of utilities that optimize resource usage on the mobile platform, including content compression, memory optimization for applications, and minimal use of local resources through aggregating and caching data. User experience manager (UEM): It provides utilities that maximize user experience satisfaction, including reducing latency for offline startup and improving perceived latency through incremental rendering and user status updates. The UEM also provides support for multiple interaction 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 application preferences, awareness of the state of the client, and the state of the application through personalization data. Delivery context manager: It provides utilities for adjusting content on the mobile platform, adjusting navigation 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 for mobile platform profiles (e.g., learning profile, communication profile, entertainment profile, utility profile) that are used 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 management capabilities (see Fig. 6) are introduced into the network operations center (NOC). As the traffic demand increases, resource contention can exist due to unexpected and transient traffic spikes or intentional attacks. Furthermore, application performance may be affected by the network failures. Given a fixed amount of resource, QoS techniques are indispensable to optimize the resource utilization. Besides resource control, the network also contains 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: Internet video 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 overthe-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 cable production companies. Furthermore, popularity of a channel or a certain type of media offering was somewhat controllable through professional marketing campaigns. The advent of OTT video publishing has reshaped the video market enormously. Today, hundreds of millions of Internet 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. The attention span of the typical user for a particular type of content has been reduced to days (or even hours) as opposed to weeks or months in traditional news media. Fig. 6. Network operation center as part of the mobile application platform. 848 Proceedings of the IEEE Vol. 100, No. 4, April 2012

9 One of the keys to YouTube s success appears to be its use 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 additional browser plug-ins provided. To enable playback of the flash video before the content is completely downloaded, YouTube relies on Adobe s progressive download technology. 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 streaming 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 to stream 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 for typical 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 application 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-axisistheloadafternormalization. The figure illustrates rapid degradation in throughput as the load increases. The figure demonstrates vividly how the voice application is affected by that network 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. Vol. 100, No. 4, April 2012 Proceedings of the IEEE 849

10 Fig. 8. Sensitivity of the mobile application performance to radio channel characteristics. 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 linearly with the network performance metrics, adding to users dissatisfaction with mobile application performance, if operators do not track these sensitive metrics continuously. V. MOBILE APPLICATIONS AND 4G NETWORKS A. QoS and Network Resource Optimization Given 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 subscriber groups for the same applications. These subscriber groups can be defined in any way that is suitable to the operator, for example, corporate versus private subscribers, postpaid versus prepaid subscribers, and incoming roaming subscribers. The next-generation 4G or LTE network has shifted to an all-ip flat network architecture that has traditionallysupportthebbesteffort[ model of service. New mobile applications requiring real-time support and high-speed response from the network will coexist with applications that only require lower value best effort services (i.e., ). 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 Network (RAN): The basic unit in cellular network for QoS management is called bearer. A bearer uniquely identifies flows that receive a common QoS treatment between the terminal and the gateway. A flow is defined by a five-tuplebased 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 differential treatment for traffic with differing QoS requirements. The QoS class identifier (QCI) is the parameter to identify different classes of applications such as conversational, interactive, streaming, and background traffic types. QCI is a scalar that is used as a reference to parameters 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 as scheduling weights, admission thresholds, queue management 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. Subsequently, enodeb handles the bearer traffic to enforce the resource allocation [14]. 2) QoS Support in Transport: There are two principal approaches to implement QoS in packet-switched networks: a) a prioritizing system, where each packet identifies a desired service level, and b) a parameterized system, basedonanexchangeofapplicationrequirementswiththe network. The well-known examples of these two systems are the differentiated services (DiffServ) and the integrated services (IntServ) architectures. The DiffServ architecture, defined in RFC 2475, provides QoS by handling different classes of traffic in different 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 differentiate between different packets, in terms of the assigned bandwidth 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 for providing 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 850 Proceedings of the IEEE Vol. 100, No. 4, April 2012

11 requests. If enough resources exist, resource reservation is made. 3) QoS in Evolved Packet Core: The QoS policy is controlled in the packet core of the cellular network. It determines 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 or modify 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 offline charging 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 together 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 unlocking smartphones from their operators [14]. B. Operator APIs for Mobile Applications In 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 traditional 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 advantage of becoming the strategic partners and information suppliers to the third-party application developers. The advantage resides in their unique position in the management 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 services to Bsmart-pipe[-based tiered services. Providing tiered services further stresses network functions such as policy configuration, network enforcement, resource control, 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-based rich media applications have been proposed as new types of operator-managed communication services, today the most popular applications are still OTT third-party applications, 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 service APIs are critical enablers for such business model. The operator-supported NOC provides a number of functions on behalf of the mobile application and the mobile application 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 provides location 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 application is largely simplified. For instance, it can be built on HTTP protocol by calling the APIs instead of using complex SMPP protocol. It also simplifies the server side communication, without relying on an SMPP-enabled gateway to send/receive messages. WAP Push APIs: The network gateways can accept HTTP POST connections directly from web applications. Developers 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 manufacturers and network providers. For instance, the network provider can work with device manufacturers to set a policy on which application can access which APIs based on the creator of the application and its functionality. Such policies,ofcourse,ultimatelyneedtobeenforcedincollaboration 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 usercontrolled permission for application access to the APIs, e.g., once by the application, for the application session, or always by the application. Vol. 100, No. 4, April 2012 Proceedings of the IEEE 851

12 Each mobile operating environment, in conjunction with 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. Together with other integration challenges, this increases the complexity and time-to-market for mobile applications. Wholesale application community (WAC) initiative, supported by many global carriers, represents one such effort, toward unification of these device and platform APIs that are expected to be utilized by the next-generation mobile applications [10], [11], [13]. Similar to device APIs, for network-specific capabilities, uniformity and consistency are provided via WAC including GSMA OneAPI as part of its roadmap. GSMA OneAPI provides uniform and consistent access to network capabilities such as location, in-app carrier billing/ payment, messaging (SMS/MMS), voice call control, data connection profile, and device profiles. C. Building Blocks of the Next-Generation Device and 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 ensuing resources 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 device, 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 the request 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 and application 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 application. The device runtime, e.g., WAC runtime, could use the PKI infrastructure to validate the identity of the application 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 applications, the user also needs to know the Breputation[ of the application. For example, what is application s reputation 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 application 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. 852 Proceedings of the IEEE Vol. 100, No. 4, April 2012

13 application provider domain, e.g., Apple s AppStore or Android Marketplace, or other third-party provided application 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 information relevant to that user or group of users. The PKI-based signed 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 applications and 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., stronger, 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 identities 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 from the device and network can reveal information about user s whereaboutsaswellastypicalmovementpatternsofan 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 capabilities 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 controlling how and by whom such information can be used. This requires the runtime environment, e.g., a WAC runtime, 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 usable and scalable solution needs to be developed. Moving forward, 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 network API providers will also need to enforce the privacy required by the user and the local government policies and regulations. Using OAuth, or other such de facto standard technology, for device as well as network APIs, would provide consistent programming model for the application developer and support management of privacy requirements 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 implement the policies in their own contexts. As shown in Fig. 9, device has the policy-store (PS) and policy enforcement point (PEP) that implement device-specific policies for access and usage of device APIs. Typically, PS and PEP are embedded inside a given runtime 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 toenforcetheusageoftheapi.thepoliciesinpsenforced by PEP need to support multiple model, e.g., user-defined policies, device-provider-defined policies, and networkprovider-defined policies. As the complexity and number of applications on the device increase, it will also need to support 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, the user 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 mobility on 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 academia, and have also proposed conceptual platform architectures for the device, server, and cellular network for their efficient deployment. A detailed look at the infrastructure issues, related to QoS, and how they drive and are 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 emphasized, if operators plan to see new revenues from nontraditional wholesale customers from their network, and some solutions for these APIs are also presented. h Vol. 100, No. 4, April 2012 Proceedings of the IEEE 853

14 REFERENCES [1] T. Reenskaug, Models, Views, Controller, Xerox PARC Technical Note, May [Online]. Available: /mvc-2/ MVC.pdf. [2] J. Coutaz, BPAC: An implementation model for dialog design,[ in Proc. Interact Conf., Stuggart, Germany, 1987, pp [3] R. B Far, Mobile Computing Principles. Cambridge, U.K.: Cambridge Univ. Press, [4] Google App Inventor, [Online]. Available: [5] F. Buschmann, R. Meunier, H. Rohnert, P. Sommerlad, and M. Stal, Pattern Oriented Software Architecture, Vol 1: A System of Patterns. New York: Wiley, [6] R. C. Basole, Ed., Enterprise Mobility: Applications, Technologies, and Strategies, vol. 2. Amsterdam, The Netherlands: IOS Press, 2008, ser. Tennenbaum Institute Series on Enterprise Systems. [7] P. Tarasewich, J. Gong, F. Nah, and D. DeWester, BMobile interaction design: Integrating individual and organizational perspectives,[ Inf. Knowl. Syst. Manage., vol. 7, pp , [8] P. Brans and R. Basole, BA comparative anatomy of mobile enterprise applications: Toward a framework for software reuse,[ Inf. Knowl. Syst. Manage., vol. 7, pp , [9] E. Scornavacca and S. Barnes, BThe strategic value of enterprise mobility,[ Inf. Knowl. Syst. Manage., vol. 7, pp , [10] W3C, Mobile Web Application Best Practices, W3C Recommendation, Dec. 14, [Online]. Available: mwabp/. [11] OpenID Foundation. [Online]. Available: [12] OAuth. [Online]. Available: [13] Wholesale Applications Community (WAC). [Online]. Available: [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 , ABOUT THE AUTHORS Nimish Radia received the B.E. degree in electrical 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 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-generation mobile broadband services. 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 Multimedia Communication Networks: Technologies and Services (Norwood, MA: Artech House, 1998) and coauthor of Advanced Internet Protocols, Services, and Applications (New York, NY: Wiley, 2012). Ying Zhang received the Ph.D. degree from the Electrical Engineering and Computer Science Department, University of Michigan, Ann Arbor, in She is a Researcher in the Packet Technologies Research group, Ericsson Research Silicon Valley, San Jose, CA. Her research interests are in networking and systems, including Internet and cellular network management, Internet routing and measurement, next-generation routing design, and network security. Mallik Tatipamula (Senior Member, IEEE) received 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 He is Head of Packet Technologies Research, Ericsson Silicon Valley, San Jose, CA. He leads a research team Vijay K. Madisetti (Fellow, IEEE) received the B.Tech. (honors) degree in electronics and electrical 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 He is a Professor of Electrical and Computer Engineering at Georgia Institute of Technology, Atlanta, GA. His interests are in wireless and mobile 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. 854 Proceedings of the IEEE Vol. 100, No. 4, April 2012