Institute of Aeronautical Engineering

Dundigal, Hyderabad

Seminar On

P2PMOBILE: A Framework for Remote Execution in

Mobile Environment

By
B. Puneeth Sharma
09951D2509
 M.Tech (SE)

Abstract

In the last decade, the popularity of mobile devices(such as smart-phones, personal digital
assistance PDAs,laptops), together with the development of wireless connection technology has
been making mobile computing highly discussed and studied by researchers. In this paper, we
introduce P2PMOBILE, a new framework for utilizing distributed resources in heterogeneous
network environment. P2PMOBILE is designed for allowing mobile users to fetch services and
resources located in peer-to-peer nodes through their mobile devices. In our framework the peer
lies in wired network and communicates with other peers through peer-to-peer protocol. They
advertise their services and resources so that other peers can easily get access to these services
and resources. Besides, P2PMOBILE enables mobile terminals to get access to these distributed
resources and thus makes it possible to utilize these resources for remote execution of various
tasks. The load of system is taken into consideration, and a novel approach to route the result of
execution back to mobile users is presented in P2PMOBILE. We use image process as an
example to test our framework in the end.
 I. INTRODUCTION

Mobile devices (such as smart-phones, PDAs, laptops) have been widely used in different
fields during the last decade. Due to the limited capacity of computation and network
technology, mobile phones have been mainly used for communication purposes, while PDAs
have been serving as an assistance to take care of simple tasks for users.
Nowadays, mobile devices are commonly equipped with more powerful processor, larger
memory and different network technologies. The increase of computational capability enables
mobile devices to execute some tasks that previously were confined to desktop computers.
Furthermore, with the development of different communication methods and technologies (e.g.
GPRS, Bluetooth, WLAN and UMTS), these mobile devices are not as isolated as they used to
be. Thus, they can easily connect to the global internet by using these technologies.
As mentioned above, these mobile devices obviously meet the requirement of ubiquitous
computing. And currently, many applications (e.g. MobiCare introduced in [1], GPS-based
application in [2]) have been applied to these mobile environments. However, the processing
speed and battery life are limited. Executing some tasks will consume more time and drain more
battery. Therefore, it will be better to take advantage of distributed resources to achieve our
goals.
In this paper, we present a framework focusing on utilizing distributed resources to perform
remote execution. A novel approach to route the result back to users is presented too. In the rest
of this paper, we present the current frameworks and approaches that try to find a way to utilize
the distributed resources for remote execution in section II. In section III, we describe the main
concept of P2PMOBILE and the novel approach, their implementation and test. Finally, we draw
Some conclusions.

II. RELATED WORK

Considerable researches and work have been done to remote execution in mobile
environment. And a lot of exciting experiments and results have been achieved. Current research
and work on remote execution mainly focus on: (1) the design of middleware, (2) task migration.
Mainly on strategy of how the tasks migrate from current computing server to another computing
server, (3) peer-to-peer environment based remote execution. Though, some researches have
been done in this direction, it still needs more attention and further study. ]Jari Porras et al. [3]
have introduced a framework of Peer Hood. Peer Hood is a middleware providing an approach to
peer-to-peer communication in mobile environment. It is composed of three entities: Peer Hood
daemon, Peer Hood library and Peer Hood plug-ins. The daemon ensures the continuous
knowledge about other wireless devices and stores the local or remote devices and services
information. Peer Hood library provides applications interface for operations provided by Peer
Hood. Peer Hood plug-ins provide functions specific to the wireless network technologies.
However, Peer Hood confines to very local peer-to-peer communication, and continuous
monitoring the environment consumes more processing time and battery in mobile devices. The
concept of [4] [5] [6] are based on the middleware Peer Hood. In [4], the authors described
service discovery module in Peer Hood and the process of discovering services. In [5],
challenges in mobile environment, as well as an approach to route the result back to mobile
devices are presented. To deliver result to mobile client this may involve too many nodes for
bridge. Thus more connection time and transfer time will be needed. Use of distributed resources
for remote execution in mobile environment is discussed in [6]. The authors utilized the current
service to perform remote execution. But they regarded the system in a static way, the didn’t
notice that the mobile client may disconnect from server. Without routing mechanism the client
will not get their result back. This draws considerable attention in our paper.

