Download wireless network fixed network

Mobile Applications
 Cellular Networks
– Email/Web/Location services
– Intranet application access
– Wireless application protocol
 Wireless LANs
– Client-Server adaptations
– Disconnected operations
 Ad-hoc Networks
– Vehicular applications
– Emergencies
 Data broadcasting
 Mobile agents
Variability of the Mobile Environment
Mobility
• stationary
• nomadic (pedestrian speed)
• mobile (vehicular speed)
• roaming (mobile across networks)
Connectivity
Mobile Device Capability
• form
factor
• Windows based GUI
• multimedia
• real-time multimedia
• connected
• semi-connected
(asymmetric)
• weakly connected
• disconnected
Source: Helal
Mobile Applications - 1
 Vehicles
– transmission of news, road condition etc
– ad-hoc network with near vehicles to prevent accidents
 Emergencies
– early transmission of patient data to the hospital
– ad-hoc network in case of earthquakes, cyclones
– military ...
 Traveling salesmen
– direct access to central customer files
– consistent databases for all agents
– mobile office
Mobile Applications - 2
 Web access
– outdoor Internet access
– intelligent travel guide with up-to-date location dependent
information
 Information services
– push: stock quotes; pull: nearest cash ATM
– find nearest printer (Jini services)
 Disconnected operations
– file-system caching for off-line work
– mobile agents, e.g., shopping
 Entertainment
– ad-hoc networks for multi user games
World Wide Web and Mobility
HTTP/HTML have not been designed for mobile applications/devices
 HTTP 1.0 characteristics
–
–
–
–
–
–
–
designed for large bandwidth, low delay
stateless, client/server, request/response communication
connection oriented, one connection per request
TCP 3-way handshake, DNS lookup overheads
big protocol headers, uncompressed content transfer
primitive caching (often disabled, dynamic objects)
security problems (using SSL/TLS with proxies)
 HTML characteristics
– designed for computers with “high” performance, color highresolution display, mouse, hard disk
– typically, web pages optimized for design, not for communication;
ignore end-system characteristics
System Support for Mobile WWW
 Enhanced browsers
– client-aware support for mobility
 Proxies
– Client proxy: pre-fetching, caching, off-line use
– Network proxy: adaptive content transformation for connections
– Client and network proxy
 Enhanced servers
– server-aware support for mobility
– serve the content in multiple ways, depending on client capabilities
 New protocols/languages
– WAP/WML
Wireless Application Protocol
 wapforum.org: co-founded by Ericsson, Motorola, Nokia, Phone.com
 Goals
– deliver Internet services to mobile devices
– independence from wireless network standards
– GSM, CDMA IS-95, TDMA IS-136, 3G systems (UMTS, W-CDMA)
 Browser
– “Micro browser”, similar to existing web browsers
 Script language
– Similar to Javascript, adapted to mobile devices
 Gateway
– Transition from wireless to wired world
 Server
– “Wap/Origin server”, similar to existing web servers
 Protocol layers
– Transport layer, security layer, session layer etc.
 Telephony application interface
– Access to telephony functions
WAP: Reference model and protocols
Internet
HTML, Java
A-SAP
WAP
Application Layer (WAE)
S-SAP
additional services
and applications
Session Layer (WSP)
HTTP
TR-SAP
Transaction Layer (WTP)
SEC-SAP
SSL/TLS
Security Layer (WTLS)
T-SAP
TCP/IP,
UDP/IP,
media
Transport Layer (WDP)
WCMP
Bearers (GSM, CDPD, ...)
WAE comprises WML (Wireless Markup Language), WML Script, WTAI etc.
Source: Schiller
WAP: Stack Overview
 WDP (Wireless Datagram Protocol):
– Provides transport layer functions
– Based on ideas from UDP
 WTLS (Wireless Transport Layer Security):
– Provides data integrity, privacy, authentication functions
– Based on ideas from TLS/SSL
 WTP (Wireless Transaction Protocol):
– Provides reliable message transfer mechanisms
– Based on ideas from TCP
 WSP (Wireless Session Protocol):
– Provides HTTP 1.1 functionality
– Supports session management, security, etc.
 WAE (Wireless Application Environment):
– Architecture: application model, browser, gateway, server
– WML: XML-Syntax, based on card stacks, variables, ...
– WTA: telephone services, such as call control, phone book etc.
Content encoding, optimized for low-bandwidth channels, simple devices
WAP: Network elements
fixed network
Internet
HTML
wireless network
WML
HTML
filter
WAP
proxy
Binary WML
WML
HTML
web
server
HTML
filter/
WAP
proxy
WTA
server
Binary WML
Binary WML
PSTN
Binary WML: binary file format for clients
Source: Schiller
WAE: Logical model
Origin Servers
web
server
other content
server
Gateway
response
with
content
push
content
request
encoders
&
decoders
Client
encoded
response
with
content
encoded
push
content
encoded
request
WTA
user agent
WML
user agent
other
WAE
user agents
Source: Schiller
Wireless Markup Language (WML)
 Cards and Decks
