1. Planning around Technology Prof. Eric A. Brewer UC Berkeley ICT for Developing Regions September 17, 2003

2. Today’s Focus  How to think about technology…  Not very technical  Goal: map applications into technology options  Architecture  Networking  Devices and Sensors

3. General Architecture Proxies, Basestations Devices or sensors cell “disconnected” Internet Data Center

4. Data Centers  Best place to store persistent data  (device is second best)  Can justify backup power, networking, physical security  Cheapest source of storage/computer per user  100-1000x less than a personal device (!)  Factors: shared resources, admin cost, raw costs (power, disks, CPUs)  Need at least two for disaster tolerance  Plan about 3 in urban centers (for one region)  Berkeley will be the data center for our early work…

5. Networking  The key enabler… distribution for information.  Focus on wireless  Vastly cheaper to deploy  Wide range of options  Packets allow efficient use of media  “multiplexing”  IP = “Internet Protocol”  Global names for every device  Way to route packets to names

6. Basics  Bandwidth = data/sec  Modem = 56 kilobits/sec  DSL = 384 kilobits/sec  Latency = transmission delay in seconds  Ethernet = milliseconds  Satellite = ¼ second  Power should be mostly tied to transmission  Double distance => quadruple power  Sequence of short hops usually lower power (but higher latency)

7. Communication Attributes  Directional or Omnidirectional  Broadcast or Unicast  Wireless is always broadcast  Shared or Single User  Wireless is always shared  Synchronous or Asynchronous  Cellular is synchronous: full-time two-way connection  E-mail is asynchronous: send now, receive later

8. Understanding Range  Range costs power (squared)  Long distances best covered with directional antennas  10x difference in range for low cost  “Point-to-point” links  Can go 50km at reasonable cost  User density matters:  Range also limited by total users  Urban areas thus use short-range wireless  Rural areas need long-range  Claim: need islands of coverage (with point-to-point)  Islands are the dense areas (e.g. villages)

9. Example: India Mumbai (Bombay) Chennai (Madras)

10. Mumbai

11. Broadcast vs. Unicast  Broadcast: same data to everyone  TV, radio, newspaper  Unicast: data to one person  Web page, e-mail  Wireless broadcast is *cheap*  Easy to reach many users with one transmission  Example: satellite TV  Claim: we will need to exploit broadcast  Broadcast common data even for unicast applications  Example: common web content  Goal: minimize unicast data

12. Synchronous vs. Asynchronous  Synchronous: two-way communications  Low latency, e.g. Phone = ¼ sec or less  Expensive: dedicated resources along whole path  Examples: phones, games, web browsing  Async One-Way: e.g. TV, Internet movie  Delay allowed: e.g. “buffering” for Real Player  Hides losses: resend data before it is missed  Typical delay is 10 seconds  Good fit for broadcast  Examples: Streaming, Market Prices, Weather alerts

13. Sync vs. Async (2)  Async Two-Way: e.g. e-mail request  Delay in getting response (= two async one-way)  Semi-interactive, but potentially much cheaper…  Savings:  No need for dedicated resources  Can “store-and-forward” data (like real mail)  Can hide problems (e.g. power out) by waiting  Examples: e-mail, correspondence classes, medical diagnosis (non-emergency), coordinating money transfers, e- commerce (e.g. catalogs)  Open Questions:  How much cheaper? How much more reliable?  When is async good enough?

14. Intermittent Networking  Physical:  Low-earth orbit satellites: connect only while they are overhead  “Mules” – moving basestation collects data  Basestation could be on a bus  Weather, e.g. some places only get radio on clear nights  Overloaded network may delay transmission  Extended coverage:  User may periodically enter the coverage area  E.g. coverage only near market or school

15. The Case for Intermittent  Pros:  Cost: better use of resources, more tolerant of problems  Reliability: delay hides transient problems  Ease of deployment: can be more ad hoc, less coordination than a synchronous system  Coverage: Intermittent coverage >> full time coverage  Cons:  Not really interactive, or only interactive in some areas  Need to design apps around this (new) model  Don’t know what delay is OK (depends on the app)

16. Cellular Phones  Advantages:  User interface works well (no need for literacy)  High demand for voice, but some data provided  High-volume phones and basestations  Disadvantages:  Hard and expensive technically  Voice may be inefficient use of bandwidth  Poor fit for rural users (low density of users)  Typical data rate < 9600 baud

17. Example: Cellular Standards System Cell Range Cost Bandwidth bits/sec Simult. Users GSM 10 km $100K9600~800 PHS 100-300 m $3K9600~200 MiniGSM 35 km ?9600~800

