Anjana Sangwan

Assistant Professor
Department of Computer Science and Engineering
SKIT-Jaipur

1
Presentation Outline
 What is mobile computing?
 Comparison to wired networks
 Why go mobile?
 Types of wireless devices
 Mobile objects
 Moving object databases (MOD)
 Query language for MOD
 Applications of mobile computing
 Challenges
 Future of mobile computing
 Conclusion

2
What Is Mobile Computing?
 What is computing?
Operation of computers (according to oxfords
advance learner’s dictionary)
 What is the mobile?
That someone /something can move or be moved
easily and quickly from place to place
 What is mobile computing?
Users with portable computers still have network
connections while they move

3
What Is Mobile Computing? (Cont.)
 Is using a digital camera “Mobile Computing”, or
using an MP3 player or handheld computer (e.g.
3Com’s Palm Pilot or Compaq’s iPAQ 3660)?

4
What Is Mobile Computing? (Cont.)
 A simple definition could be:
Mobile Computing is using a computer (of one kind or
another) while on the move
 Another definition could be:
Mobile Computing is when a (work) process is moved from a
normal fixed position to a more dynamic position.
 A third definition could be:
Mobile Computing is when a work process is carried out
somewhere where it was not previously possible.

5
What Is Mobile Computing? (Cont.)
 Mobile Computing is an umbrella term used to
describe technologies that enable people to access
network services anyplace, anytime, and
anywhere.

6
Comparison to Wired Net.
 Wired Networks  Mobile Networks
- high bandwidth - low bandwidth
- low bandwidth - high bandwidth
variability variability
- can listen on wire - hidden terminal problem
- high power machines - low power machines
- high resource machines - low resource machines
- need physical - need proximity
access(security) - higher delay
- low delay - disconnected operation
- connected operation

7
Why Go Mobile?
 Enable anywhere/anytime connectivity
 Bring computer communications to areas without
pre-existing infrastructure
 Enable mobility
 Enable new applications
 An exciting new research area

8
Types of Wireless Devices
 Laptops
 Palmtops
 PDAs
 Cell phones
 Pagers
 Sensors

9
What is Mobile Computing?
 Computing enabled by presence of wireless
enabled portable devices (PDAs, cell phones)
 Some other names
 Pervasive computing
 Ubiquitous computing
 Wireless computing
 Embedded computing
 Wireless communication is needed
 Focus on logical aspects of mobile communication
 What kind of application can be enabled by mobile
computing?
 Design issues in mobile application and system
What is Mobile Computing?

 Mobile Computing
 Computing Platforms: PDAs, Smartphone, Pocket
PCs, Tablet PCs, Laptops
 Networked embedded processors & apps
 Information & computing anytime, anywhere
 Distributed computing
 Nodes (computers)
 Communications
 Computing tasks
Mobile Computing Applications
 Email
 Internet access
 Personal Information Management (PIM)
 Instant Messaging
 Data & information access
 Context-aware applications
 Audio streaming
 Video streaming
 Cell phone
 VoIP via WiFi
Mobile Computing Applications
 Pervasive/ubiquitous computing: computing everywhere
 Home appliances: refrigerator, washer/dryer, thermometer,
 microwave, dishwasher, what else - rumba the vacuum cleaner
 Mobile devices: laptop, PDA, PocketPC, iPhone, cell phones
 Home electronics: TV, DVD player, satellite TV set-top boxes, cd
 players, Stereos, iPod, Gameboy/Sony psp/Nintendo DS
 Location positioning devises – GPS, MPS
 Automobiles – every modern car is a network of computers
 Tags – RFIDs, SmartCards
 Sensor network and Smart Dust
 Smart homes, wearable computing, ….
 Mobile Objects
 A mobile object is some
code that carries a state

14
 Mobile Objects (Cont.)
 A mobile object is some
code that carries a state
 that lives on a host

15
 Mobile Objects (Cont.)
 A mobile object is some
code that carries a state
 Lives in a host
 That visits places

16
 Mobile Objects (Cont.)
 A mobile object is some
code that carries a state
 Lives in a host
 That visits places
 which is let in when
trusted

17
 Mobile Objects (Cont.)
 A mobile object is some
code that carries a state
 Lives in a host
 That visits places
 which is let in when
trusted
 and barred when untrusted

18
 Mobile Objects (Cont.)
 A mobile object is some code
that carries a state
 Lives in a host
 That visits places
 which is let in when trusted
 and barred when untrusted
 and will refuse to go to
untrustworthy places

19
 Mobile Objects (Cont.)
 Mobile objects can talk to
their friends

20
 Mobile Objects (Cont.)
 Mobile objects can talk to
their friends
 but only by co-operation
of the hosts

21
Moving Object Databases (MOD)
 Deals with Mobile Objects whose geometry, position
changes over time
 Traditional DBMS alone is incapable for this purpose
 MOD is built on top of existing DBMS to support a
critical set of capabilities

22
Moving Object Databases (MOD)
(Cont.)
 DOMINO (Databases for Moving Objects Tracking)
Approach
 System Architecture

DOMINO
ArcView GIS
Informix DBMS

23
Moving Object Databases (MOD)
(Cont.)
 Omnitracs
- developed by Qualcomm
- Is a commercial system used by the transportation
industry
- Provides location management by connecting
vehicles, via satellites, to company DB
- Vehicles are equipped with GPS, and they they
automatically and periodically report their
location

24
Query Language for MOD
 Regular query language (SQL) is nontemporal
 For MOD we need Spatial and Temporal Query
language
 “Where is the nearest station?”
 “What is the distance of the closest taxicab?”

25
Query Language for MOD
(Cont.)
 Some proposed query language:
- Future Temporal Logic (FTL)
- MobSQL
 SQL like query languages with specific predicates and
operators to address temporal issues

26
Query Language for MOD
(Cont.)
 What is the nearest station?
SELECT station.name, station.address
FROM station in Stations
WHERE NEAREST (HERE,station);
 “At what time truck 12A arrive to Windsor ”
SELECT t
FROM v in Trucks, c in Cities
WHERE v WITHIN(t) c and v.id = 12A
and c.name=Windsor
27
Applications of Mobile
Computing
 Emergency services

28
Applications of Mobile
Computing (Cont.)
 For Estate Agents
 In courts
 In companies
 Stock Information Collection/Control
 Credit Card Verification
 Taxi/Truck Dispatch
 Electronic Mail/Paging

29
Challenges
 Disconnection
 Low bandwidth
 High bandwidth variability
 Low power and resources
 Security risks
 Wide variety terminals and devices with
different capabilities
 Device attributes
 Fit more functionality into single, smaller
device
30
Future of Mobile Computing
 Use of Artificial Intelligence
 Integrated Circuitry -> Compact Size
 Increases in Computer Processor speeds

31
Conclusion
 Mobile computing has severe limitations
- however, it is far from impossible, and technology
improves all the time
 Lots of challenges
- some have (good) solutions, many others are still
waiting to be solved

32
References
 Papers:
- “Moving Object Databases: Issues and Solution” by Ouri Wolfson,
Bo Xu, Sam Chaamberlain and Liqin Jiang
- “DOMINO: Databases for Moving Objects Traking” by Ouri
Wolfson, Bo Xu, Sam Chaamberlain, Liqin Jiang and Prasad Sistla
- “MobSQL, An SQL Like Query Language for Mobile Objets
Databases” by Ahmed Lbath and Mourad Ouziri
 WWW Links:
- http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol4/
vk5/report.html
- http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol1/vk5/article1
.html
- http://www.cs.ucsb.edu/~ebelding/courses/284/w04/slides/intro.
pdf
- http://www.ansa.co.uk/ANSATech/ANSAhtml/98-
ansa/external/9807tb/9807mose.pdf
- http://www.danishtechnology.dk/it/9238

33
Mobile Computing?
 Computer History
 Mainframe, Microcomputers, Microcontrollers
 Networking
 Dialup, TCP/IP, Ethernet LAN, WAN, Wi-Fi,
 Client-Server Computing
 Web server, File Server, Database server
 Distributed Computing
 Grid computing
 Peer-to-peer Computing
 Mobile Computing
Mobile Computing Applications
User Groups
 Cellular phone/VoIP
 Personal Information Management (PIM)
 Mobile Internet Access
 Mobile Multimedia Entertainment
 Business User Applications
 Mobile Enterprise
 Retail/Supply Chain
 Intelligent Transportation
 Maintenance and Field Service
 Healthcare
 Homeland Security/Emergency
 Military
Mobile Computing Constraints
 Resource-poor
 Battery packs
 Hardware: Memory, CPU, peripherals
 Software
 Battery lifetime will see very small
increase
 Need energy efficient hardware and
system software
 Planned disconnections – doze mode
Mobile Computing Constraints
 Less secure and less reliable
 Lost or stolen
 Hostile or unfriendly environment
 Mobile connectivity
 Dynamic changes in environment:
infrastructure
 Highly variable: bandwidth, latency
 Reliability: disconnections
What Needs
 Operating to be Reexamined?
systems
 File systems
 Database systems
 Programming Languages
 Communication architecture and protocols
 Hardware and architecture
 Real-Time, multimedia, QoS
 Security
 Application requirements and design
Adaptability – the Key to Mobile Computing
 Scenario – searching for information
 Adaptive to location, user’s preference
 Scenario - Video streaming application
 Adaptive to available resource, video contents
 Continuous streaming
 Routing video stream packets
 Access points
 New IP address
Adaptability – the Key to Mobile Computing
 Vision
 Adapt to dynamic changes in environmental and
system conditions
 System agility
 speed and accuracy with which an adaptive application
detects and responds to change in computing environment
 Roam seamlessly
 Perform computing and communication task
uninterrupted
 E.g., mobile video streaming
 Less human intervention
Adaptability – the Key to Mobile Computing
 Fundamental to mobile computing is various
techniques in hardware/software to adapt to
resource availability
 Take into account contextual information including
user preferences
 Wireless sensor networking is enabling
technology for pervasive/ubiquitous computing
 Middleware deals with the heterogeneity of the
mobile devices.
 Who should be responsible for adaptation
 system or application?
 Application transparent or application aware?
Application Transparent
 Transparency – the ability of system to hide
some characteristics of underlying
implementation from users.
 Access transparency
 Location transparency
 Failure transparency
 Application works with no modification in mobile
environment
 Proxy can be provided to hide the differences
between the stationary and mobile environment
from applications.
 Adaptive system is responsible for adaptation
Constraints of mobile computing
environment
 Mobile computers can be expected to be more
resource –poor than their static counterparts.
 mobile computers are less secure and reliable.
 mobile connectivity can be highly variable in terms of
its performance(bandwidth and latency) and
reliability.
Application-Aware Adaptation
 Adaptive system is responsible for adaptation
 Does application-transparent way of adaptation suffice in mobile
computing?
 Performance issue, difficult for system adaptive to different
applications, manual intervention may be needed
 Allows Applications to react to mobile resource changes
 How?
 Collaboration between System and individual Applications
 System monitors resource levels and notifies applications of
relevant changes
 Application then adapts to the change
Application-Aware Adaptation
 Multimedia Application
 Applications
 Video Conferencing on mobile devices

 Watch live video from Remote server on mobile devices

 Operating condition changes

 Move/bandwidth changes

 Request other peer/server

 Lower quality video

 Battery power level changes

 Conserve energy

 Reducing the intensity of the back light (display)