–
–
–
–
Document consists of many cards, cards are grouped to decks
Deck is similar to HTML page, unit of content transmission
WML describes only intent of interaction in an abstract manner
Presentation depends on device capabilities
 Features
–
–
–
–
text and images
user interaction
navigation
context management
 WMLScript
– Provides general scripting capabilities
– Validity check of user input, local user interaction
– Access to device facilities (phone call, address book etc.)
WML: Example

















<WML>
<CARD>
<DO TYPE="ACCEPT">
<GO URL="#card_two"/>
</DO>
This is a simple first card!
On the next you can choose ...
</CARD>
<CARD NAME="card_two">
... your favorite pizza:
<SELECT KEY="PIZZA">
<OPTION VALUE=”M”>Margherita</OPTION>
<OPTION VALUE=”F”>Funghi</OPTION>
<OPTION VALUE=”V”>Vulcano</OPTION>
</SELECT>
</CARD>
</WML>
Source: Schiller
Application Adaptations for Mobility
 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
 data broadcasting/caching
 System-aware, application-aware
 the mobile agent model
The Client/Proxy/Server Model
 Proxy functions as a client to the fixed network server
 Proxy functions as a mobility-aware server to mobile client
 Proxy may be placed in the mobile host (Coda), or the fixed
network, or both (WebExpress)
 Enables thin client design:
–
–
–
–
Resource-poor mobile computers
Application resides on the server
Keyboard and mouse inputs sent from client to server
Display outputs sent from server to client
Web Proxy in WebExpress
The WebExpress Intercept Model
Source: Helal
Disconnected Operations: File Systems
 Goals
– Efficient/transparent access to shared files within a mobile environment
– Support for disconnected operations while maintaining data consistency
– Standard file systems (e.g., NFS) are very inefficient, almost unusable
 Approaches
– Replication of data (copying, cloning, caching)
– Getting data in advance (hoarding, pre-fetching)
 Main problem: consistency
– Typical mechanisms: strong consistency (via atomic updates)
• Invalidation of caches through a server
• Cannot be used in mobile environments
• Mobile computer may not be connected to network
 One solution: weak consistency
–
–
–
–
Tolerate occasional inconsistencies
Apply conflict resolution strategies subsequently
Use version numbering, time-stamps (content independent)
Use dependency graphs (content dependent)
File Systems: Coda
 Application transparent extensions of client and server
– changes in the cache manager of a client
– applications use cache replicates of files
– extensive, transparent hoarding
 Consistency
– system keeps record of changes; compares files upon reconnection
– if different users have changed the same file, manual reintegration
of the file into the system is necessary
– optimistic approach, coarse grained (file size)
mobile client
application
cache
server
Source: Schiller
File Systems - Coda
 Hoarding
– user can pre-determine a file list
with priorities
– contents of the cache determined by
the list and LRU strategy
– explicit pre-fetching possible
– periodic updating
 States of a client
hoarding
disconnection
weak
connection
write
disconnected
 Consistency
– asynchronous, background
comparison of files
– system weighs speed of updating
against minimization of network
traffic
strong
connection
connection
disconnection
emulating
 Cache misses
– function of file size and bandwidth
– modeling of user patience: how
long can a user wait for data
without an error message?
Source: Schiller
Mobile Data Management
 Maximize query capacity of servers, minimize energy/query at client
– asymmetric links (high b/w from server to client; low b/w from client to
server)!
 Pull data delivery: clients demand, servers respond
– clients request (validate) data by sending uplink messages to server
 Push data delivery: servers broadcast data, clients listen
– servers push data (and validation reports) through a broadcast channel,to a
community of clients
– data are selected based on profiles and registration in each cell
– client energy is saved by needing receive mode only
– scales to any number of clients
 Push and Pull data dissemination: Sharing the channel
– Selective Broadcast: Servers broadcast "hot" information only
– On-demand Broadcast: Servers choose the next item based on requests
Organization of Broadcast Data
 Flat: cyclically broadcast the union of the requested data
A B C
 Skewed (Random):
– broadcast different items with different frequencies
– goal is that the inter-arrival time between two instances of the same
item matches the clients' needs
A A B C
Broadcast Disks
Disk1
Disk2
A
B
C
A B A C




Periodic broadcast of one or more disks using a broadcast channel
Disks can of different sizes and can be broadcast at different speed
Frequency of broadcasting each item depends on its access probability
Disk speed can be changed based on client access pattern
Source: Helal
Indexing on Air
inx
inx
inx
inx
inx
inx
inx
inx
inx
inx
 Server dynamically adjusts broadcast hotspot
 Clients read the index, enters into doze mode, and then perform selective
tuning
– Query Time: time taken from point a client issues a query until answer is
received
– Listening Time: time spent by client listening to the channel
Source: Helal
Client Caching in Broadcasting