18. Satellites  Pros: great for broadcast, coverage  Cons: limited shared bandwidth, mostly one-way, high latency  GEO (geostationary – stays in one place)  35000 km up, very high latency  Mostly one-way due to power  LEO (low-earth orbit), <1000 km up  Intermittent coverage (only when overhead)  Better latency and power, cheaper  Need lots of satellites (800?)

19. Two-way using Satellites  Option 1: transmit up to the satellite  Very high power required, and large antenna  Very low bandwidth (9600 or less)  Option 2: use a different network  Telephone is most common, could use wireless  Tricky but possible to do TCP  Variation: upload data later when convenient (intermittent)  Good for mostly broadcast applications, coverage

20. WiFi: 802.11  Made for wireless local-area network  Three variations:  b: 1 Mb/s, oldest and cheapest, $5/chipset  Best for long-distance links  a: 11 Mb/s, shorter range  g: 54 Mb/s, shorter range, more channels  Best for omni coverage of local area (if cheap)  Decent for long distance: (802.11b)  Special directional antennas & alignment, ($20-$200)  30km seems easy, 88km is current record  Longer distances need towers, 40’ typical

21. WiMax (802.16)  New standard for metro areas  Target is 30km radius, $20K for basestation  Cost should come down (as with 802.11)  High bandwidth, low density  Receiver per village, not per person  100 villages per basestation plausible  Probably requires licensing (not free for all)  Complements 802.11 for local coverage  Expect this combo to be very popular…

22. Proxies and Basestations Cellular => one basestation per cell Proxies are similar: locally shared computing/storage  10x less than devices (per user!)  Target cost: $200 or about 20¢ per user  Good way to share computing, storage  Relay point for networking  Typically stationary, may be solar powered  “Mules” are mobile proxies  Easy to upgrade in place (like Tivo)  Not good for long-term storage (“persistent data”)  No backup plan, unreliable power and security…

23. Example Proxy Tasks  Caching of frequently used data  Such data can be broadcast to proxies  Temporary storage  Packets waiting for LEO  Transactions in progress  Computation-intensive tasks:  Speech recognition  Sensor data analysis  Process data for “dumb” device  Can double as “big” device, e.g. Internet kiosk

24. Devices  Wide range of devices are possible  Two broad classes:  General-purpose computer (Simputer, PDA, laptop)  Task specific: water testing, telephone, camera  Claim: task specific is a better choice  Much simpler to use (and train for)  Can be more cost effective  Volume should be high enough to justify

25. Shared Devices  Sharing reduces the cost per user  Village phones have 4-8x better cost/performance  May only need one per village (water testing)  Some design issues:  Does behavior depend on which user?  E-mail does, telephone does not  Need for authentication, accounting?  Claim: Most projects should start with shared devices  Can move to personal devices if demand warrants…

26. Device Costs  Big costs:  Packaging  Screen: color is >3x monochrome  Battery  UI: keyboard, buttons, touch screen, …  General driver: too many components  Solution: better integration into silicon  Silicon is ~free… (marginal cost)  We are working on real details of costs…

27. How to think about devices…  Sharing is good (but design for it)  Task-specific is good (simpler and cheaper)  UI and size have a lot to do with cost…  Dependence on infrastructure is good  Reduces cost (and theft)  Can push work into infrastructure as needed  Increases extensibility, decreases obsolescence  … but requires thought about disconnected operation

28. Sensors  Sensors on silicon => very cheap  Basic: temp, humidity, pressure, moisture, light…  Moderate: acceleration, magnetic, position  Simple chemical: gases, smoke  Complex biological: toxic agents  Actuators: control environment as well  Much harder: usually want human in the loop…

29. Sensor Applications  Environmental monitoring  Water testing  Weather warnings?  Aid to Infrastructure  Electrical grid loss/theft  Water distribution loss/theft/quality  Commerce  Butterfat testing for milk pricing  Health  Home environment  Human tests? (or animal)

30. Example: Great Duck Island Monitoring petrels on an island in Maine  About 50 sensors  Some in burrows, detect occupancy  Some to track environmental conditions  Fits architecture:  Data center in Berkeley  Network: local wireless in patches, satellite to UCB  Proxies: process/manage data collection  Mix of sensors  Intermittent connectivity (to save power) 1.25 inch

31. Summary  Decide on the task  Not about internet access (per se), about applications  Drives UI, leads to simplicity, lower cost  Long-term: single chip per app is ideal…  Wide range of devices can share infrastructure  Intermittent networking may be sufficient  Greater coverage, much lower cost, more reliable  Not always interactive  Share, share, share  Data centers are big shared resources, >100x savings  Proxies are locally shared resources, >10x savings  Share devices as well