Laissez-faire apporach
 It is not desirable because it puts too much burden on
the application developer.
 Further, no support from the underlying system
restricts the types of adaptation that can be
performed.
Application-aware adaptation
There are two extreme approaches to designing adaptive
system:
 Application-transparent :- the system is fully
responible for adaptation
 Laissez-faire:- the system provides no support at all
Application-transparent
 In the application –transparent apporach ,the
responsibility of adaptation lies solely with the
underlying system.
 On the other hand ,in the application –aware
approach, the application collaborates with the
underlying system s/w.
 Here the system provides status information about the
available resources.
 The application uses this info to make decision on
how to adapt to changes in the resource availability.
Spectrum of adaptation strategies
Application aware
(collaboration b/w system and application)

Laissez- Application-
faire(no system transparent(no
support) changes to
Mechanism for Adaptation
 Mechanisms for adaptation
 Adapting Functionality of Mobile Application
 Adapting Data – delivered
 Adapting Functionality
 Classic client-server systems assume
 location of client and server hosts do not change
 connection among them does not change

 Functionality between client and server is statically

partitioned
 Varying the Partition of duties in Client-Server model in
mobile computing
 Connected - Client-Server (CS) model
 Disconnected – Mobile client works autonomously
Adapting Functionality
 Change dynamically the functionality of the
computational entities
 Client/Server
 Resource-poor mobile client requests a resource-rich
server to perform expensive computation
 Request-Response model
 Services
 Web pages ← Web servers
 Database server
 Temporary IP addresses
 Name translation
Adapting Functionality
 Extended Client/Server
 Maintain the state of the clients: hard state, soft state
 Soft state
 Updated periodically to avoid automatic deletion
 Useful in systems with dynamic configurations

 Soft state used in

 Resource Reservation Protocol (RSVP, RFC 4604, 4605)
 Internet Group Management Protocol (IGMP)

 Request service → Sleep (conserve energy) → Wake

up (get result)
Adapting Data
 Varying the quality of data (fidelity)
 Quality of Service (QoS) requirements in
information access application
 Information quality
 Performance
 Latency: from the Mobile client’s perspective
 Throughput: from the system’s perspective

 Data maintained at remote server

 Reference copy
 Complete and Up-to-date
 Mobile client – may choose to access or
manipulate data item of lower fidelity
Adapting Data
 Fidelity
 Agility
 Speed and accuracy with which the application detects
and responds to changes
 Consistency
 Data quality
 Video data – frame rate and image quality
 Telemetry data – sampling rate and timeliness
Adaptations How To
 Adaptive to detectable changes in their
environment
 Software detects changes
 Middleware layers or Operating system
 E.g., TCP protocol
 State-based approach
 Changes in mobile computing are viewed as State
Transitions (e.g., Coda)
 Strongly connected
 Weak connectivity
 Weak connectivity/Disconnected → Strong connectivity
 Disconnected
 Adaptation of function and/or data performed when a
state transition occurs.
Where ? Adaptations
 Client /Proxy/Server
 Adapting to the hardware/software capabilities – in
the proxy and/or at the server
 Adapting to the connectivity of the mobile device: at
the server and/or the client
 Adapting to the resource availability at the mobile
device: at the client
Where ? Adaptations
 Proxies:
 Filtering data and connections (security firewalls)
 Modifying control data (network address translator)
 Transcoding (converting data, content transformation)
 Proxy reduces Bandwidth demands and allow legacy
and non standard client to communicate with the
server
Adapting functionality
 The first approach is to change dynamically the
functionality of the computational entities involved in
response to the change in the operating conditions.
Example of this is CS model.
CS model
 In the standard CS model, the roles of the client and
server are defined usually at design time, and remain
fixed during operation of the system.
 A client or the underlying system- middleware-may
select dynamically the server from which to request
the service.
 A server may or may not maintain information or
state, about the client to which it is providing service.
 The state info may be maintained as soft or hard.
 Soft state information,once installed,has to be
updated periodically to avoid automatic deletion by
state maintainer(server).It is useful in systems with
very dynamic configurations, such as mobile
systems.eg: Resource Reservation
Protocol(RSVP),IGMP.
 Hard state information,once installed,requires
explicit deletion.
Adapting data
 Another way to adapt to resource availability is by
varying the quality of data(fidelity) that is made
available to the application running on the mobile
client.
 Fidelity is defined as the “degree to which a copy of
data presented for use at the client matches the
reference copy at the server “
Tha QoS requirements for such application
 Information quality: Ideally, a data item being
accessed on a mobile client should be
indistinguishable from that available to the
application if it were to execute on the server
storing the data.
 Performance:
1) From the mobile client’s perspective, Latency of
data should be within tolerable limits.
2) From the system’s perspective,throughput of the
system should be maximized
 It is difficult to provide both high-
performance and highest quality
information in mobile computing
environment.
Fidelity and agility
 Data fidelity has many dimensions depending on its
type. Consistency is a dimension which is shared by all
data.
 The other dimensions are type-dependent
1. Video data- frame rate and image quality
2. Spatial data such as topographic maps-minimum
feature size
3. Telemetry data- sampling rate and timeliness
agility
 It is define as the speed and accuracy with which an
adaptive application detects and responds to changes
in its computing environment.
 The larger in change ,the moreimportant agility.
 For eg an adaptive system that tries to adapt to the
availability of connection bandwidth can try to
determine how well the system reacts to sudden
changes in bandwidth.
How to develop or incorporate adaptations in
applications:

 coda(continued data availability):

 Clients are called VENUS maintain a local cache.
 Hoarding(strong connectivity)
 Emulating(diconnected)
 Write-disconnected(weak connectivity)
 Reintegration(diconnected->strong conncetivity)