There are some other papers consider remote execution in different ways. In [7], SPADE, a
system that facilitates the execution of commodity software on remote idle computers is
presented. In SPADE, jobs are composed of simpler tasks that will be executed on remote
computers. Also SPADE can handle a batch tasks in the same time. In [8], authors study the
problem of task migration in the context of wireless mobile computing and introduce a
framework to decide the optimal policy on whether to execute locally or remotely.

III. MAIN CONCEPT OF P2PMOBILE

Many factors have motivated the study of remote execution including the deficiency of
the mobile devices (e.g. Limited processing speed, limited lifetime of battery) and lack of
suitable software. Applications have been implemented to conserve battery, to improve
processing time and to execute tasks that are not suitable to be executed or can not be executed in
mobile devices.
As is mentioned in [5], mobile environment is considered to be a collection of nodes,
including static devices with high processing power and high mobility devices with low
processing power (dynamic). In P2PMOBILE, static devices connect to each other through wire
line, while mobile devices connect themselves to static devices through wireless technologies.
Therefore mobile devices can get access to the services located in static devices. P2PMOBILE is
based on client-server model. The server runs on static devices and communicates with other
servers in peer-to-peer manner, while the client runs on mobile devices. A service management
module is implemented to manage services in the server. Any computer which installs the server
can register or advertise its services, and it maintains a list of services and a list of clients
connected to the system. In this way, a large amount of distributed resources are organized in a
peer-to-peer manner and are available for any client connects to the server.

Fig.1 shows the scenario of P2PMOBILE.

A. Remote Execution
 Remote execution is an approach to execute tasks in other places than in original places
where the tasks are generated. Remote execution exists in wired network environment for
decades. But, it may not work so well in mobile environment as it is in static environment.
Compare to static environment, mobile environment is more dynamic, with lower bandwidth and
higher frequency of disconnection. These factors make mobile environment unstable. So we need
to deal with remote execution in a different way. Although differences do exist, the steps of
remote execution are nearly the same. As addressed in [6], the common steps are presented
below.
1) Sending the task over wireless network to the server
2) Executing the task at the server
3) Sending the result back to the client

Our framework complies with these steps, yet, we extend the steps 2) and 3) with novel
approaches. In step 2), where to executing the task should be highly considered. Some
researchers proposed migrating the tasks from one server to another suitable server during the
mobile's movement or by considering the issue of load balancing. Though, these might seem as
solutions to mobile issues, we consider them a waste of time and resources in case of frequent
movements. In P2PMOBILE, we simply consider the load balancing by taking the characteristic
of mobile environment into account. By doing so, we select a suitable server to execute the tasks,
instead of selecting the directly connected server merely. We may select an indirectly connected
server if necessary. Once selected, we would not change the task executor any more. As
Is showed in Fig.2, we can see our remote execution environment clearly.
In Fig.2, server A, B, C and D communicate with each other in peer-to-peer manner, so we
assume they directly connect to others in peer-to-peer virtual network. As is show,
client directly connects to the server C. We call C as Direct Server (DS). A, B and D are the
servers that client indirectly connects to. We call A, B and D as Indirect Server (IS). When client
sends tasks to the DS, DS is the preferred server to execute tasks if it has the suitable service or
application. Otherwise, tasks will be transferred to a suitable IS (Here we simply select the server
with well connection to the DS and is not fully load.) and executed there. In this case, DS acts as
a bridge between client and IS. Tasks are sent from client to DS, and then migrate from DS to IS.
After that no more migration will be done. In all, the times of tasks migration are no more than
twice. In this way, not only load balancing is considered, but also communication time is
conserved.
The execution may take a few cycles of CPU in the server. During these periods, mobile
client may act in two alternative ways: maintains the connection to the previous server; moves
out of the coverage area of previous sever and connects to a new server. After the execution, how
are results sent back to mobile client? This is the question we are going to deal with in step 3).
We consider the following situations:

• Client still connects to the previous server. In this situation, there are two scenarios show in
Fig.3 (a) and (b) respectively. Whichever scenario it is, the results are sent back along the route
(along this route the tasks are sent) in opposite direction.
• Due to some factor, client connects to a new server or disconnects from the system. Fig.3 (c)
depicts the scenario of connecting to a new server. As it shows, the result was sent from the
executor A to the new DSD, and then sent to the client. When client disconnects from system,
the result will be stored in the server where tasks were executed until client connects to system
again. In our approach, the result passes only one DS on its way to the client. Because wherever
the DS located, it is a peer in the peer-to-peer system, so is the server which stores the result.
These two servers can communicate with each other directly in peer-to-peer manner. Compare to
the approach proposed in [5], our approach proves to be more efficient. In [5], result may pass
through many nodes before it reaches to the client, and to find the right passing route, nodes’
routing table would be look up for times. This approach would take more time than ours does.
Finally, we summarize our steps as below:
a) Client connects to DS over wireless network, and fetches the list of services in the peer-to-
peer environment.
b) Client selects one suitable software from the list and sends the task to DS.
c) DS chooses an optimum server as the executor. If the executor is DS itself, no task migration
will be done; else task migrates to the executor.
d) After the execution, the executor finds out whether the client connects to the system, if not
connected, goes to step e), else jumps to step f)
e) The executor stores the result in the result queue. As soon as the client connects to the system,
goes to step f), after the successful sending, result will be deleted from the queue.
f) If the executor is not the client’s DS, it sends the result to the DS, and then DS sends the result
to the client, else the executor directly sends the result to the client.

B. General Implementation of P2PMOBILE

P2PMOBILE is based on client-server model, server runs on fixed computers, while client runs
on mobile devices. Clients connect to servers through WLAN. Fig.4 shows the main architecture
of P2PMOBILE. Abbreviations we need: SM: Service Management; T&RM: Task & Result
Management; CM: Client Monitoring TF: Task Factory; CNM: Connection Management
 1) Server

Server is an application using JXTA technology. JXTA [10] is a set of open, generalized peer-to-
peer (P2P) protocols that allow any networked device -sensors, cell phones, PDAs, laptops,
workstations, servers and supercomputers - to communicate and collaborate mutually as peers.
The JXTA protocols standardize the manner in which peers: Discover each other, Self-organize
into peer groups, Advertise and discover network resources, Communicate with each other and
Monitor each other. Our server is mainly composed of three modules: Service Management,
Task & Result Management and Client Monitoring.
• Service Management. This module takes care of services including registers or advertises
services and stores services advertised by other peers. In this module, services are stored in the
form of specific data format: <path> :< service-name>: [description]. The field <path> is
necessary and it depicts which peer the service belongs to and service's directory. <servicename>
Is also necessary, giving the name of the service. Generally, it is the name of the software.
[Description] is not compulsively necessary. It describes the detail of the service.
• Task & Result Management. This module is in charge Of reception, migration and
execution of the task and result storing and transferring. The task is encapsulated with the
command, parameters, selected service and the ID of the client. The result contains the ID of
client, so that the result can be sent to the right client.
• Client Monitoring. Manages the connection between client and server and assigns a unique
ID to the client first connects to the server. Monitors the client, when the client connects to one
server, other servers will be notified, and they know all the on-line clients.
2) Client

The client's implementation is not as complicated as the server's. It is composed of Connection