Data are cached at clients to improve access time
Lessen dependency on the server's choice of broadcast priority
Traditionally, clients cache "hottest" data to improve hit ratio
Cache data based on PIX:
– Probability of access (P)/Broadcast frequency (X).
 Cache data replacement
– cost-based is not practical
– requires perfect knowledge of access probabilities
– comparison of PIX values with all resident pages
 Alternative: LIX, LRU with broadcast frequency
– pages are placed on lists based on their frequency (X)
– lists are ordered based on L, the running avg. of interaccess times
– page with lowest LIX = L/X is replaced
Client Cache Invalidation
 Why?
– Value of data may have changed since caching by client
 When?
– Synchronous: send invalidation reports periodically
– Asynchronous: send invalidation information for an item, as soon
as its value changes
 To whom?
– Stateful server: to affected clients
– Stateless server: broadcast to everyone
 What to send?
– invalidation: only which items were updated
– propagation: the values of updated items are sent
– aggregated information/ materialized views
 Another issue
– Commit of transactions involving read and write by clients
The Mobile Agent Model
 Mobile agent receives client request and
 Mobile agent moves into fixed network
 Mobile agent acts as a client to the server
 Mobile agent performs transformations and filtering
 Mobile agent returns back to mobile platform, when the
client is connected
Mobile Code
 Definition:
– Capability to dynamically change the bindings between code
fragments and the location where they are executed
 Approaches: (Not a totally new concept)
– Remote batch job submission & use of PostScript to control
printers
– Distributed OS led to more structured approach
• Process Migration
• Object Migration (Mobile Objects)
– Mobile Code Systems (Mobile Agents)
Process Migration
 Transfer of OS process from one m/c to other
 Migration mechanisms handle bindings between
– process and execution environment (e.g. open fds, env variables)
 Provide for load balancing
 Most of these facilities provide transparent process
migration
 Other like Locus provide for some control
– like external signal or migrate( ) system call
Object Migration
 Makes possible to move objects among address spaces
– finer grained mobility with respect to processes
– e..g Emerald system : Different granularity levels - small to
complex objects
• does not provide complete transparency
– COOL (oo extension of Chorus OS) allows total transparent
migration
 Process and Object migration address issues when
– code and state are moved among hosts of loosely coupled, small
scale distributed systems
– insufficient when applied to large scale settings
Mobile Code Systems
 Code mobility is exploited on Internet Scale
– Large scale, heterogeneous hosts, technologies
– Strong v/s weak mobility
 Mobility is location aware
– Programming language
• provides mechanisms and abstractions that enable shipping/
fetching of code to/from nodes
– Underlying run-time
• supports marshalling, code, check in , security etc
• no knowledge of migration policies
 Applications
– Not just for load balancing
– E-commerce, distributed information retrieval, workflow…
Mobile Code Systems: Design
 Several Paradigms:
–
–
–
–
Client Server
Remote Evaluation
Code on Demand
Mobile Agent
 Example:
–
–
–
–
–
–
Two friends Sita and Gita
interact to make a cake (results of service)
recipe is needed (know-how about service)
also ingredients (movable resources)
oven to bake (hard to move resource)
a person to mix ingredients as per recipe (computational component
responsible for execution of code)
– prepare the cake (execute the service)
– where the cake is prepared (site of execution)
Client-Server: CS
 Sita would like to have chocolate cake:
– she does not know the recipe
– she does not have the required ingredients nor an oven
 Sita knows that Gita (who likes baking cakes)
– knows the recipe
– has a well supplied kitchen
 Sita calls Gita asking:
– “Can you make me a chocolate cake please?”
 Gita makes the cake and delivers it back to Sita
Remote Evaluation: REV
 Sita would like to have chocolate cake:
– she knows the recipe
– she does not have the required ingredients nor an oven
 Sita knows that Gita (who likes baking cakes)
– has a well supplied kitchen
– does not know the recipe
 Sita calls Gita asking:
– “Can you make me a chocolate cake please? Here is the recipe…”
 Gita makes the cake and delivers it back to Sita
Code on Demand : COD
 Sita would like to have chocolate cake:
– she has the required ingredients and an oven
– she does not know the recipe
 Sita knows that Gita
– knows the recipe (and is willing to share it)
 Sita calls Gita asking:
– “Can you tell me the recipe for making chocolate cake please?”
 Gita tells her the recipe and Sita makes the cake
Mobile Agent: MA
 Sita would like to have chocolate cake:
– she has the recipe and the required ingredients
– she does not have an oven
 Sita knows that Gita
– has an oven (and is willing to share it)
 Sita could
– prepare the batter
– go to Gita’s place
– bake the cake
 Several other variations are also possible
Mobile Agents: Example
Mobile Applications in Industry







Wireless access: phone.com
Alerting services: myalert.com
Location services: airflash.com
Intranet applications: imedeon.com
Banking services: macalla.com
Mobile agents: tryllian.com
….
 wapforum.org
 palowireless.com