66
A Glimpse of the Future
 Imagine you are a tourist in Paris
 with a wearable computer

 wireless access to remote services

 unobtrusive heads-up display, microphone,

earphones
 speech for computer interactions

 online language translation

 Let’s go . . . . . .
67
 What Makes This Science Fiction?

 Lack of hardware?
 No! We have what we need.

 Lack of applications?
 Nope - we have those too.

 Need a system capable of coping with the problems of mobility

 Odyssey to the rescue...

68
Problems

with Mobility
Mobile elements are resource-poor
 relative to static elements of same era
 weight, power, size constraints

 Mobility leads to communication uncertainty

 enormous variation in bandwidth & latency
 intermittent connectivity

 Power management is a concern

 actions may have to be slowed or deferred
 communication costs energy

 need to rely on resources of remote servers,

 but may not be able to reach them!
69
Adaptation is Key
 Highly dynamic environment – adaptation key to
good performance

 Who adapts?
 System?
 take advantage of good times
 Behave ok during bad times
 CODA

 This paper: applications also must adapt

 Change expectations depending on surrounding state
 End to end argument?

70
 Client Adaptation

 Make mobile clients more robust by offering

adaptation
rely on servers when possible
function autonomously if needed
monitor and adjust to current conditions
Change application expectations

71
 Adaptive Applications

 applications consume resources

network bandwidth, CPU cycles, battery power, disk space,
$$$

 resources are variable

 …so…

 applications adapt use of resources as resource

quality changes

72
 Who Controls Adaptation

 The Operating System?

 Individual applications?

 Both!

 … Application-Aware Adaptation

73
Application-Aware Adaptation
 Application only (laissez faire)
 What if different applications compete for the
resources?

 OS only (application-transparent)
 Does not differentiate between applications (student
viewing a video of a lecture vs. a video
teleconference)

 Joint responsibility in Odyssey (application-aware)

 Several ways to divide the functionality – odyssey 74
What Knobs Do We Have?
 Where work gets done
 let powerful remote servers do the work

 How snazzy the data is: “Fidelity”

 degrade data meaningfully before giving to mobile host

 Fidelity has many dimensions

 one is universal: consistency
 others depend on data type
 movies: frame rate, frame quality
 geographical databases: feature set, minimum feature size
 tradeoffs are application-dependent

 Discussion – anything else?

75
76
Applications
Video
 server offers movie at several levels of fidelity
 application plays the track that the current bandwidth can support
 xanim: split into client and server

 WWW
 “distillation server” degrades data before shipping to client
 images can be compressed
 HTML can be summarized
 Netscape: client-side proxy + remote distillation server

 Speech Recognition
 local/remote/hybrid execution
 Janus: support remote recognition method, hybrid

 Other?
77
 Odyssey
A Platform for adaptive mobile data access

• Built a prototype for Un*x as OS extension

• Provides a small API to the application

• Implementation:
• Need a central component for resource monitoring
and management (Viceroy)
• Need data aware components that offer fidelity
choices (Wardens)

78
Viceroy and Wardens
 System-level data differentiation through wardens
 specialized code components (a la device drivers)
 provides system-level support to manage a data type
 trusted entities (unlike applications)

 Wardens subordinate to viceroy

 single, central component
 type-independent, system-level support
 responsible for all resource allocation, arbitration
 central point of authority and control for Odyssey

79
Odyssey Architecture

Application Web
Warden
viceroy
Odyssey runtime Video
warden
Odyssey calls
Upcalls
Sys calls
Tsop,
kernel Interceptor request

80
Resource Negotiation
 Applications give viceroy a window of tolerance for some resource
 viceroy monitors resource availability
 if it leaves window, notifies application via upcall

Fid. 1 Fid. 2 Fid. 3 Fid. 4

Available bandwidth

 Currently focus only on network bandwidth; what are other

resources of interest?

81
Viceroy
 Monitors resources and notifies applications of any
changes in resource levels
 Does this apply to non-mobile applications?
 Viceroy acts as a single point of resource control

 Applications must be able to specify what changes

of resources are of interest to them
 Reporting everything is too expensive since it crosses
the OS to user boundary
 Solution – application specifies a window of
tolerance in a resource request system call
 Viceroy does an upcall if resource availability moves
outside the window
82
Wardens
 Wardens are code components that manage type
specific operations
 Wardens manage communication with the various
servers
 They also offer the fidelity menu to applications
 Type specific operations can be customized using
