第 3 讲 移动计算系统结构与模型
3.1
3.2

MU
(mobile unit)
MSS
(mobile support station)
Fixed network
Server
Wireless radio cell (19.2Kbps) WLAN




Fixed network can be dedicated proprietary network for the mobile system.
 Fixed network can also be the Internet or Intranet.

MSS ( mobile support stations , sometimes called base station ) will be in charge of communication with mobile clients or mobile hosts (called mobile unit or MU ).
Communication between MSS and MU can vary a lot.
MSS helps to keep track of MU.
MSS performs paging for MU within a cell.
MSS handles handoffs for MU.
Retransmission of messages can be done at MSS to MU.
MSS may also forward messages to moved MU.




The nodes play the same role
Mobile client AND network router

Multi-hop wireless paths
Mutually helping in forwarding

Self-configuration/organization
Topology maintenance
Routing




Hierarchical but both wireless
Ad hoc backbone + wireless cell

MAP ( mesh access point , sometimes called mesh router ) play the same role as MSS
MAP helps to keep track of MU.
MAP handles handoffs for MU.
Retransmission of messages can be done at MAP to MU.
MAP may also forward messages to moved MU.

Ad hoc networking among MAPs
Multi-hop wireless paths
Self-*


How mobile units (MUs) communicate with servers and other nodes in the network?
Infrastructure network: MUs communicate with MSS directly
Ad hoc network: MUs communicate with others via intermediate nodes
Actual communication varies depending on the wireless communication hardware setup and protocol, e.g.,
802.11 with CSMA/CA, or others.
 For data communication, we assume the structuring of communication resource into logical channels .
A channel is a media on which a message can be sent or received.
A channel may be unidirectional or bi-directional , of varying observed bandwidth.
For instance, 10 Mbps Ethernet can deliver observed bandwidth of about 5
Mbps.
A channel can be a point-to-point channel that supports unicast or a broadcast channel that supports broadcast.
Multicast can be implemented as a broadcast, with recipients filtering for their information, or sequential unicasts.
Channels are usually inherently asymmetric
With higher bandwidth for downlink than uplink traffic processing power and energy of MU and MSS (or GW) are different.
Symmetric for internal communication inside ad hoc network


MU can tune in to different downlink channels to download the required data at appropriate time.
 MU can transmit data to MSS via uplink channels, subject to competition (e.g., CSMA/CA or reservation).
This can often be modeled as a simple queue, shared by the MUs.

MU can be in active mode or in doze mode . When it is in the doze mode, it is not able to listen to data over the channel, but this saves precious energy.
Note that a disconnected MU cannot send/receive any data, even if it is in active mode.

A practical MU will often calculate the time to download its required data and turn into doze mode, waking up at the appropriate time to pick up the data.
 To enable MU to calculate the moment that a data item is available, an index to the data items to be delivered is normally sent over the channels.
This is especially true for the broadcast channel, since data items needed by different MUs are often multiplexed on the same channel.


Issues to consider on the characteristics of channels:
In distributed computing environment
Reliability : reliable vs unreliable channel
Synchrony : synchronous vs asynchronous channel
Ordering : FIFO vs non-FIFO channel
In mobile computing environment
Broadcast vs point-to-point channel
Asymmetry of channel (and hence bandwidth, then synchrony)
Degree of unreliability of channel (retransmission mechanism)
Degree of prolonged disconnection
Mobility of MU to another MSS (handoff and forwarding)

Questions:
How can we ensure the correctness of distributed algorithms in mobile environment with bad channel characteristics?
How can we provide proper data management under those constraints?




Recall that many mobile computing techniques have their root in distributed systems.


Client/server model is the easiest model in distributed computing.

Client/server model is therefore the most straightforward model to adopt in a mobile environment.
 Reasons:
MUs are moving around, connecting to various types of servers.
Fixed MSSs act naturally like a server for communication.
Service requests can be routed from the MSSs to other types of fixed servers such as database servers, either via transparent message passing (e.g. IPv6) or nested client/server invocation or RPC/RMI.


Client/server computing communicates in a master/slave manner.
Server is the slave, providing services to clients as masters.

Clients make requests to servers, which are resource managers, and obtain responses from servers for their activities.

This is easily modeled or implemented by means of Remote
Procedure Call (RPC).

Examples include file server, database server, printer server, web server, and application server.


Communicate with user
Contact server
Communicate with server

Accept client request
Process request and perform computation
Return result to client


A server may not be able to perform every task and often needs the help of other servers and uses other resources.
A server may behave as a client during its request processing cycle, generating requests to other servers to help performing its task.
Nesting may be of arbitrary levels.
For example, MSS may act as a first level server, getting help from second level application server, or database server.