Management and Task Factory.
• Connection Management. Establish and destroy the connection over wireless network. Basic
data transmission interfaces are implemented.
• Task Factory. Produce tasks in the client. The task is encapsulated with the command,
parameters, selected service and the ID of the client.

C. Experimenting

To test P2PMOBILE, we do a simple experiment, in which an image is simply processed.

Here, we create a simple picture processing software-PPS as a service or application used by our
system. PPS uses an image file as the input parameter, after processing (probably drawing a
circle or rectangle on the input file), a new file is stored and returned. The test environment
consists of two laptops and one Nokia N95 smart phone. The two laptops install the server
program implemented in P2PMOBILE, but, only one laptop installs the PPS. And we already
advertised PPS application to the peer-to-peer system. Client program is installed in Nokia
phone. Firstly, we take a picture with the smart phone. Then we test the following scenarios:
• Connect our phone to the laptop installed PPS and send the task to the server running on it.
Maintain the client connecting to the server. We get the result in our phone soon after the
execution.
• In this scenario, we connect the phone to the laptop without the installation of the picture
processing software. We are glad to see that result is correctly sent back and the execution
happens in the other laptop which installed the picture processing software.
• In order to simulate mobility, we put the two laptops in different labs away from each other
over 200 meters so that we can leave out of the coverage area of one laptop. We send the task to
the server registered the PPS, after that we disconnect the client from the server, and then
connect the client to the other server and finally we get our expected result by our phone. During
Our movement, the execution is finished and result is stored in previous server. The previous
server was notified when client connected to system again, and sent the result to corresponding
client.

IV. CONCLUSIONS

Remote execution is a tempting approach to execute tasks in mobile environment by

utilizing distributed resources. It reduces processing time, conserves more battery and allows
users to execute tasks that can not be executed in our mobile devices.
In this paper, we present P2PMOBILE to use distributed resources for remote execution of tasks.
Our framework is based on client-server model. The client side runs on mobile devices, it allows
connecting to the server over wireless network and fetching services or applications from
servers. The server side runs on fixed computers advertising and gathering services available in
fixed computers. Two novel approaches are presented in our framework:
• The servers communicate in peer-to-peer manner. It is easier to advertise and discover
services in peer-to-peer environment. More resources in different network are shared, instead of
confining to local network.
• Efficient task migration and result routing. Both task and result pass through no more
than two servers on their way to destination. Mechanism for storing result assures every result is
sent correctly.
Remote execution in mobile environment is achieved in our framework. However, there are a
lot of aspects need to be improved to make our framework a successful one. Easier usage and
compatible with more services or applications are needed to be improved, and the load of the
task executor needs more consideration as well.

REFERENCES

[1] Rajiv Chakravorty, “MobiCare: A Programmable Service Architecture for Mobile Medical
Care”, Proceedings of UbiCare 2006: The First Workshop on Ubiquitous and Pervasive
Healthcare; 532-536; 2006
[2] T. Imielinski and J. C. Navas, “GPS-based geographic addressing, routing, and resource
discovery”, Communications of the ACM, 42(4):86–92, April-June 1999.

[3] Jari Porras, Petri Hiirsalmi and Ari Valtaoja, “Peer-to-peer Communication Approach for a
Mobile Environment.” 37th Annual Hawaii International Conference on System Sciences, 2004.

[4] Arto Hämäläinen, Jari Porras and Pekka Jäppinen, “Service Discovery In Mobile Peer-to-peer
Environment”, 5th Workshop on Applications of Wireless Communications (WAWC'07), 2007.

[5] Ji Zhang, Arto Hämäläinen and Jari Porras, “Addressing Mobility Issues in Mobile
Environment”, MobMid’08, December 1-5, 2008, Leuven, Belgium.

[6] Tommi Kallonen and Jari Porras, “Use Of Distributed Resources In Mobile Environment”,
2006 International Conference on Software in Telecommunications and Computer Networks,
pages 281--285, 29 2006-Oct. 1 2006.