mobile os and mobile service architectures prabhaker mateti ceg4361

139
Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG436 1

Upload: francis-cameron

Post on 18-Dec-2015

225 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

1

Mobile OS and Mobile Service Architectures

Prabhaker Mateti

CEG436

Page 2: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

2

What is an OS?

• An OS controls all the hardware of a computer, and every program currently running.

• All computer systems, by definition, include an OS. • Several modern day gadgets, such as cell phones,

MP3 players, wrist watches, PDAs, video game consoles, TiVO, … are specialized computer systems.

• Many appliances, such as microwave ovens, dishwashers and TVs, contain embedded computer systems.

CEG436

Page 3: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

3

OS Definition by Functionality• From the book by Silbershatz and others: • "What are the three main purposes of an operating system?

Answers: • (i) To provide an environment for a computer user to execute

programs on computer hardware in a convenient and efficient manner.

• (ii) To allocate the separate resources of the computer as needed to solve the problem given. The allocation process should be as fair and efficient as possible.

• (iii) As a control program it serves two major functions: (a) supervision of the execution of user programs to prevent errors and improper use of the computer, and (b) management of the operation and control of I/O devices."

CEG436

Page 4: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

4

OS Definition by Components

• OS = … + …• VM Virtual Memory Management• File System • Process Management• Network Layer (TCP/IP)• Input/Output System• User Management• (OS Boot Loader)• [System Programs] • an OS does not include GUI, nor CLICEG436

Page 5: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

5

OS as a Collection of …

• System Calls– Libraries– APIs