wardens (e.g., caching)
 To avoid API explosion, one system call (type-
specific operation tsop() is provided
 Tsop is similar to the un*x ioctl()
 Can also be used to request type specific operations
83
 Operational Model
 Control loop:

1. Select fidelity
(application)

1. Place request (system

call)

1. Detect change

1. Notify application

84
Agility
 An Odyssey client must estimate the quality of network paths used
by various applications.

 Odyssey records:
 Round-trip time
 Throughput

 Odyssey updates its estimates of latency and bandwidth once every

half second.

 Aside, Noble’s group followed up with agility estimation work for

ad hoc networks

85
Agility (cont.)

86
Agility (cont.)

87
Stability
 Pursuing agility while completely sacrificing
stability can be counterproductive.
 Rapidly switching
 Low-fidelity
 Variable latency
 Stability is properly incorporated by individual
application.
 When notifying an application , the viceroy can
include information about the expected variance of
estimate.
88
Client/Server Computing
Cache Coherency:
- cache invalidation server Client
- update propagation cache State

client Request
cache Server
Client Reply

Sockets Sockets
TLI TLI
RPC
Fixed Network RPC

RMI RMI

89
Client/Server Design
 Stateless/stateful client/server design
 Caching and cache invalidation
 server invalidates client cache and/or
 client requests server to validate its cache.
 file system caching: writes => update propagation
 Connectionless/connection-oriented design
 TCP/IP & Interfaces
 Other issues: multi-threading &deadlocks

90
Fixed Network C/S
Assumptions
 Client Connectivity
 client is always connected with availability
comparable to the server’s. Server can always
invalidate the client cache
 Server Availability & Reliability
 server is highly available. Reliable if stateless (but
state info is exchanged in every C/S interaction), or if
implements recovery procedures (may require client
availability)
 Network
 fast*, reliable*, BER < 10-6, bounded delay variance

91
Taxonomy of C/S Adaptations
 System-transparent, application-transparent
 The conventional, “unaware” client/server model

 System-aware, application-transparent
 the client/proxy/server model

 the disconnected operation model

 System-transparent, application-aware
 dynamic client/server model

 the mobile agent (object) model

 System-aware, application-aware

92
The Unaware Client/Server
Model
 Full client on mobile host and full server on fixed
network (SLIP/PPP C/S)
 Client and Server are not mobility-aware
 Client caching does not work as the client can be
disconnected when the server invalidates the cache
 Not reliable and of unpredictable performance
 Requires special cache invalidation algorithms to
enable caching despite long client disconnections

93
The Client/Proxy/Server
Model
 Adding mobility-awareness between the client and
the server. Client and server are not mobility-aware.
 Proxy functions as a client to the fixed network server,
and as a mobility-aware server to the mobile client
 Proxy may be placed in the mobile host (Coda’s
Venus), or the fixed network, or both (WebExpress)
 Application- and user-dependent
 One advantage: enables thin client design for
resource-poor mobile computers

94
Thin Client/Server Model

Keyboard and mouse events

Thin
Server
Client
Display events
 Thin client fits in resource poor info appliances
 Bounded communication
 Requires at least weak connection
 CITRIX WinFrame and ICA thin client
 InfoPad

95
The Disconnected Operation
Model
 Approach I:
 Provide full client and a thin version of the server on
the mobile platform. In addition, needed data is
replicated into the mobile platform. Upon
reconnection, updated replicas are synchronized with
the home server. Conflict resolution strategies are
needed (Coda/Venus & Oracle Lite)
 Approach II:
 Provide a full client and a mobility agent that intercepts
requests to the unreachable server, emulates the server,
buffers the requests, and transmit them upon
reconnection (Oracle Mobile Agents)
96
The Dynamic Client/Server
Model
 Servers (or their thin versions) dynamically relocate between
mobile and fixed hosts. Proxies created and relocated dynamically
 A spectrum of design and adaptation possibilities
 Dynamic availability/performance tuning

97
Dynamic Client/Server Model
 Mobile objects:
 applications programmed with dynamic object relocation policies for
adaptation (Rover’s RDOs)
 Collaborative Groups:
 disconnected mobile clients turns into a group of collaborating, mobile
servers and clients connected via an ad-hoc net. (Bayou architecture)
 Virtual Mobility of Servers:
 servers relocate in the fixed network, near the mobile host,
transparently, as the latter moves.

98
File System Proxy in Coda

 Disconnected operation (Venus): hoarding, emulating, reintegrating

 Weakly connected operation: both object and volume call-backs
 Isolation-Only Transactions

99
 Isolation-Only Transactions
in Coda

 Isolation-Only Transactions (ACID): no failure atomicity guarantees. Also

Durability is guaranteed only conditionally.

100
Web Proxy in WebExpress

The WebExpress Intercept Model

101
Wireless Web Browser
in Mowgli

102
Thin Client InfoPad
Architecture

103
Case Studies
 Bayou
 Odyssey
 Rover

104
Case Study1: Bayou
 Main Features
 Novel Aspects
 Bayou architecture
 Bayou application-specific conflict resolution
 Bayou replication management

105
Main Features of Bayou
 Replicated, weakly consistent storage system for
collaborative applications
 Ad-hoc network of portable computers participate in
managing a mobile, replicated storage system
 Suitable for a group of collaborators, all mobile and
disconnected from fixed network, sharing
(reading/writing) appointment calendars, meeting
notes, evolving design documents, etc.

106
Novel Aspects of Bayou
 Support for application-specific detection and resolution of update
conflicts
dependency checks
client-provided, per-write conflict resolution (merge procedures)
 Eventual replica convergence through a peer--wise anti-entropy
process
 Per-client consistency guarantees
 Roll-back and undo capabilities

107
The Bayou Architecture

Storage Storage
Application
System System
Bayou API

Client Stub
Server State Anti-entropy Server State
Read
Client Server
or Server
Write
Storage
System

Storage
Application
Server State System
Bayou API
Read
Client Stub or
Write Server Server State
Client

Server

108
Application-Specific Conflict
Resolution in Bayou
 Along with desired update, a write operation
includes a dependency check:
 server query & expected query results
 As a pre-condition to performing the write
operation, the dependency check must succeed
 A conflict is detected if query, when run against
server data, does not produce same results.

109
Application-Specific Conflict
Resolution in Bayou
 If dependency check fails, write is not performed
and server runs a merge procedure:
 also submitted along with the write operation
 templates or rules written in a high-level interpretive
language
 uses server data and application-specific data to resolve the
conflict
 when run, produces a revised update request

 Write operations are atomic

110
Conflict Resolution in Bayou
 Example (Application-specific):
Write {
reserve an hour time slot by meeting room sched
application; dependency_check: (list of previously scheduled
meetings that overlap with requested time slot,
NULL); merge_procedure: ();
}

 Others:
 detect read/write conflicts
 detect write/write conflicts

111
Replication Management in
Bayou
 Clients send their writes to only one server (weak
consistency)
 Bayou servers propagate their writes during pair-
wise contacts. This process is called Anti-entropy
and results on the two server agreeing on the
writes and their order.
 Eventually all writes will reach all servers
(eventual consistency)

112
Bayou: Summary
A
pplic
atio
ns N o n -re altim ec ollab ora tiv eap plic atio ns: m eetin g
roo m sc h ed ulera n db ib lio g rap hicd atab ase,
ap p o in tm en tca len d ars,e v o lv ingd e sig nd oc um e nts,
ne w sb ulletinb o ard s.
A
dap
tatio
n A p p lic ation -spe cificad ap tatio ntod isc onn ectio n
an din term ittentc on n e ctiv ity ; ap p lic ationsa re
pe rm itte dtom ak etrad e-o ffo fre p lic ate dd ata
co n siste n cyan dav ailab ilityb yu sin gin divid ually
sele c tab lesessio ng uara n te e s.
M
od
el D isc o n n ecte dc ollab orativ eg rou p ;fu ll(o r
disc o n n ecte d)c lie nta rc h ite c ture .
M
ob
ileD
ata Sy ste m su pp ortfo rd e tec tio no fu p d a tec onflicts,
ap p lic atio n -spec ificre so lu tio no fu p d ateco nflicts,
ev en tu alre plicac on v e rge n c eth ro u g hap eer-w ise
an ti-e n thro pyp ro cess,a n dp e r-c lie n tc onsisten cy
gu a ra n tees.

113
Case Study 2: Odyssey
 Odyssey client architecture
 Odyssey system components
 Odyssey applications:
 Video player
 Web browser

114
Odyssey Client Architecture

Viceroy Generic Support

Wardens Type-Specific
Support

Applications Cache Manager

API Extensions (Kernel)

115
Main Features of Odyssey
 Application-aware adaptation approach
 Odyssey monitors system resources and notifies
applications of relevant changes
 Applications decide when and how to adapt, to
maintain certain level of fidelity
 General support for adaptation: Viceroy
 Type-specific support: Warden
 Caching support

116
Odyssey System Components
 Odyssey Objects
 Client API to allow applications to:
 operate on Odyssey objects
 express resource needs (expectations)
 be notified when needed resources are no longer
available
 respond by changing levels of fidelity

117
Odyssey API
Request( in path, in resource_descriptor, out request_id) Resource_id
Cancel(in request_id) lower bound
upper bound
Resource Negotiation Operations name of upcall handler
Resource Descriptor Fileds

Network Bandwidth bytes/second

Handle( in request_id, in resource_id, in resource-level) Network Latency microseconds
Disk cache Space Kilobytes
Upcall Handler
CPU SPECCint95
Battery Power minutes
Money cents
Generic Resources in Odyssey
Tsop( in path, in opcode, in insize, in inbuf, in out outsize, out outbuf)
Type-specific Operations

118
Video Player in Odyssey

119
Web Browser in Odyssey

120
Odyssey: Summary

A
p
pl
ic
at
ion
s F
il
e s
yst
em ac
ces
s,v
ide
o p
lay
ing,a
ndW e
b
b
rows
ing.
A
d
ap
t
at
io
n App
li
cat
ion-
awar
e a
dap
tat
io
n wi
tht
hesys
te
m
s
uppo
rtt
hatpr
ovid
esr
esou
rcemoni
tor
i
ng,n
ot
if
ie
s
a
ppl
ica
ti
onsofr
esou
rcec
hanges
,an
d e
nfo
rc
es
r
es
ourc
e al
lo
cat
io
n d
eci
si
ons.
M
o
de
l Cl
ass
iccl
ie
nt-
se
rvera
rc
hit
ect
ure
.
M
o
bi
leD
at
a Di
st
il
le
d se
rve
rdat
adel
ive
rybas
edonth
e c
l
ie
nt
F
eedb
acks.

121
Mobility Management

Location
handoff
management
Location Management
 Location management schemes use several database
called location registrars to maintain the location and
other information.
Example:
Consider a simple location management that uses a
single-location registrar,called the home location
registrar(HLR), to maintain the location information
of all the mobile nodes in n/w.
The search and update oopreation are
performed as follows:
The location of a mobile node is maintained at
the granularity of a cell,i.e which cell the mobile
node was in when it last registered.
For each mobile node m, the HLR maintains a
mobility binding(m,c) where c is the latest cell of
m known to the HLR.
The location info of m in HLR is updated as
follows:
• When a mobile node is switched on,the HLR
is notified of the current location of m.
• Whenever handoff occurs,the HLR is
notified of the cell ID to which m is handing
off to.
• To find a mobile node m’s current
location,first the HLR is contacted.The HLR
contacts the base station of cell c in the
mobility binding for m.
The finest granularity at which location can be (and
needs to be) maintained is a cell.
• This would require a mobile node to update its location
whenever it moves from one cell to another.

• However, if the location information is maintained at a

coarser granularity, say, in an area consisting of certain
number of contiguous cells, then the search cost
increases because a larger number of cells need to be
paged to obtain the exact location (cell) of the mobile
node each time a call needs to be established.

• Thus the granularity of location information maintained

for a mobile node by the system has an impact on the
performance of the location management scheme.
Handoff
Handoff conceptually involves
several subtasks
(1) deciding when to hand off to a new AP,

(2) selecting a new AP from among several

APs in the vicinity of the mobile node,

(3) acquiring resources such as channels,

(4) informing the old AP so that it can reroute

the packets it gets for this mobile node and
also transfer any state information
to the new AP.
The decision to initiate a handoff [which can be
taken either by the mobile node, i.e., mobile-
controlled handoff (MCHO), or

by the AP, i.e., network-controlled handoff

(NCHO)] may depend on several factors such as

(1) the quality of the wireless communication

between the mobile node and the AP [as
indicated by the signal-to-noise ratio (SNR)]
(2) the load on the current AP (if the current base
station is running out of communication channels,
it may want to switch a mobile node to a
neighboring lightly loaded AP).
The choice of the base station to which to
hand off may depend on such factors as

(1) the SNR of the beacon signals from

these Aps

(2) the region the mobile node is expected

to move to in the near future

(3) the availability of resources at the AP

The main resources that need to be
acquired in the new cell are the uplink
and downlink channels in a
connection-oriented circuit-switched
network and the address (such as an
IP address) in a packet-switched
network.
Location management assists in establishing new
connections to a mobile node, whereas handoffs
ensure that the mobile node remains connected to
the network.
Summary:
mobility management consists of: location management
and handoff management .

location management is needed to ensure that the

mobile node can be located quickly when a new call arrives
so that a connection can be established. A call to a mobile
node is dropped if the mobile node cannot be reached
within a certain time. Location management plays a crucial
role in minimizing the number of calls that are dropped.

Handoff management is needed to ensure that ongoing

calls continue with minimal degradation in quality of service
(QoS) irrespective of the mobility of the endpoints
(caller/callee) of the connection.
Location Management Principles and Techniques

• Location management schemes use several

databases called location registrars to maintain
the location and other information, such as
preferences and service profile, of mobile nodes
Case study:

why more than one location registrar may be

helpful, let us consider a simple location
management scheme that uses a single-location
registrar, called the home location registrar
(HLR), to maintain the location information of all
the mobile nodes in the network. In this simple
location management scheme, the search and
update operations are performed as follows
The location of a mobile node is maintained
at the granularity of a cell,i.e., which cell the
mobile node was in when it last registered.
For each mobile node m, the HLR maintains a
mobility binding (m, c), where c is the latest cell
(location) of m known to the HLR. The
location information of m in the HLR is
updated as follows:
• When a mobile node is switched on, the HLR is notified
of the current location of m (the cell in which the mobile
node is located). the mobile node m’s location is sent to
the location server. The registration message travels via
the base station of the cell to the location server.

• Whenever handoff occurs, the HLR is notified of the cell

ID to which m is handing off to. when the mobile node
moves to cell d from cell c, the mobile node may decide
to register its location to be cell d.

• To find a mobile node m’s current location, first the HLR

is contacted.The HLR contacts the base station of cell c
in the mobility binding for m. The base station pages for
mobile m in its cell. If m is in cell c and is switched on,
then it can respond to the page message,and connection
can be established.
Another scenario in which the system may be
unable to establish a call is when the location
information provided by the HLR is not the
most recent location information for mobile
node m.

This can happen if m handed off to another

cell between the time its location information
was obtained from the HLR and cell c paged
for it mobile node m hands off to cell d just
after the mobile node attempting to contact it
obtains its location information.
As the average time a mobile node stays in a cell
before moving to another cell, called the cell
residency time, decreases, this situation can occur
with increasing frequency.

In general, the average cell residency time

depends on the cell size and the mobility pattern of
the mobile node.

In order to decrease the probability of failure in locating

a mobile, the preceding location management scheme
can be enhanced as follows:
• The mobility binding of a mobile node has two additional
pieces of information: tu and ttl, where tu is the time
when the binding was last updated, and ttl is the time-to-
live value, which determines how long the binding is
valid.
• The time-to-live entry reduces the chance of trying to
contact a mobile that is currently powered off. However,
this requires that the mobile node updates its location
information periodically, every tp seconds, where tp is
less than ttl.
• A side effect of this is that the
number of updates performed at
the HLR per mobile node is
increased dramatically. On the positive
side, the search operation can use the
fact that the mobile node updates its
location every tp time units (whenever
it is on) to reduce the search cost.
• When the mobile node is not found in cell c, a set of
cells around cell c is paged. These cells can be paged
simultaneously, or an expanded ring search can be
performed for a maximum of k rings centered at cell
c—the last known location of the mobile node.
• Increasing the paging area increases the chance that
the search operation will succeed at the expense of
using more network resource such as wireless
bandwidth and consumption of battery power for
processing paging messages. For example, if the
speed of the mobile node m is a maximum of vm cells
per second, then k can be set to vm *tp.
Introduction

146
Introduction
• key components
– Mobile terminal (MT)
– Base station (BS)
– Mobile switching center
(MSC)
– Home location register (HLR)
– Visitor location register (VLR)

147
Introduction

148
 Introduction
 Mobility Management
 location management
 handoff management

 What is location management doing?

 location registration (or location update)
 paging

149
Time Based Updating

150
Movement Based Updating
 movement threshold of 3 is used

151
Distance Based Updating

152
Calling Procedure
 Call delivery
1. Determining the serving VLR of the called
MT
2.Locating the visiting cell of the called MT
(Paging)
 Determining the serving VLR of the called
MT procedure
1. The calling MT sends a call initiation signal to
the serving MSC of the MT through a nearby
base station.
153
154
Location Management for Cellular
Networks
1. Pointer Forwarding:

K=2

155
Location Management for Cellular
Networks
2. Local Anchoring:

156
Location Management for Cellular
Networks(Cont.)
3. Pre-User Location Caching:

157
Mobile IP
 Agenda
 What is Mobile IP?
 Mobile IP Architecture
 Why Mobile IP?
 How Mobile IP Works
 Registration Message Format
 Tunneling in Mobile IP
 Mobile IP in Action
 Security in Mobile IP
 Mobile in IPv6
 Conclusion
What is Mobile IP
Definition:

Mobile IP is a standard communication protocol, defined to

allow mobile device users to move from one IP network to
another while maintaining their permanent IP address [2]
 Mobile IP Architecture
Correspondent node (CN)

Home Agent (HA) Remote Agent (RA) Mobile node (MN)

Entities in Mobile IP
 Mobile Node (MN) - A Node moving to different network, with permanent Home Address.
 Home Agent (HA) - A router on a mobile node's home network which tunnels datagrams for delivery to the mobile
node when it is away from home, and maintains current location information for the mobile node.

 Home Address - The static fixed IP Address allocated to a mobile node by Home Agent.
 Home Network - A network, having a network prefix/network id.matching that of a mobile node's home address
 Foriegn Network - A network other than a Mobile node’s home network.
 Foreign Agent - Router in foreign network that provides CoA and tunneling with HA and forward the packets to MN.
 Care-of Address - Termination point of a tunnel toward a MN in the foreign netwrok.
 Mobility Binding - The association of a home address with a care-of address (CoA).
 Correspondent Node (CN) - A peer node with which a Mobile node is communicating.
 Why Mobile IP ?
CN is successfully communicating with MN via HA
Correspondent node (CN)
Packets for MN are dropped by the
Home Agent as Mobile node is not
Mobile node (MN) present in its network

Router
Home Agent (HA)

Mobile Node moves to remote network

Remote Agent (RA)
 Why Mobile IP (Cont.)

 Trends: People’s perspective of looking at internet has changed

from ages,
with the introduction of Mobility.

 Need: Increase in the variety of mobile devices, such as

PDA’s, laptops and
cellular phones, more and more internet services are
accessible to
moving users with the widely deployed wireless
networks.
 How Mobile IP works
Registration FA

1. Registration Request by MN to FA
2
2. FA Relays Registration request to HA 1
4 3
3. HA sends Registration reply to FA

4. FA Relays Registration reply to MN

HA
MN
Mobility Binding Table
Registration message format

Register request Register response

Tunneling in Mobile IP
CN sends packets to HA
Correspondent node (CN)

Home Agent (HA) IP-in-IP or GRE tunnel

between HA and FA

HA tunnels the
Packet and sends to FA
MN moves to FA Foreign Agent(FA)

FA extracts original
Packet and sends to the MN

Mobile Node (MN)

Tunneling in Mobile IP(Cont.)

 When CN sends the data to MN, it uses the original address of the MN, so the
packet goes to HA.

 From the mobility binding HA encapsulates the packet (IP-in-IP or GRE) and
sends to CoA.

 The FA de-capsulate the packet and extracts the original packet that was sent
by the CN.

 The FA then sends this packet to the MN using the Home address destination.

 The reverse route from MN to CN may or may not follow this path.

Triangle routing – Reply packets are sent directly to CN from MN

Reverse Tunneling – Reply packet are tunneled to HA by FA.
 Mobile IP in Action
CN is successfully
Mobility Binding communicating
table with MN via HA
Correspondent node (CN)
Home Address Care-of-Address
A B
Mobile node (MN)
HA Looks binding table
Home Address = A

Home Agent (HA)

1. MN sends Registration request with its new CoA

2. Mobile binding created for MN with new CoA

3. MN sends Registration response, after validating request and

Remote Agent (RA)
updating binding table
4. Packets sent to MN from CN are tunneled to RA using binding table

CoA = B
Mobile Node moves to remote network
 Security in Mobile IP
 Required as Mobile Nodes are often in unprotected remote
network
 Authenticity and Integrity of Registration messages using
Authentication (e.g. HMAC-MD5).
 Replay attack protection for Registration messages using
sequence number.
Issue Protocol Solution
Security Issues in
Optional authentication Mobile
between IP FA
MN and IPv4 AAA and Broker AAA
services
Location Privacy IPv4,IPv6 None

Confidentiality for Data Packets IPv4,IPv6 IPSec or SSL

 Security in Mobile IP (Cont.)
Mobile IP with AAA (e.g. RADIUS)
8
7 3
Remote AAA
4
Broker AAA
2 9
Home AAA

5 6
Remote Agent (RA)

1 10
Home Agent (HA)

Registration Request

Registration Response
Mobile node (MN)
 Security in Mobile IP (Cont.)
IPSec for Data Confidentiality

Correspondent node (CN)

Home Agent (HA) Remote Agent (RA) Mobile node (MN)

IPSec Tunnel

Mobile IP Tunnel (IP-in-IP or GRE)

Mobile IP in IPv6
 Conceptually same as MIPv4

 Inbuilt support using specific extensions for mobile IP

 Route optimization using new type of routing header

 “Triangle routing” problem solved using new destination header option

 Mobility Header to exchange binding messages ( e.g. Registration)

 Better security using IPSec extensions for binding messages

Conclusion
 Mobile IP plays important role in future with advanced mobile computing
devices ( 3G phones, Wi-Fi and WiMAX nodes etc)

 Mobility vs. security will always be a trade off

 Security is provided with IPSec and AAA services

 Problem of QoS with Mobile IP need to be addressed

 Standard is driven by IETF , which helps in faster deployment without

much interoperability issues.
 References
1. IP Mobility Support for IPv4; RFC 3344, Perkins, Charlie;
http://www.ietf.org/rfc/rfc3344.txt
2. Wikipedia : http://en.wikipedia.org/wiki/Mobile_IP
3. Mobility Support in IPv6; RFC 3775; http://www.ietf.org/rfc/rfc3775.txt
4. TCP/IP Tutorial and Technical Overview, IBM Redbooks
5. http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a0080
0c9906.shtml
6. http://www.isoc.org/inet2001/CD_proceedings/T40/inet_T40.htm
Thank You