Iterative server:
One single server process provides the service for client.
Requests from multiple clients handled one by one sequentially.
Easy to program; no concurrent access problem; good if processing time for a request is very short.
May block other requests and cause a long response time.

Concurrent server:
Server process creates a child process to handle each request it receives.
It then returns to wait for a new request, before current request is completed. Child process provides the real service and generates response.
Multiple requests are handled concurrently.
Harder to program; faster response time without blocking; must be careful about concurrent access to shared data/resource.
The more common approach for practical client/server systems.

Iterative server
Concurrent server


Stateful server:
Server saves information about status of clients. Server can remember what clients have done before. The load is on server.
This reduces the size of request messages, since both client and server share their context, e.g., a next () request implies returning result starting from current position.
Lost messages could put client and server out of synchrony/context.

Stateless server:
Server maintains no information about status of clients. All requests start from a “ fresh ” state and are self-contained.
Request messages need to contain sufficient information for the context. The load is on client.
Straightforward handling procedures upon failures.


Fat server (and thin client):
Application logic resides on server.
Usually more efficient since data (resource) and application logic
(code) stay together.
Reduce network bandwidth consumption.
Easy to change application logic without affecting clients (many of them).
Adopted by majority of client/server systems.

Thin server (and fat client):
Application logic resides on client.
Easy to explore and customize client for new applications.
Client needs to know the structure of data, debugging harder.
Consistent change of application logic difficult.
Consume bandwidth by transferring data to client for processing.

 There are a number of possible models to structure the computing elements, processes, or units in a mobile computing environment.
Client/server model : also called C/S model, the most common distributed computing model.
Client/agent/server model: also called CAS model.
Client/intercept/server model: also called CIS model.
Peer-to-peer model : the standard distributed computing model.
Mobile agent model: also called MA model.


Model used should be able to handle issues in mobile computing.
Disconnection and weak connection.
Variability of communication environment.
Variation of mobile host functionality and capability.

Adaptation is needed since clients and hosts come with different capability with varying resources.
Notebook computer: docked versus non-docked.
Pocket PC with expansion card: varying memory / capability.
Mobile phone with simple OS: additional software.
 Adaptation is also needed for varying operating environment.
Varying wireless bandwidth and intermittent connection.
Voluntary and involuntary disconnection.
Voluntary doze off of clients.


Application-awareness: applications should know that client may be mobile, and detection of changing environment should be built in and appropriate operation mode is used to make better use of resources.
WAP applications should be simpler than web applications, since
WAP is downloaded and executed by a mobile device.
Application should detect external environment and this could be complicated.

Duty partition between client and server: mobile clients should bear smaller responsibility pushing more to server
 Connection-awareness: make more extensive use of caching and data hoarding if connection is not guaranteed; reduce communication cost by call optimization, data compression.


Two extreme approaches in adaptation:
Done at system level and transparent to applications.
Advantages: existing applications can run without change.
Disadvantages: performance may be worse; some applications cannot function without making proper preventive measure (e.g., hoarding of important files that have not been accessed).
Done by individual applications .
Advantages: applications know well what to do; make use of specific application needs to optimize handling mechanism.
Disadvantages: each application has to handle its own adaptation, with high development cost; competition for shared resources handled in different manner.

Hybrid solution
Both system level and app level
Layered in system level

 In C/S model, client submits requests to server and server returns results back to client.
 However, mobile client/server model deviates from standard client/server computing for distributed environment.
Client/server model normally assumes continuous network connectivity and reasonable client ability .
Resource limitation to clients moves “fat” client activities back to server, making clients as thin as possible.
Clients cannot be too thin, since disconnection and low communication bandwidth force us to place as much processing logic in client as possible to enable processing.


Traditional C/S model would not work well in mobile environment.
Direct message exchange is not good for thin client, since fat servers cannot handle requests in time, causing long queues to form.
Standard RPC is not good either, since the disconnection of clients from server would lead to excessive timeout and retransmission of request/reply.
Mobility of client causes additional problem: when and where to transmit a reply back to client, even if RPC has been decoupled into asynchronous RPC?

Need to reorganize activities on clients and servers.
Make use of the client/server model as much as possible.
Focus on improving performance to MU transparently.
Decouple the communication in synchronous RPC.
Often based on extension of client/server computing model with multiple tiers.

 Use a variant of the three-tier approach.
Middle-tier can help to resolve previous problems.
Application logic placed in a middle tier apart from the interface
(client) and the data (server).
Communication between tiers by means of message passing.
More flexible with thin client and thin server.
Application logic can be changed readily.
In general, there is an increased response time and aggregate bandwidth consumption.

Move additional processing logic to agent(s).
 Agents will be responsible for work to mask out mobile computing limitations.

 An agent is an autonomous program that can perform some specific activities, according to some agreed upon arrangement with a party that the agent is responsible for.