• Program and Configuration Files– /boot/vmlinuz, /boot/initrd– /etc/password, …, /etc/udev/*– /sbin/init, …

• Processes– Resident Kernel– Device Drivers– Interrupt Handlers

CEG436

Page 6: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

6

An Operating System in Action

• CPU loads boot program from ROM (e.g. BIOS in PC’s)• Boot program:

– Examines/checks machine configuration (number of CPU’s, how much memory, number & type of hardware devices, etc.)

– Builds a configuration structure describing the hardware– Loads the operating system, and gives it the configuration

structure• Operating system initialization:

– Initialize kernel data structures– Initialize the state of all hardware devices– Creates a number of processes to start operation (e.g. getty in

UNIX, the Windowing system in NT, e.g.)CEG436

Page 7: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

7

O.S. in Action (Cont’d)• After basic processes have started, the OS runs user programs, if

available, otherwise enters the idle loop• In the idle loop:

– OS executes an infinite loop (UNIX)– OS performs some system management & profiling– OS halts the processor and enter in low-power mode (notebooks)

• OS wakes up on:– Interrupts from hardware devices– Exceptions from user programs– System calls from user programs

• Two modes of execution– User mode: Restricted execution mode (applications)– Supervisor mode: Unrestricted access to everything (OS)

CEG436

Page 8: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 8

Control Flow in an OS

Operating System Modules

IdleLoop

From boot

Initialization

RTI

InterruptSystem call

main()

Exception

Supervisor ModeSupervisor Mode

Return to user mode

Return to user mode

Page 9: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

9

On Interrupts

• Hardware calls the operating system at a pre-specified location• Operating system saves state of the user program• Operating system identifies the device and cause of interrupt• Responds to the interrupt• Operating system restores state of the user program (if

applicable) or some other user program• Execute an RTI instruction to return to the user program• User program continues exactly at the same point it was

interrupted.

• Key Fact: None of this is visible to the user program

CEG436

Page 10: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 10

On Exceptions

• Hardware calls the operating system at a pre-specified location

• Operating system identifies the cause of the exception (e.g. divide by 0)

• If user program has exception handling specified, then OS adjust the user program state so that it calls its handler

• Execute an RTI instruction to return to the user program

• If user program did not have a specified handler, then OS kills it and runs some other user program, as available

Key Fact: Effects of exceptions are visible to user programs and cause abnormal execution flow

Page 11: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 11

On System Calls

• User program executes a trap instruction (system call)

• Hardware calls the operating system at a pre-specified location

• Operating system identifies the required service and parameters (e.g. open(filename, O_RDONLY))

• Operating system executes the required service

• Operating system sets a register to contain the result of call

• Execute an RTI instruction to return to the user program

• User program receives the result and continues

Key Fact: To the user program, it appears as a function call executed under program control

Page 12: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

12

High-level software architecture

CEG436

Operating System(process/device/memory management,

file systems, interprocess communication, …)

Operating System(process/device/memory management,

file systems, interprocess communication, …)

MemoryMemory

Instruction Execution & Interrupt ProcessingInstruction Execution & Interrupt Processing

User ApplicationsUser Applications

WindowSystem

WindowSystem

CommandInterpreterCommandInterpreter

I/O DevicesI/O Devices

“Middleware”“Middleware”

Page 13: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 13

Operating System Structures

• Monolithic OS (e.g., Unix) • Micro-kernel OS (e.g., Mach, Exokernel, …)

Memory ManagementMemory Management

CPU SchedulingCPU Scheduling

Process ManagementProcess Management

HardwareHardware

Network SupportNetwork Support

SecuritySecurity

File SystemFile System

Command InterpreterCommand Interpreter

Device ManagementDevice Management

Network Support

Network Support

MemoryMgmt.

MemoryMgmt.

WindowServer

WindowServer

FileServer

FileServer

......

HardwareHardware

CPUScheduling

CPUScheduling

Device Drivers

Device Drivers

InterruptHandler

InterruptHandler

Boot andInit.

Boot andInit.

Message PassingMessage Passing ……

APIAPI

Page 14: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 14

Microkernel architecture

Microkernel assigns only a small number of essential processes to the kernel, such as address space management, inter-process communication and scheduling, and provides all other services in separate processes called servers

Page 15: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

15

OS Summary

• An OS is just a “program”:– It has a main() function, which gets called only once (during boot)– Like any program, it consumes resources (such as memory), can

do silly things (like generating an exception), etc.• But it is a very strange program:

– It is “entered” from different locations in response to external events

– It does not have a single thread of control, it can be invoked simultaneously by two different events (e.g. system call & an interrupt)

– It is not supposed to terminate– It can execute any instruction in the machine

CEG436

Page 16: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

17

Process/Thread

• Processes– A process is a program in execution– It is a single, sequential thread of execution, a current state, and an

associated set of system resources• A process refers to the program being run and the context it is

running in• The context refers to all services and utilities, working

memory, file pointers, etc., that the program needs in order to run

• Executing a program involves the creation of a process by the OS by allocating some memory, loading the program code from a disk and starting it running

CEG436

Page 17: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

18

Processes and Threads• Process abstraction combines two concepts

– Concurrency• Each process is a sequential execution stream of instructions

– Protection• Each process defines an address space• Address space identifies all addresses that can be touched by the program

• Threads– Key idea: separate the concepts of concurrency from protection– A thread represents a sequential execution stream of instructions– A process defines the address space that may be shared by multiple

threads– Threads can execute on different cores on a multicore CPU (parallelism

for performance) and can communicate with other threads by updating memory

CEG436

Page 18: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

19

Threads vs. Processes• Threads• A thread has no data segment or

heap• A thread cannot live on its own, it

must live within a process• There can be more than one

thread in a process, the first thread calls main & has the process’s stack

• If a thread dies, its stack is reclaimed

• Inter-thread communication via memory.

• Each thread can run on a different physical processor

• Processes• A process has code/data/heap &

other segments• There must be at least one

thread in a process• Threads within a process share

code/data/heap, share I/O, but each has its own stack & registers

• If a process dies, its resources are reclaimed & all threads die

• Inter-process communication via OS and data copying.

• Each process can run on a

CEG436

Page 19: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

20CEG436

Implementing Threads

Page 20: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

21

Interrupts

• the basic form of time-sharing• provide the computer with a way of automatically running specific

code in response to events• When an interrupt is received, the computer hardware

automatically suspends running programs by pushing the current state on a stack and save registers and program counter

• The OS kernel decides how to deal with the event by running some code or ignoring it.

• The processing of hardware interrupts is a task that is delegated to software called “device drivers“ which is either part of the OS or another program or both

CEG436

Page 21: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

22

Multi-tasking

• refers to the possibility of the CPU time to be divided equally between the different running applications, switching each one in and out of memory

• A multitasking OS can switch CPU time from an application waiting for an I/O operation to be completed to one needing CPU time and back again without the user being aware

• Multi-tasking needs clearly defined processes by allowing different processes to be swapped

• OS kernel contains a piece of software called „scheduler“ which determines how much time each program will spend executing, and in which order execution control is passed

CEG436

Page 22: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 23

Multi-tasking challenges

• Improper synchronization– suspending and resuming execution requires signals to be

sent to/from different processes

– If these signals are lost or duplicated, the system crashes

– „fault tolerance“ is needed to cope with interrupted communication in wireless communications

• Failed mutual exclusion– two or more procesess compete to use the same resource

(e.g., data file)

• Non-deterministic program operation (aka non-Atomic operation)– interleaved programs sharing

• Deadlocks– two or more programs are waiting for each other to free a

resource before continuing

Page 23: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 24

Memory management• Multi-tasking systems need to move processes in and out of

memory effectively and efficiently (allocate memory dynamically to different programs as and when it is required) in order to avoid areas of memory being used by more than one program

• Process isolation– processes have their own memory and data and don not overlap

or interfere with each other

• Automatic allocation and management– memory is allocated as and when required transperantly

• Support of modular programming– allowing programmers to define multiple program modules and to

creat, modify, destroy them as required

• Protection and access control– allowing different programs to share memory locations as

required by the application and specified by the programmer, and protecting programs from accidental or malicious access violations

• Long term storage– process information so that programs and data files can be

restored when and as required

Page 24: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 25

Memory management - Virtual memory

• Virtual memory is a mechanism that enables the programmer to address memory in a logical way without needing to overly concerned with how much memory is physically available at run time

• Virtual memory allows multiple programs to run concurrently.

• Paging systems allows processes to be composed of fixed-sized blocks of memory (called pages)

• A program uses a virtual address (page number and an offset within the page)

• The paging system translates the virtual address into a real physical address in main memory

• The fixed size of pages allows them to be moved in/out memory

Page 25: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

26

Information protection and security

• Operating systems can provide facilities to support better security– Access control

• means to restrict which processes can have access to different parts of the system/ different data based on the user profile

– Information flow control• means for controlling the flow of data within the system and

its presentation to users

– Certification• means for ensuring that programs and data are authentic and

have not been tampered with

CEG436

Page 26: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 27

Scheduling and resource management

• Operating systems need to run multiple tasks concurrently without users being aware

– All concurrently running processes need to share the processor and memory and other resources

– Scheduling challenges• Fairness: programs with similar priority and requirements

profiles should have equal access to and time with any resource

• Differential responsiveness: at the same time, processes with different requirements need to be treated differently (priorities updated as program state change)

• efficiency: OS need to maximize throughput and minimize response time, support multi-users

Page 27: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

28

What Is Special About Mobile Operating Systems?

• A mobile OS need to support the effective and efficient functioning of a mobile device which is severely constrained.

• Physically constrained– battery-powered device– small screens of varying shapes, sizes, and resolutions– memory (clearly less than a laptop computer)– storage space

• Working in Uncertainty– Networks come and go– Other devices appear and disappear– OS need to provide robust methods for handling connections and coping with service

interruptions and ad hoc attempts to communicate• Psychological affordance

– Small devices, such as mobile phones, are most likely left unattended, forgotten or lost– It is not the job of the OS to provide a complete suit of security programs but it should

offer a number of utilities and services for security applications

CEG436

Page 28: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 29

What is special about mobile operating system (cont.)

– Wireless networking capable• Bluetooth (802.15)

• 802.11x wireless LAN

• HiperLAN2

• Telephony

• GSM

• GPRS

• 3G

• Data exchange using TCP/IP

– Location dependent• Utilities are needed for location and temporal awareness to

support devices operating in different places and times

• GPS support

• clock and calender support

• user profile support

Page 29: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 30

Mobile System requirements

• Processing power (energy)

– Mobile devices need to be small, light, compact and easy to use

– The heaviest part of mobile devices are batteries

– Power consumption of the mobile devices needs to be minimal

– Considerable improvements have been achieved in the size and longevity of batteries, increased battery life is mainly achieved by reducing the power demands of the device (power management)

• power saving capabilities -> power-source profiling

• data storage -> access speed and capacity

• backlighting

• power consumption per pixel

Page 30: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 31

Mobile Processors

• The ARM architecture (Advanced RISC Machine) is a 32-bit RISC processor architecture developed by ARM Limited that is widely used in embedded designs.

• Because of their power saving features, ARM CPUs are dominant in the mobile electronics market, where low power consumption is a critical design goal.

• Today, the ARM family accounts for approximately 75% of all embedded 32-bit RISC CPUs,

• Important branches in this family include Qualcomm Snapdragon, Marvell's XScale and the Texas Instruments OMAP series.

• Others include, e.g.,:– MIPS (Microprocessor without Interlocked Pipeline Stages) is a RISC

microprocessor architecture developed by MIPS Technologies. Mainly used in embedded systems like TiVo, Playstation1 & 2

– Intel Atom Processors for netbooks

Page 31: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

32Sep-05 32

A closer look at their processors

, Droid

The ARM instruction set architecture is surging to market prominence as the dominant standard for embedded CPU solutions

CEG436

Page 32: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

33Sep-05 33

A closer look at these Systems

CEG436

Page 33: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 34

Mobile System requirements

• Mobile devices need to be able to use a wide range of computer networks

– Bluetooth

– WLAN ( 802.11x or HiperLAN)

– 2.5 G or 3 G (voice and data)

• Ethernet access is achieved via some sort of docking

station or cradle connected to the desktop computer

Page 34: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 35

Mobile Memory• The memory on the CPU for buffers and I/O

management and stacks, the availability of the general purpose RAM and the memory of backing storage are all limited on mobile devices

• The better the memory management offered by the OS, the wider the options available to applications developers

• –Mobile devices have two types of memories– ROM

• for operating system and preinstalled programs

– RAM• for user information

• Types of RAMs– DRAM (Dynamic RAM): cheapest, used in

mobile devices– EDO (Enhanced Data Output): more

expensive but offers a speed increase of about 30% over DRAM (Windows CE)

– SDRAM (Synchronous Dynamic RAM): a further 50% speed (iPAQ)

– DDR (Double Data Rate) SDRAM is twice as fast as SDRAM

– OUM (Ovonics Unified Memory): experimental

Page 35: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 36

Mobile Storage

• Flash memory is non-volatile computer memory that can be electrically erased and reprogrammed.

– used in memory cards and USB flash drives for general storage and transfer of data in PDAs, laptop computers, digital audio players, digital cameras and mobile phones

– a specific type of EEPROM (Electrically Erasable Programmable ROM) that is erased and programmed in large blocks; in early flash the entire chip had to be erased at once.

– Flash memory costs far less than byte-programmable EEPROM and therefore has become the dominant technology wherever a significant amount of non-volatile, solid-state storage is needed.

• Compact Flash (CF) is a mass storage device format used in portable electronic devices. For storage, Compact Flash typically uses flash memory in a standardized enclosure.

• The format was first specified and produced by SanDisk in 1994.

Page 36: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 37

Execute-in-place (XIP)

• XIP is a method of executing programs directly from long term storage rather than copying it into RAM.

• It is an extension of using shared memory to reduce the total amount of memory required.

• Mobile devices reduces memory use and speed up program execution by using XIP

Page 37: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 38

Multimedia Supports

• Data that contains combination of text, digital still and video images and audio information

• Processing multimedia relies on low level binary operations that are best handled by the operating system

Page 38: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 3939

Smartphone OS Competitive Landscape

iPhone OS (Apple) BlackBerry OS (RIM)Window Mobile

(Microsoft) Android (Google) Symbian (Nokia)

Platform • Closed • Closed • Open • Open • Open

Source Code • Closed • Closed • Closed • Open • Open (in future)

Q2 WW Market Share (Gartner)

• 2.8% (1) • 17.4% • 12.0% • n/a • 57.1%

Smartphone traffic share (AdMob)

• WW: 4%

• US: 16%

• WW: 11%

• US: 31%

• WW: 13%

• US: 29%

• n/a • WW: 64%

• US: 2%

Pros • Early momentum

• Data hungry early adopters

• Powerful distribution channel

• Strong reach (particularly in US)

• Manufacturer / carrier agnostic

• Manufacturer / carrier agnostic

• Open source innovation

• Massive global reach

• Open source innovation

Issues • Apple dependant • BB dependent

• Distribution

• Distribution • Late to market

• Uncertain consumer demand

• Limited reach in US

• Distribution

Application ecosystem

• >3K apps (~20% free)

• More than 1M installs in only a few months

• Fewer free apps

• BB Application Center being developed for Storm

• >18K apps

• Skymarket to launch in 2009

• Android Market announced

• $3.8MM awarded in Developer Challenge

• >10K apps

• Claims >90MM installs over last 2 years

Notes: 1. Artificially low given the wait for the 3G iPhone (5.3% market share in Q1)

Page 39: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 4040

iPhone OS (Apple) – Starting with MAC OS X

•http://developer.apple.com/macosx/architecture/

Page 40: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 41

iPhone OS

• Iphone uses streamlined (quite complete ) version of Mac os X.

• It uses a Mach kernel, Unix userland, Cocoa frameworks, Mac OS X application bundles, and other vestiges of Apple’s NeXTSTEP derived desktop version of the Mac operating system.

• A number of desktop oriented concepts have been stripped, simplified, cleaned up, or refigured to support the unique needs of a mobile device with limited resources

• The iPhone’s Mach kernel uses the same I/O Kit architecture as Mac OS X, allowing Apple to reuse a lot of the mature code that is already proven to work on the Mac.

• The I/O Kit in Mach uses kexts or kernel extensions to add low level hardware support.

Page 41: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 42

 Layers of iPhone OS

• Cocoa Touch– Multi-touch events and controls– Accelerometer support– View hierarchy– Localization (i18n)– Camera support

• Media– OpenAL– Audio mixing and recording– Video playback– Image file formats– Quartz– Core Animation– OpenGL ES

• Core Services– Networking– Embedded SQLite database– GeoLocation– Threads

• OS X Kernel– TCP/IP– Sockets– Power management– File system– Security

iPhone SDKhttp://developer.apple.com/iphone/

Page 42: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 43

KERNEL EXTENSIONS:

• Apple has followed its own advice by using only two sets of kexts in the iPhone.

– The first sets up USB input, specifically for a user human interface device, and more specifically the multitouch screen:

• IOUSBDeviceFamily

• IOHIDFamily

• AppleMultitouchSPI

– The second pair of extensions relate to VPN or Virtual Private Networks. These extensions tie into the network stack to provide a way to securely tunnel encrypted traffic over a public network like the Internet.

• L2TP.ppp

• bPPTP.ppp

Page 43: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 44

Kernel: MAC vs iPhone

KERNEL FOR MAC OS X :

• Desktop Macs have kexts for the iSight camera, audio and video hardware, power and thermal management, and serial interfaces.

• Support for all hardware is implemented as a kext.

• On the Mac, different models have different hardware, so a modular set of plugin is required

KERNEL FOR IPHONE:

• No equivalent kexts present.

• Support for all of the hardware in the iPhone is built into the iPhone’s kernel.

• Currently no variety in iphone hardware.

Page 44: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 4545

iPhone OS (Apple)• Pros:

– Strong user growth and data-hungry user base

• More than 10 million iPhones sold

• 3.8% of worldwide smartphone web/data traffic and 7.8% in US (1)

– Application store creating a vibrant app ecosystem with great momentum

• More than 3K applications (~20% free)

• More than 1 million downloads

– Powerful technology enablers (e.g., multi-touch, GPS, accelerometer)

• Issues:

– App approval process is largely a black-box to developers

– Apps viewed as competitive to Apple are often shut down

– Downloads highly dependent on “featured” or “top download” promotion in store

– App store is the only authorized distribution channel

– Apple / hardware dependent

• Recent news / developments:

– NDA requirement: Apple finally removed the onerous NDA requirement

– Flash: signs pointing towards development of iPhone flash player

• Development resources:

– http://developer.apple.com/iphone/index.action

– http://iphoneincubator.com/blog/Notes:1. Source: AdMob internal metrics

Page 45: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 46

Android (Google)

• Open software platform for mobile development

• A complete stack – OS, Middleware, Applications

• An Open Handset Alliance (OHA) project

• Powered by Linux operating system

• Fast application development in Java

• Open source under the Apache 2 license

Page 46: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 4747

Android – Starting with Linux

Page 47: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 48

Linux Kernel

• Works as a HAL

• Device drivers

• Memory management

• Process management

• Networking

Page 48: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 49

Libraries

• C/C++ libraries

• Interface through Java

• Surface manager – Handling UI Windows

• 2D and 3D graphics

• Media codecs, SQLite, Browser engine

Page 49: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 50

Android Runtime

• Dalvik VM– Dex files– Compact and efficient than class files– Limited memory and battery power

• Core Libraries– Java 5 Std edition– Collections, I/O etc…

Page 50: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 51

Symbian

• Symbian is a company created by a consortium of four mobile phone companies, Nokia, Ericsson (now Sony-Ericsson), Motorola and Matsushita (Panasonic), and Psion, a long established palm-top computer manufacrurer

• Symbian is driven from a mobile phone perspective• Symbian emphasizes its non-properiatary, open platform for

wireless communications with particular emphasis on 2G, 2.5G, and 3G networks

• Sybian OS small footprint, modular, object oriented design and good support for scalability, it is suitable for use in embeded systems

• Symbian OS is fully object-oriented and component based.

Page 51: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 52

Symbian OS Architecture

Page 52: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 53

Symbian OS

• Micro-kernel uses client/server session based IPC

• Servers mediate access to shared resources and services

• Kernel deals with memory allocation and IPCs

• Proactive defense mechanism– Platform Security Architecture

– OS Services

– Data Caging

Page 53: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 54

Architectural Overview

• Core– Kernel, file server, memory management and device drivers

• System Layer– Communication and computing services e.g. TCP/IP, IMAP4, SMS and database management

• Application Engines

• User Interface Software

• Applications

• All layers communicate with each other using Client/Server Mechanism

Page 54: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 5555

Symbian (Nokia)• Pros

– Massive global reach• Leads WW market with 62% of smartphone traffic (1)

• 57% market share of smartphones sold in Q2 ‘08

– Like Android, being open source could help accelerate pace of innovation

• Issues

– Limited reach in the US

– Application distribution more difficult today vs. iPhone’s app store

• Recent news / developments:

– June ’08: Nokia announced plans to acquire full ownership of Symbian and start the Symbian Foundation, which will be an independent force for the future development of Symbian OS. They stated that Symbian OS (including the platforms S60, UIQ and MOAP(S)) will become open source in the first half of 2009

• Developer resources:

– http://www.forum.nokia.com/main/resources/technologies/symbian/Notes:1. Source: AdMob internal metrics

Page 55: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 5656

BlackBerry OS (RIM)• Pros:

– Large reach and data-hungry user base

• Leads US market with 31% of smartphone traffic (1)

• #2 in worldwide market with 11% of smartphone traffic (1)

– Developers not limited to single distribution channel

• Issues:

– Developer momentum appears to be shifting to iPhone

– Less reach outside of North America

– Application distribution more difficult today vs. iPhone’s app store

– Users more email focused vs. web consuming iPhone users

– RIM / hardware dependent

• Recent news / developments:

– BlackBerry Application Center scheduled to debut w/ BlackBerry Storm OS v4.7

– Speculation that Storm (i.e., touchscreen iPhone competitor) will be available in November

• Developer resources:

– http://na.blackberry.com/eng/developers/

– http://www.blackberrydeveloperconference.com/ (Oct. 20-22, Santa Clara)

– http://crackberry.com/Notes:1. Source: AdMob internal metrics

Page 56: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 5757

Windows Mobile• Pros

– Strong user reach

• #2 in US market with 30% of smartphone traffic (1)

• #2 in worldwide market with 13% of smartphone traffic (1)

– Manufacturer agnostic

– >18K apps

• Issues

– Current version in market (Windows Mobile 6) lacks support for some popular technology enablers (e.g., multi-touch, GPS, accelerometer)

– Next-gen version will be late to market

– Less developer enthusiasm vs. that for iPhone and Android

– Application distribution more difficult today vs. iPhone’s app store

• Recent news / developments:

– Microsoft to launch “Skymarket” applications marketplace for Windows Mobile 7 (planned for launch in 2H ’09)

– Speculation that Windows Mobile 7 will support revamped UI and multi-touch

• Developer resources:

– http://www.microsoft.com/windowsmobile/en-us/business/developers.mspxNotes:1. Source: AdMob internal metrics

Page 57: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

58

Models of Mobile and Distributed Systems

CEG436

Page 58: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

59

What is a Mobile Distributed System Model?

• A MDS model addresses:– What are the main entities in the Computing

System?– How do they interact?– What characteristics affect the individual & collective

behavior?• The purpose of the MDS model is to :

– Make explicit all assumptions about the system– Enable generalizations about the system, based on

these assumptions.CEG436

Page 59: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 60

Software and Hardware Service Layers

Applications, services

Computer and network hardware

Platform

Operating system

Middleware

Page 60: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 61

Distributed object management

Spanning layers

Network 1 Network 2

TCP UDP

Windows

TCP UDP

UNIX/Linux

Application

TCP UDP

Mac OS

Internet protocol

Spanning layer

Mobile TCPs UDP

Wireless Network

Mobile Platform

MobileIP

Page 61: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

62

Spanning layer

• Certain protocols are designed with the specific purpose of bridging differences at the lower layers, so that common agreements are not required there.

• Instead, the layer provides the definitions that permit translation to occur among a range of services or technologies used below. Thus, in somewhat abstract terms, at and above such a layer common standards contribute to interoperation, while below the layer translation is used.

• Real interoperation is achieved by the use of effective spanning layers.

CEG436

Page 62: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

Software Layers

• Software architecture – the structure of software as layers or modules in terms of services offered and requested between processes located in the same or different computers.

– Platform: the lowest-level hardware and software layers, i.e., Intel x86/Windows, Sun Sparc/SunOS, PowerPC/MacOS, Intel x86/Linux.

– Middleware: a layer of software whose purpose is to mask heterogeneity and to provide a programming model to applications, CORBA, Java remote object invocation (RMI), Microsoft Distributed Component Object Model (DCOM).

CEG436 63

Page 63: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

64

System Architecture: Client-Server Model

CEG436

Server

Client

Client

invocation

result

Serverinvocation

result

Process:Key:

Computer:

Dual roles— A web server is often a client of a local file server. Web servers and other Internet servers are clients of the DNS server which translates Internet domain names to network addresses. A search engine is a server, but it runs programs called web crawlers that access web servers throughout the Internet for information inquiries.

Page 64: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

65

Service Provided by Multiple Servers

CEG436

Server

Server

Server

Service

Client

Client

Servers may

partition the set of objects

maintain replicated copies of the entire set of objects on several hosts.

Page 65: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

66

Client-Server Architecture

CEG436

… invocation

invocation

Results

Results

Clients

Server

… invocation

invocation

Results

Results

ClientsService

Single-Server Multiple-Server

Page 66: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

67

Web Proxy Server

CEG436

Client

Proxy

Web

server

Web

server

serverClient

Web proxy servers provide a shared cache for client machines at a site or across several sites.

Page 67: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

68

Peer Process Architecture

CEG436

Coordination

Application

code

Coordination

Application

code

Coordination

Application

code

All the processes play similarroles, interacting cooperativelyas peers to perform tasks.

For example, a distributed whiteboardapplication allows users to view andinteractively modify a picture.

Page 68: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CEG436 69

VMinterpreter

Java program

Compilation

JITcompiler

Bytecode:low level butmachine independent

Native machineinstructions

Mobile code

Java virtual machine

Page 69: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

VM as a spanning layer• The virtual machine addresses some

problems in network distribution of applications:

– Different instruction sets and operating systems (portability)

– Network and GUI APIs (portability)– Security in downloading executables from

untrusted sources (policies)

• A price that is paid:– 10X (perhaps down to 3X) performance hit for

interpreted execution. This can be reduced using just-in-time (JIT) compilers and native Java processors.

• Typically applications are written in Java, which offers features (such as threading and garbage collection) coordinated with the VM definition. However, in principle an application could be written in a different language as long as an appropriate compiler is available.

CEG436 70

Java virtual machine

Operating system

Applications

JavaBeanscomponent framework

Page 70: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

71

Thin Clients and Compute Servers

CEG436

ThinClient

ApplicationProcess

Network computer or PCCompute server

network

Thin client: a software layer that supports a window-based user interfaceon a local computer while executing application programs on a remotemachine.

Advantage: low management and hardware costs at the client

Disadvantage: Delays are increased because of transfer of image and data between the thin client and the application process.

Page 71: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

72

Conventional Example of Thin Clients – X-11 Window Systems

• X-11 server provides an extensive library of procedures for displaying and modifying graphical objects.

• X-11 client is the application program a user is interacting with.

• The client program communicates with the server by invoking procedures using the RPC mechanisms.

CEG436

Page 72: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

73

New Example of Thin Clients – Mobile Smart Phone Systems

• Intending to provide a terminal for interaction with the Internet/Cloud.

• The client program communicates with the server by invoking procedures using the RPC mechanisms.

CEG436

Page 73: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

74

Fundamental Models

• Fundamental Models address important aspects of a Mobile distributed system, in abstraction.

• Interaction Model– Addresses communication and coordination between

processes• Failure Model

– Defines and classifies faults and methods of recovery or tolerance

• Security Model– Defines security threats and mechanisms for resisting them

CEG436

Page 74: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

75

Interaction Model

• Communication Performance• Latency

– Propagation delay: the time it takes for the first bit of a message to reach the destination.

– Transmission delay: the time interval between transmission of the first bit and the last bit of the message.

– Processing delay: the time it takes for the OS to process/send/ receive the message.

– Queueing delay: the time it takes a message to be queued either at end hosts or intermediate nodes waiting for transmission.

• Bandwidth: the total amount of information that can be transmitted over a given time.

• Jitter: the time difference between the delays incurred by different messages.

CEG436

Page 75: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

76

Interaction Model

• Clocks & Timing events– No global notion of time– Clock drift rates: the relative rate at which a computer

clock drifts away from a perfect reference clock.– Clock synchronization:

• Global positioning system (GPS): a few computers may use radio receivers to get time readings from GPS with an accuracy of 1 microsecond. They then send timing messages to other computers in their respective networks.

• Logical clocks: messages are time stamped with a sequence number that reflects their logical ordering.

CEG436

Page 76: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

77

Real-time Ordering of Events

CEG436

send

receive

send

receive

m1 m2

2

1

3

4X

Y

Z

Physical time

Am3

receive receive

send

receive receive receivet1 t2 t3

receive

receive

m2

m1

Page 77: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

78

Interaction Model

• Synchronous Distributed System– Each step in a process takes lb < time < ub– Each message is received within bounded time– Each local clock’s drift has a known bound

• Asynchronous Distributed System– No bounds on process execution– No bounds on message transmission delays– The drift rate of a clock is arbitrary– Internet is an asynchronous distributed system

CEG436

Page 78: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

79

Failure Model

• Omission failures– Process omission failure

• Crash – a process halts and does not execute any further operations; can be detected by timeout in synchronous DS

– In asynchronous systems, a timeout may be a consequence of process crash, extremely large message delays, or message losses.

• Fail-stop – a process crash is called fail-stop if other processes can detect certainly that the process has crashed.

CEG436

Page 79: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

80

Failure Model

• Omission failures– Communication omission failures

• Send-omission: loss of messages between the sending process and the outgoing message buffer

• Channel omission: loss of message in the communication channel.

• Receive-omission: loss of messages between the incoming message buffer and the receiving process

CEG436

Page 80: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

81

Processes and Channels

CEG436

process p process q

Communication channel

send

Outgoing message buffer Incoming message buffer

receivem

Page 81: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

82

Failure Model (cont’d)

– Arbitrary failures• Arbitrary process failure: arbitrarily omits intended processing

steps or takes unintended processing steps.• Arbitrary channel failures: messages may be corrupted,

duplicated, delivered out of order, incurs extremely large delays; or non-existent messages may be delivered.

– Timing failures• Clock failure: the process’s local clock exceeds the bound on its

drift rate from real time.• Process-time failure: process exceeds the bound on the interval

between two steps.• Channel-time failure: message transmission time exceed the

budgeted bound.

CEG436

Page 82: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

83

Omission and Arbitrary Failures

CEG436

Class of failure Affects DescriptionFail-stop Process Process halts and remains halted. Other processes may

detect this state.Crash Process Process halts and remains halted. Other processes may

not be able to detect this state.Omission Channel A message inserted in an outgoing message buffer never

arrives at the other end’s incoming message buffer.Send-omission Process A process completes a send, but the message is not put

in its outgoing message buffer.Receive-omission Process A message is put in a process’s incoming message

buffer, but that process does not receive it.Arbitrary(Byzantine)

Process or

channel

Process/channel exhibits arbitrary behaviour: it maysend/transmit arbitrary messages at arbitrary times,commit omissions; a process may stop or take anincorrect step.

Page 83: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

84

Timing Failures

CEG436

Class of Failure Affects DescriptionClock Process Process’s local clock exceeds the bounds on its

rate of drift from real time.Performance Process Process exceeds the bounds on the interval

between two steps.Performance Channel A message’s transmission takes longer than the

stated bound.

Page 84: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

85

Adaptations on Mobile Platforms

CEG436: Mobile Computing (PM)

Page 85: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

86

Mobile Applications must Adapt

• Need to adapt to heterogeneous, dynamic device/network status

• Need to optimize resource usage given that resources are often limited

Slides adapted from Wanghong Yuan, Klara Nahrstedt Richard Yang

CEG436: Mobile Computing (PM)

Page 86: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

87

Service Adaptation• Service delivered should depend

on– device status (e.g., display

capability, input method, memory size, remaining battery level)

– network status

• Adaptation needs the support of– the client, – the server, and/or – a third party (proxy or gateway)

• Server and third party adaptation is also called content adaptation

in-building

campus-area packet radio

metro-area

regional-area

CEG436: Mobile Computing (PM)

Page 87: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

88

Adaptation: Client Responsibility

• Client informs server its device capability and connection status

• Client makes best use of – available resources and – available result data

CEG436: Mobile Computing (PM)

Page 88: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

89

Content Adaptation

• Server/third party adapts service/content according to client capability

CEG436: Mobile Computing (PM)

Page 89: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

90

Client Adaptation

• Client Capability Negotiation and Monitoring• Make Best Use of Resources/Results

– Adaptive CPU scheduling– Adaptive playout

Page 90: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

Typical Power Usage

91

Page 91: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

92

Power Management

CEG436: Mobile Computing (PM)

Page 92: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

93

Dynamic Voltage Scaling (DVS)

• Voltage to be dynamically adjusted• DVS-enabled processors

– StrongARM SA-2 (500mW at 600MHz; 40mW at 150MHz)

– AMD (PowerNow!)http://www.amd.com/us-en/assets/content_type/DownloadableAssets/Power_Now2.pdf

– Intel (SpeedStep, XScale)– Texas Instrument– Transmeta

Page 93: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CPU Power Consumption Model• When the supply voltage V is lower, charging/ discharging

time is longer; thus frequency should be lower

f V• The power consumption rate P of a CMOS processor

satisfies

P = kCV2f

where k is a constant, C the capacitance of the circuit,f the CPU frequency, and V the voltage

• P V3

94

Page 94: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

95

Voltage Scaling

throughput

Page 95: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

96

Dynamic Voltage Scaling

• Basic idea: determining voltage according to program response time requirement

• For normal applications, give reasonable response time

• For multimedia applications, use the deadline to determine voltage

Page 96: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

97

Architecture

CEG436: Mobile Computing (PM)

CPU

monitoring scheduling

speed scaling

demand distribution

scheduler

speed adaptorprofiler

multimedia applications

requirements

time constraint

Page 97: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

98

Demand Prediction

CEG436: Mobile Computing (PM)

Online profiling and estimation: count number of cycles used by each job

cum

ulati

ve

prob

abili

ty

b1 b2Cmin=b0 br=Cmax

1

br-1

CDF F(x) = P [X x]

Page 98: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

99

CPU Resource Allocation

• How many cycles to allocate to a multimedia job?• Application should meet percent of deadlines

– each job meets deadline with probability – allocate C cycles, such that F (C ) =P [X C ]

CEG436: Mobile Computing (PM)

b1 b2 b0 br

1

br-1

cum

ulati

ve

prob

abili

ty

F(x)

C

Page 99: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

100

How Fast to Run the CPU?

• Assume the strategy is to run job i at a fixed speed Si

• Assume it needs Ci cycles during a time duration of Pi

• Fact: since power is a convex function of frequency, if a job needs C cycles in a period P, then the optimal frequency is C/P, namely the lowest constant frequency.

CEG436: Mobile Computing (PM)

Page 100: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

101

Why Not Uniform Speed?

• Intuitively, uniform speed achieves minimum energy if the allocated is used exactly

• However, jobs use cycles statistically– often complete before using up the allocated– potential to save more energy– stochastic DVS

CEG436: Mobile Computing (PM)

Page 101: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

102

Stochastic DVS

• For each job– find speed Sx for each allocated cycle x

• time is 1/Sx and energy is (1 - F(x))S3x

CEG436: Mobile Computing (PM)

such that

Page 102: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

103

Example Speed Schedule

CEG436: Mobile Computing (PM)

Job 12.5x106 cycles

spe

ed (M

Hz)

100

400

200

Job 21.2x106 cycles

Page 103: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

104

DVS

CEG436: Mobile Computing (PM)

spe

ed

A1 A1 B1B1 A1

A1

execution

speed upwithin job

context switch1. Store speed for switched-out2. New speed for switched-in

switch back

A2

Page 104: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

105

Example: Deal with Variable Delay

• Consider multimedia applications

• Packets arrive with variable delay (why?)

• Variable delay does not work well for multimedia application

CEG436: Mobile Computing (PM)

Page 105: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

106

Client Playout Buffer• Basic idea: delay playing out packets to accommodate delay jitter

• Question: how to determine the playout delay?

packetsnumber

time

packetsgenerated

p p'

delay0

1

r

packets received

Page 106: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

107

An Example Client Architecture

• Application requests service– registers a resource descriptor and an upcall event

handler with the OS• Operating system maintains/monitors available

resources– no need to have each application re-implement the

monitoring• OS notifies the application upon detecting resource

changes• Application adjusts requests to the server

Page 107: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

Content Adaptation: Audio

• Send a lower resolution stream as theredundant information, e.g. nominal stream at 64 kbps and redundant stream at 13 kbps (such as GSM)

108

2 3

Page 108: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

109

Content Adaptation: Video/Image

• Potentially many dimensions– frame rate (for video)– image size– quality of image

• Usage: e.g., data acceleration offered by many carriers

Page 109: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

110

Block Transform Frame Encoding

CEG436: Mobile Computing (PM)

DCT

Zig-zag Quantize

Run-length Code

Huffman Code

011010001011101...

Page 110: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

111

Example: MPEG Block Encoding

CEG436: Mobile Computing (PM)

139 144 149 153144 151 153 156150 155 160 163159 161 162 160

original image

DCT1260 -1 -12 -5-23 -17 -6 -3-11 -9 -2 2-7 -2 0 1

DC component

AC components

Quantize

79 0 -1 0-2 -1 0 0-1 -1 0 00 0 0 0

zigzag79 0 -2 -1 -1 -1 0 0 -1 0 0 0 0 0 0 0

run-length and Huffman encoding of the stream 10011011100011...

coded bitstream < 10 bits (0.55 bits/pixel)

Page 111: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

112

Examples

Uncompressed(262 KB)

Compressed(22 KB, 12:1)

Compressed(6 KB, 43:1)

CEG436: Mobile Computing (PM)

Page 112: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

Location Based Services (LBS)

Page 113: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

114

Content-Centric LBS

• Current LBSs are content-oriented and lack the logic necessary for user interactivity (no user models captured in the service)

• Content could be boring! And has limited impact as compared to interactions

• Content-centricity was not by choice, it was more of a constraint. Downloading content was what is available, and was challenging enough (e.g. WAP performance)

CEG436: Mobile Computing (PM)

Page 114: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

115

Precision of the Localization subsystem

• Cellular triangulation useful for some applications but inadequate for others.

• On-board GPS (e.g., Assisted GPS) offers better accuracy, but does not work indoors.

• “Locate nearest Pizza place!” era of LBS– Does not need accuracy– Outdoor!

CEG436: Mobile Computing (PM)

Page 115: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

116

Telecom-centric LBS

• Localization based information provided by telco; telco partners with other content providers (such as Verizon and Microsoft MSN)

• The centricity and encumbrance by telecom proved to be non-scalable and actually an impedance to the much-anticipated proliferation of the elegant LBS concept

CEG436: Mobile Computing (PM)

Page 116: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

117

Redefining LBS to be a framework

• As an application, LBS, gets a location, passes it to an authoritative server (@telco), and then delivers back location relevant information to the target. This is one application – very limiting.

• As a framework, LBS gets a location, passes it to servers provided by third parties, and then delivers back location relevant services (applications) to the target. This is unlimited number of applications. This is very flexible and much more exciting!

CEG436: Mobile Computing (PM)

Page 117: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

118

Impromptu Delivery of Apps

• Middleware and intelligent markup languages should be developed to enable the development of compact size code that takes only a few seconds to download and to get interpreted on a mobile device.

• Code not content: compact code gets interpreted to native computations utilizing native resources.

• Net effect: – A few seconds instead of tens of seconds or minutes in

delivery time– No installation, de-installation or management. – Applications appear & disappear.

CEG436: Mobile Computing (PM)

Page 118: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

119

Enable Indoor Localization

• More investment in indoor localization technology. • Standardizations • Solve Privacy issues• Bluetooth Example: Through the creation of a new

“Legalized Snooping” profile– Snoop protocol– Pay customer to snoop– Access to customer profile– On the fly tailored applications

• Technologies: Wi-Fi, Ultra wideband, or licensed frequencies.

CEG436: Mobile Computing (PM)

Page 119: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

120

Alter LBS Business Model

• Telco to sell and profit from basic services only (data pipe, SMS pipe, ..and perhaps application pipe in the future). Telco no longer defines LBS.

• Empower third party to transact LBS directly with end users, using Telco basic services. This is B2C with B2B embedding.

• Any business should be allowed to participate and offer LBS. A business should be able to develop “LBSlets” using simple LBS development kits.

• Businesses can host their own LBSs either directly or through a web hosting service.

• User to own and sell his/her LBS user profile.

CEG436: Mobile Computing (PM)

Page 120: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

121CEG436: Mobile Computing (PM)

Page 121: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

122

Major Challenge: Positioning

• GPS– Good accuracy, 10m– short battery life, hours

• GSM– Poor accuracy, 200-

400m– Long battery life, days

• WiFi / Skyhook– accuracy: 200-400m– battery: 16h E.g.,

SkyHook

• WiFi Location– Skyhook trucks war-drive a place

• Create map = <Location: WiFi IDs>• Distribute map to phones

– Phone user goes to a war-driven region, hears WiFi IDs

• Does a reverse Look Up

– At the cost of• Degraded location accuracy:

walking paths ~ 60m• Reliance on infrastructure (APs)• War-driving ($$ + carbon

footprint)• NYTimes claims Skyhook has a

fleet 500 trucks.

CEG436: Mobile Computing (PM)

Page 122: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

123

Assisted GPS (A-GPS)

• Typical in current cell phones.

• U.S. FCC's 911 mandate: location of a cell phone available to emergency call dispatchers

• Time To First Fix– GPS: 40-80 sec– A-GPS: 30 sec

• A-GPS uses– radio signals from GPS

satellites– precise coordinates of

cell towers– AGPS assistance servers

over cell/wi-fi network to utilize the satellites faster as well as better in poor signal conditions.

CEG436: Mobile Computing (PM)

Page 123: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

124

Skyhook Location Service• skyhookwireless.com/• software-only location system that quickly

determines device location with 10 to 20 meter accuracy.

• Skyhook Engine uses raw data from Wi-Fi access points, GPS satellites and cell towers and computes with advanced hybrid positioning algorithms.

• Skyhook maintains a worldwide database of cell tower locations, and Wi-Fi access points.

– Skyhook trucks war-drive a place– Create map = <Location: WiFi IDs>– Distribute map to phones– 250 million wi-fi access points and

covers 70 percent of population centers in the United States, Canada, Western Europe and Asia.

• Embedded into the MapQuest Android app

• Wi-Fi positioning performs best in urban areas and indoors.

• GPS provides accurate results in "open sky" environments.– indoors, tall buildings … block

view of satellites– GPS or A-GPS cannot provide

fast and accurate location results

• Cell tower triangulation provides generalized location results with only 200 - 1000 meter accuracy.

CEG436: Mobile Computing (PM)

Skyhook GPS A-GPS

Accuracy 10 m 10 m 30 m

Availability 99.8% 80.0% 95%

TT First-Fix 1 sec 65 sec 30 sec

Page 124: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

125

Other Approaches: CompAcc

• No War-Driving– Cannot drive walking paths (campus, parks, …)– Expensive / Environment unfriendly

• No reliance on WiFi infrastructure– Rural regions / developing countries

• Good accuracy (comparable to GPS)• Improve energy-efficiency

– Better than Skyhook, GPS

CEG436: Mobile Computing (PM)

Page 125: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

126

CompAcc: Basic Idea• Direction(compass) + Displacement(accelerometer) = User’s

directional trail

• Compute path signatures – Derived from a local electronic map (Google Maps)

• Compare directional trail with path signatures– Best match provides the user location

CEG436: Mobile Computing (PM)

Directional Trail

Path Signature …

Page 126: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

127

Path Signature … Directional Tra

il

Correct location errors at turns

CEG436: Mobile Computing (PM)

Page 127: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

128

Path Signature … Directional Tra

il

Correct location errors at turns

Directional Trail

Path Signature …

CEG436: Mobile Computing (PM)

Page 128: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

129

Advantages

• No war-driving• No reliance on WiFi

infrastructure– Maps available

ubiquitously

• Improves battery lifetime– GPS ~10h – Skyhook ~16h – Accelerometer ~ 39h – Compass ~48h

CEG436: Mobile Computing (PM)

Page 129: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

130

CompAcc Architecture

• Tile • Database

• Tile • Database

• 6. Current location

• (lat A, long B)• 2. Report initial location

(lat X, long Y)

• Tile

• 4. Direction(Compass)

• 5. Displacement(Accelerometer)

• 1. Initial location GPS:(lat X, long Y)

• CompAcc

• Initial location • Directional trail • Current location

• 3. Obtain paths in the user vicinity

CEG436: Mobile Computing (PM)

Page 130: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

131

Directional trail: displacement

• displacement = Accelerometer-step-count * step-size

CEG436: Mobile Computing (PM)

Page 131: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

132

Directional trail: direction

CEG436: Mobile Computing (PM)

Page 132: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

133

Directional trail: direction

CEG436: Mobile Computing (PM)

Page 133: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

134

Path Signature

• Extract from Google Maps• Geodesic formulas

CEG436: Mobile Computing (PM)

Page 134: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

135

Matching Directional Trail with Path Signatures

Dissimilarity Metric:

ci = compass readingspi = path computed directionN = directional trail size

Directional Trail

Path Signature

CEG436: Mobile Computing (PM)

Page 135: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

CompAcc Results

CEG436: Mobile Computing (PM) 136

Page 136: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

Results • Average ALE• GPS: 10m• CompAcc: 11m• WiFi-War-Walk: 30m• Skyhook: 70m

• Energy • GPS: 10h• CompAcc: 23h• WiFi-War-Walk:16h• Skyhook:16h

CEG436: Mobile Computing (PM) 137

Page 137: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

138

g GPS, s Skyhook, c CompAcc

CEG436: Mobile Computing (PM)

Assume GPS is absolute truth

Page 138: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

139

CompAcc

• Today’s localization technologies limited– Energy- Efficiency– Coverage/Accuracy

– Rely on simple localization mechanism – Need: Compass, Accelerometer and Maps

• Evaluation results: – ALE: 11m – Battery: 23h

• CompAcc scales to any mapped part of the world CEG436: Mobile Computing (PM)

Page 139: Mobile OS and Mobile Service Architectures Prabhaker Mateti CEG4361

140

References

• Constandache, Choudhury, Rhee, “CompAcc: Using Mobile Phone Compasses and Accelerometers for Localization”, IEEE Infocom, March 2010.

• Wanghong Yuan, Klara Nahrstedt, Energy-Efficient Soft Real-Time CPU Scheduling for Mobile Multimedia Systems

CEG436: Mobile Computing (PM)