Download Mobile Computing: Rich Sensed Data & Transient Infrastructure - Next Decade Implications and more Schemes and Mind Maps Mobile Computing in PDF only on Docsity!
Mobile Computing: the Next Decade
Mahadev Satyanarayanan
School of Computer Science
Carnegie Mellon University
1 Introduction
“Information at your fingertips anywhere, anytime” has been the driving vision of mobile computing for the past two decades. Through relentless pursuit of this vision, spurring innovations in wireless technol- ogy, energy-efficient portable hardware and adaptive software, we have now largely attained this goal. Ubiquitous email and Web access is a reality that is experienced by millions of users worldwide through their BlackBerries, iPhones, Windows Mobile, and other portable devices. Continuing on this road, mo- bile Web-based services and location-aware adver- tising opportunities have begun to appear, triggering large commercial investments. Mobile computing has arrived as a lucrative business proposition. What will inspire our research in mobile comput- ing over the next decade and beyond? We begin by considering two hypothetical mobile computing sce- narios from the future. We then extract the deep as- sumptions implicit in these scenarios, and use them to speculate on the future trajectory of mobile com- puting. We conclude that there are really two fun- damentally distinct strategies at play, and that the di- alectic between these strategies will largely shape the mobile computing landscape of the future.
2 Scenario 1: Lost Child
Five-year old John is having a wonderful time with his family at the Macy’s Thanksgiving Day parade in Manhattan. Mid-way through the parade, John sees a group of friends in the crowd nearby. He shows his parents where his friends are, and tells them he is going over to meet them. Since his parents see re-
sponsible adults in the group, they are fine with John walking over to see his friends. An hour later, John’s parents walk over to where they expect to find him. To their shock, they discover that the friends have not seen John at all. He has been missing for an entire hour now, and John’s parents are very concerned. Searching for a lost child in a Manhanttan crowd is a daunting task. Fortunately, a police officer nearby is able to send out an amber alert via text message to all smart- phone users within two miles. He requests them to upload all photographs they may have taken in the past hour to a secure web site that only the police can view. In a matter of minutes, the web site is populated with many photographs. New photographs continue to arrive as more people respond to the amber alert. With John’s parents helping him, the police officer searches these photographs with an application on his smartphone. His search is for the red plaid shirt that John was wearing. After a few pictures of Scot- tish kilts in the parade, a picture appears that thrills John’s parents. In a corner of that picture, barely visible, is a small boy in a red shirt sitting on the steps of a building. The police officer recognizes the building as being just two blocks further down the parade route, and contacts one of his fellow officers who is closer to that location. Within moments, the officer is with the boy. John is safe now, but he has a lot of explaining to do...
3 Scenario 2: Disaster Relief
The Big One, measuring 9.1 on the Richter scale, has just hit Northern California. The entire Bay Area is one seething mass of humanity in anguish. Many highways, power cables and communication lines are severely damaged. Disaster on such a scale has not been seen since World War II. With limited manpower, unreliable communication and marginal transportation, disaster relief personnel are stretched to the limit. Internet infrastructure, in-
cluding many key data centers, have been destroyed. The Googleplex has been reduced to a smoking hulk. In spite of heroic efforts, disaster relief is painfully slow and hopelessly inadequate relative to the scale of destruction. Sudden obsolescence of information regarding ter- rain and buildings is a major contributor to slow re- sponse. Vital sources of knowledge such as maps, surveys, photographs, building floor plans, and so on are no longer valid. Major highways on a map are no longer usable. Bridges, buildings, and landmarks have collapsed. GoogleEarth and GoogleMaps are now useless for this reqion. Even the physical topog- raphy of an affected area may be severely changed. Conducting search and rescue missions in the face of obsolete information is difficult and dangerous. New knowledge of terrain and buildings has to be recon- structed from scratch at sufficient resolution to make important life and death decisions in search and res- cue missions. In desperation, the rescue effort turns to an emerg- ing technology: camera-based GigaPan sensing. Us- ing off-the-shelf consumer-grade cameras in smart- phones, local citizens take hundreds of close-up im- ages of disaster scenes. Transmission of these im- ages sometimes occurs via spotty low-grade wireless communication; more often, the images are physi- cally transported by citizens or rescue workers. The captured images are then stitched together into a zoomable panorama using compute-intensive vision algorithms. To speed up the process, small GigaPan robots that can systematically photograph a scene with hundreds of close-up images are air-dropped over the area for use by citizens. Slowly and painstakingly, detailed maps and to- pographical overlays are constructed bottom-up. As they become available, rescue efforts for those ar- eas are sped up and become more effective. Rescu- ing trapped people is still dangerous, but at least the search teams are now armed with accurate informa- tion that gives them a fighting chance...
4 Reflecting on these Scenarios
These scenarios embody a number of themes that will be central to the evolution of mobile computing over the next decade. We explore these themes next. Common to both scenarios is the prominent role of
mobile devices as rich sensors. While their comput- ing and communicaton roles continue to be impor- tant, it is their rich sensing role (image capture) that stands out most prominently in these scenarios. We use the term “rich” to connote the depth and com- plexity about the real world that is being captured. This is in contrast to simple scalar data such as tem- perature, time and location that are involved in typ- ical sensor network applications. When cell phones with integrated cameras first appeared, people won- dered if they represented a solution in search of a problem. Would mobile users take so many pho- tographs that this capability was worth supporting? Today, the value of this functionality is no longer questioned. Tomorrow the roles will be reversed: people will wonder why any digital camera lacks the wireless capability to transmit its images. Video cap- ture, leading to even richer sensing and recording of the real world is also likely to gain traction. A second emergent theme is that of near-real-time data consistency. This is most apparent in the lost child scenario, where the only useful images are very recent ones. Pictures taken before the child was lost are useless in this context. Recency of data is also important in the disaster relief scenario. A major earthquake is often followed by aftershocks for hours or possibly days. These aftershocks can add to the damage caused by the original quake, and in some cases be the “tipping point” that triggers major struc- tural and topographical changes. Regions that have already been mapped after the original quake may need to be remapped. The need for near-real-time data consistency forces rethinking of a long line of work in mobile computing that relates to the use of prefetching and hoarding for failure resiliency. The core concepts behind those techniques may still be valuable, but major changes in their implementations may have to be developed in order to apply them to the new context. In the disaster relief scenario, for example, many old maps and photographs may still be valid if the buildings and terrain involved have only been minimally affected. However, discover- ing whether it is acceptable to use hoarded informa- tion about them is a challenge. No central authority (e.g. a server) can answer this question with confi- dence. Only an on-the-spot entity (e.g. a user with a mobile device) can assess whether current reality is close enough to old data for safe reuse. That de-
Low-latency high-bandwidth wireless network
Mobile Eye Trek^ Olympus WearableComputer
Wearable^ Handtalk Glove
Nokia N810Tablet
AndroidPhone
Coffee shopCloudlet
Distant cloud on Internet
(a) Cloudlet Concept
Cloudlet Cloud State Only soft state Hard and soft state Management Self-managed; little to no professional atten- tion
Professionally adminis- tered, 24x7 operator
Environment “Datacenter in a box” at business premises
Machine room with power conditioning and cooling Ownership Decentralized owner- ship by local business
Centralized ownership by Amazon, Yahoo!, etc. Network LAN la- tency/bandwidth
Internet latency/bandwidth
Sharing Few users at a time 100s-1000s of users at a time (b) Key Differences: Cloudlet vs. Cloud Figure 3: Extending the Classic 2-level Mobile Computing Architecture to 3 Levels
5 Transient Infrastructure Since birth, mobile computing has implicitly as- sumed a 2-level hierarchy. Originally, the two lev- els were identified as “servers” and “clients.” More recent terminology uses “cloud” to connote the com- putational and information resources represented by a collection of servers. Regardless of terminology, however, the 2-level concept is woven quite deeply into our thinking about mobile computing. The up- per layer (“cloud” or “server”) is assumed to be well- managed, trusted by the lower layer, and free from concerns that are specific to mobility such as battery life and size/weight constraints. Future architectures for mobile computing are likely to extend this 2-level hierarchy to at least one additional layer, possibly more. The case for an in- termediate layer called a cloudlet was articulated in a recent paper [3]. In that work, the rationale offered for the architectural extension is low latency network communication to computational resources in order to enable a new genre of immersive mobile appli- cations. Cloudlets are viewed as decentralized and widely-dispersed Internet infrastructure whose com- pute cycles and storage resources can be leveraged by nearby mobile computers. A natural implementa- tion is to extend Wi-Fi access points to include sub- stantial processing, memory and persistent storage for use by associated mobile devices. A cloudlet can be viewed as a “data center in a box.” It is self-managing, requiring little more than power, Internet connectivity, and access control for
setup. This simplicity of management corresponds to an appliance model of computing resources, and makes it trivial to deploy. For safe deployment in unmonitored areas, the cloudlet may be packaged in a tamper-resistant or tamper-evident enclosure with third-party remote monitoring of hardware integrity. Figure 3(b) summarizes some of the key differ- ences between cloudlets and clouds. Most impor- tantly, a cloudlet only contains soft state such as cache copies of data or code that is available else- where. Loss or destruction of a cloudlet is hence not catastrophic. This stateless model leads to an im- portant research challenge: how can a mobile device rapidly and safely customize a cloudlet for its spe- cific use? A possible solution, based on dynamic vir- tual machine synthesis, is sketched in [3]. Other approaches may also need to be explored. Although originally motivated by considerations of network latency, cloudlets have much broader relevance. In particular, they are relevant to both the scenarios presented earlier. The GigaPan ap- proach relies on compute-intensive vision algorithms to stitch together a zoomable panorama from indi- vidual images. Under normal conditions, these algo- rithms can be executed in the cloud. However, cloud computing may be compromised in the aftermath of a disaster. The physical infrastructure necessary for good Internet connectivity may have been destroyed and it may be many days or weeks before these can be repaired. Limited Internet connectivity may be re-established soon after the catastrophic event, but
there will be very high demand on this scarce re- source from diverse sources: families trying to des- perately learn and share information about the fate of loved ones, citizen reporters and professional jour- nalists sharing videos, images, blogs, and tweets of the disaster area with the outside world, and disaster relief agencies coordinating their efforts with their home bases. Under these conditions, cloudlets may be needed to support cloud computing. We envision opportunistic deployment of cloudlets in disaster relief. In the immediate af- termath of a disaster, before external IT supplies have arrived, any available hardware such as an undamaged desktop can be pressed into service as a cloudlet. A cloudlet can even be built around a high-end laptop, with its few hours of battery life being priceless prior to the arrival of emergency electrical generators. As IT supplies arrive, tempo- rary cloudlets may be replaced by purpose-designed equipment. Cloudlets also have relevance to the lost child scenario. In that scenario, the near-real-time im- age search will require extensive computation since pre-computed indexes are not available for the con- tributed images. Cloud computing is the obvious an- swer for this, but exactly where in the cloud to com- pute is an open question. The task involves submis- sion of images from a lot of people in the immedi- ate neighborhood of the lost child; the search results will also be viewed there. This suggests use of local infrastructure (i.e., a cloudlet) rather than distant in- frastructure. Once the search is completed (success- fully or unsuccessfully) the contributed images can be discarded. This fits well with the stateless model of cloudlets and their use as transient infrastructure.
6 Competing Design Strategies
So far, this paper has focused on how mobile com- puting today and tomorrow differs from the past. Amidst all this change, however, certain fundamental challenges of mobility have remained invariant since they were articulated over 15 years ago [2]. First, wireless connectivity is highly variable in performance and reliability. Many real-world fac- tors hinder ubiquitous high-bandwidth wireless con- nectivity. For example, Wi-Fi connectivity in pub- lic spaces often requires a subscription or one-time
payment to the service provider. In private spaces (such as inside a customer’s premises), there may be organizational or access control reasons that prevent Wi-Fi connectivity. 3G or 4G connectivity has wider coverage, but offers signifiantly poorer bandwidth. Even these lower-bandwidth alternatives are some- times unavailable within buildings. Finally, there are situations where wireless transmissions are forbid- den: for example, during air travel. Second, mobile hardware is necessarily resource- poor relative to static client and server hardware. Considerations of weight, size, battery life, er- gonomics, and heat dissipation exact a severe penalty in processor speed, memory size, disk capacity, etc. For a user, a mobile device can never be too small, too light or have too long a battery life. While mo- bile hardware continues to evolve and improve, com- putation on mobile devices will always be a com- promise. An additional obstacle is the slow pace of improvement in battery technology, especially when compared to Moore’s Law. The first challenge (uncertain connectivity) leads to a “Swiss Army Knife” design philosophy: try to cram as much functionality as possible into a compact design that is self-contained and as frugal as possible in resource usage. Unfortunately, this approach often compromises usability, just as the tools in a real Swiss Army Knife (such as knife, fork, can opener, and corkscrew) are poor substitutes for full-sized implementations. Miniscule displays and keyboards are especially challenging for mobile users, particularly in the context of a graying popu- lation. Unfortunately, the incentives of today’s mar- ketplace tend to reward itemizable functionality en- hancements rather than improvements to more dif- fuse attributes such as usability. The second challenge (resource poverty) com- bined with the limitations of the Swiss Army Knife approach will eventually lead to a very different de- sign philosophy. Rather than relying exclusively on a self-contained mobile device, one can use that device to leverage other resources such as a distant cloud, a nearby cloudlet, or an interaction device such as a large display. We refer to this as a “wallet” design philosophy because it resembles the role of wallets in everyday life. A typical wallet contains things like cash, credit cards, and ID cards. None of these items are intrinsically valuable. Rather, their value lies in