Two common extensions to the C/S model:
CAS model ( c lient / a gent / s erver model)
CIS model ( c lient / i ntercept / s erver model or client / client intercept / server intercept / server model)

In CAS model, it is closer to fat server model, since agent is near server, but some server activities are moved to the agent.
 In CIS model, additional activities are moved to the two intercept agents.

 Agent is a surrogate or proxy that acts on behalf of the client at the server.
 Communications pass through agent.
 To the server, the agent looks like the mobile client, so standard C/S interaction occurs between agent and server.
client wireless link agent fixed network server


Agent functionalities
Messaging and queuing.
Optimization to transmission over wireless link (need appropriate change in client code).
Off-load processing from client.
Handle disconnection of client.
Normally asynchronous communication between client and agent.

Agent type
Client-specific : each client has one agent.
Service-specific : each client service is associated with an agent.
Service-specific : agents may be shared among several clients (then an agent becomes a mini-server itself).
 Agent placement
Placed at base station or MSS: can handle transmission optimization and personalize with client, but MSS may not be trustworthy; agent may need to move with clients to other MSS.
Placed near server : longer communication path from client to agent; better for service-specific agent.
Placed near most clients : for shared service-specific server.


Thin clients can shift functionalities to agents.
Complex client requests can be pre-processed or postprocessed by the agent.
Server can off-load certain activities to agent.
Different protocols can be executed between client and agent and between agent and server.
Agent can cache results to improve performance.

Changes are needed in client code to be able to talk to agent.
Agent can only optimize response time between server and agent, but not much between agent and client.
Client traffic needs to pass through agent.
Cannot sustain prolonged disconnection.

 Standard CAS model refers to c lient / server a gent / s erver model.
 An alternative CAS model is the c lient / client a gent / s erver model.
Allocate the agent close to the client.
Agent will perform hoarding, prefetching and other compression activities.
client client agent wireless link server fixed network


Introduce a pair of agents , one located on client and one located near server.
 Agents are proxies for both client and server, and are often called intercepts .

There is a clear separation of responsibility.
 This is also called the CAAS model ( c lient / client a gent / server a gent / s erver model).
client client agent wireless link server agent fixed network server


Advantages
No change to client and server code.
More design choices to place load of clients and servers to agents.
Easy to optimize transmission with specific protocol at agents.
Mask disconnection of client through agents.
Prefetching and caching at client agent to combat disconnection, which causes inaccessibility of data.

Disadvantages
Need resource-rich client.
Traffic passes through both agents.
A lot of coding needed for both agents.
Different agent pairs for different applications.

Example: IBM WebExpress provides mobile web access with an agent pair.

 It is the generalized client/server model so that any client can communicate with any other client.
 No distinction between client and server.

Hosts are expected to play the role of a client and a server .
 Extend CIS model so that each host has a client agent and a server agent, in addition to the client code/thread and server code/thread.
 Now server can also move and suffer from disconnection.

Resource-rich mobile hosts are needed.

Server thread may need to be event-driven and started on demand , perhaps similar in nature to CGI (since it could be costly to continuously run the thread on the mobile host).

Useful for cooperative applications.

Useful in an ad hoc network without centralized server.

 Generalize server agent to allow it to move along when client moves to other MSS. It does not matter whether there is the client agent.
 The result is the mobile agent , and the mobile agent model .

An mobile agent is similar to an object (with persistent state information) but is autonomous and can move .

It carries along with the computational context when migrated to another host.

Agents can be dispatched from client, to handle ad hoc requests. This is useful since agents can contain dynamic code for different needs.

Service searching by agents to appropriate server.
 Agent carries back results to the client that dispatches it.

Desirable to be autonomous, able to interact with other agents, platform independent, and reactive to external events.


Allow mobility of code and data state .
After movement, agent is restarted and values of its variables are restored.
Agent execution restarts from the beginning of a given procedure (a method in case of objects ).
Can be implemented through Java serialization of object states with a call at specific point of execution and send them over via socket or RMI.

Mobility of code, data state and execution state .
Restart execution exactly from the point where it was suspended before movement.
Need the support of process migration ability at OS level.


Shift the processing burden from resource-poor client to fixed network or server on which agent is executed.
Reduce communication traffic over wireless link.
Support weak connection.
Tolerate network disconnection.
Agent acts on behalf of client as a surrogate when needed ( intelligent agent ).
Can move around for the best server.

Need to develop different programs/codes for agents.
Need to be executed in specific environments for agents.

Programmable agent to create and change behavior of other agents.

mobile computing model mobile client/server model mobile peer-to-peer model mobile agent model simple client/server model client/agent/server model client/intercept/server model