MARS: Portable Support for Community-Based Research Using Cellular Phones
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
MARS: Portable Support for Community-Based Research
Using Cellular Phones
Maria Kazandjieva Margaret Martonosi
Stanford University Princeton University
mariakaz@stanford.edu mrm@princeton.edu
ABSTRACT tially due to their affordability (compared to that of tradi-
With over 2 billion cellular telephones in daily use around tional desktops) and due to their ease of use in areas without
the world, cell phones in just over 30 years have moved from a traditional wired infrastructure.
technological oddities to a major force in the computing Widespread mobile infrastructure is a fundamental en-
world. Because of their ubiquity, cellphones represent a nat- abler of community-based participatory research (CBPR).
ural platform for enabling community-based participatory CBPR can be used to involve regular citizens with research
research. Unfortunately, although they outnumber desktop projects and collaborative learning in an active and em-
platforms by at least a factor of two [3, 2], their software powering way. For example, CBPR has been encouraged
model is considerably more proprietary, including operating in health-related research [1] by giving community members
systems and non-standardized APIs. The closed nature of the chance to share observations on health and disease issues
cell phone programming environments constrains their use with the primary investigators on a research project. Our
as computing platforms, and inhibits the development of ef- work improves on the software infrastructure that makes this
ficient, interoperable, collaborative or third-party software. sort of wide spread participation possible.
In this work, we propose the MARS framework to ad- CBPR involves effort on both sides—researchers and com-
dress these issues of efficient and portable software interop- munity members—and as such requires adequate means of
erability. MARS allows a portable upper layer of software communication between them. While cellular phones are an
(written in Java, and portable to any device running Java obvious choice for this, they are not currently sufficient to
CLDC), to communicate with local or remote devices in a use for computation and data sharing in addition to voice
general but efficient manner. Generality is achieved by im- communication. First, software deployed for CBPR must
plementing sockets, so that device-independent Java code run on a variety of platforms. We would like to maximize
can communicate with device-specific stubs in order to ac- code portability between platforms in order to reduce the
cess local device-dependent services like cameras. Efficiency development overhead. On the community side of a project,
is achieved by implementing “short-cuts” that turn socket ac- software for CBPR should give users the option to opt out
cesses into local file accesses. Through this method, MARS at any moment if it is inconvenient, if batteries are low, etc.
enables portable code to access local services (e.g. battery CBPR must also work with extreme heterogeneity, since it is
levels or camera commands) in a general manner, while also impossible to expect all participants sharing health or crop
improving communication latencies by a factor of at least information, for example, to have the same phone. Leaving
25X for a 100kB chunk of data. Overall, we see this work considerable choice in the participants’ hands makes them
as an important step towards providing general layers for more independent and provides a greater potential for em-
portable cell phone programming. powerment [5].
A fundamental tension exists between the exciting fact
that cell phones are an incredibly widespread programmable
1. INTRODUCTION computing platform today, and the unfortunate fact that
In recent years cell phones have become a powerful com- cell phone programming is constrained by proprietary, non-
puting platform used by millions of people. The cell phone portable software and difficult, often-nonfunctional APIs.
market has particularly surged in developing countries in How, then, can a software developer interested in CBPR
Asia and Africa. In India, for example, we see a growth on create a general program that runs on a myriad of heteroge-
the order of 6 million new cell phone subscribers per month neous devices, that allows users to opt in or out, and that de-
[8]. The popularity of mobile handsets in such regions is par- spite its generality is also capable of accessing device-specific
features such as cameras and battery gauges? In most cell
phones today, such devices are only accessible through APIs
that call into proprietary operating systems such as Sym-
Permission to make digital or hard copies of all or part of this work for bian [7] or Windows Mobile [9]. Furthermore, these APIs
personal or classroom use is granted without fee provided that copies are are often only available through particular programming lan-
not made or distributed for profit or commercial advantage and that copies guages like Symbian C++ (for Symbian) or C/C# (for Win-
bear this notice and the full citation on the first page. To copy otherwise, to dows Mobile). This paper describes MARS, an interface
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
layer for improving the portability and efficiency of cellu-
SenSys’07, November 6–9, 2007, Sydney, Australia. lar telephone software. MARS lets the programmer split
Copyright 2007 ACM 1-59593-763-6/07/0011 ...$5.00.code into a system-specific and a system-independent layer.
Therefore, a system for gathering health vaccination data
could run on a number of different cell phones, reusing the
system-independent code, while also taking into account the
device-specific aspects of each handset.
By writing code using MARS, CBPR can ensure that ev-
ery person can make an individual choice about their par-
ticipation. Furthermore, the upper layer of MARS code will
allow a common interface to software regardless of handset.
This is especially important in areas of low literacy, where
users might have difficulties adjusting to new GUIs. Provid-
ing a unified look and feel to an application and leaving the
choice of hardware to the participant increases the likelihood
of CBPR.
Of course, we have already run into the problem of code
" #$ % !$ &'!
!
interoperability in the desktop computing world. Java for
example, provides programmers with the Java Native In-
terface (JNI) which allows Java programs to call system- ()*++,(*) +-(./0+
specific methods written in C. JNI however has not been 1,)/23*+/4 +-(./0+
implemented for cell phones. In addition, there are a num-
ber of interprocess communication methods that ensure data
exchange between heterogeneous applications on desktops. Figure 1: MARS provides a shortcut for local com-
These include shared memory, message passing, and network munications by using the file-system instead of the
sockets. While sockets provide an easy way for programs physical network interface.
written in different languages to exchange data, we show in
later sections that straightforward, naive implementations
work interface, MARS uses files. In order to keep interfaces
are unacceptably slow.
simple, we only make minor modifications to the already
This paper proposes a solution to the aforementioned prob-
existing Socket/ServerSocket objects in Java and C#. We
lems on cellular phones. We have implemented MARS (Mo-
create a layer of abstraction such that the programmer can
bile Application Replacement Sockets) to provide the neces-
write almost identical code regardless of whether she wants
sary interprocess communications between generic portable
to use remote sockets or MARS sockets for local communica-
upper layer software and the proprietary low level device
tion. This allows the programmer to take full advantage of
interfaces. In the general case, MARS implements commu-
regular sockets through MARS. Figure 2 shows how opening
nications via sockets. In local connections, however, these
a remote connection differs programmatically from commu-
sockets are transparently translated into file-based commu-
nication on the local node. Depending on how the hostname
nications to make them efficient. Thus this work accom-
and port number are specified when a new MarsSocket ob-
plishes the following:
ject is declared, the underlying system can deduce whether
• We design an efficient layered programming interface for standard sockets or files are to be used. This undercover
balancing the needs for both portability and device-specificity detection allows the software programmer to write identical
in mobile phones. code for local and remote connections after the socket has
• To make our interface practical and efficient, we have been established.
built the MARS sockets communications system with There are a number of steps a program must follow when
transparent optimizations for local connections. MARS using MARS local sockets. Below we give a brief description
sockets can be used instead of or in conjunction with of the processes that take place.
traditional sockets for maximum flexibility Application Registration For applications to communi-
• Our prototype implementation demonstrates the viabil- cate with each other, a central facility keeps track of applica-
ity of our approach. It runs on a Cingular 8525 hand tion names and IDs. Therefore, when a cell phone is booted
set and is written in Java and C# for Windows Mobile up, all applications using the MARS infrastructure register.
platforms. Our sockets optimization offers speedups of This registration requires writing an application name to the
25X over standard sockets for 100kB data transfers on regfile and receiving a unique ID. Since the regfile is a global
this platform. structure we provide locking and file-sharing mechanisms to
ensure there is no concurrent file access.
The rest of this paper is organized as follows. Section 2 Peer Application Lookup Once a program is ready to
provides a system overview and experiential results. Section establish a local connection, it performs a peer ID lookup in
3 includes a detailed case study to illustrate the need for the registration file by providing a process name. This is an
MARS. Finally, Section 4 concludes our work. additional step that is not present when standard sockets,
and thus known port numbers, are used. This difference is
2. SYSTEM OVERVIEW AND RESULTS shown in Figure 2. Once the peer ID has been discovered,
In this section we provide an overview of the MARS com- however, the process continues identically for both local and
munication infrastructure. remote connections.
As shown in Figure 1 MARS sockets use the underlying Initiating Connection The commfile it keeps track of
file system to transfer information between two processes. applications requesting to open local connections. Each re-
Unlike standard sockets that transfer data through the net- quest is represented by a “hello” message including the source60000
App 1 App 1 50000
Application
Layer 40000
Time [ms]
wants to start wants to start
local communication remote communication
30000
20000
String hostname = String hostname = 10000
“mars.”+myID; “xxx.xxx.xxx.xxx”;
0
int port = int port = known_port; Sockets MARS Sockets MARS Sockets MARS
Reg.getPeerID("SampleApp");
1 kB 10 kB 100 kB
MARS Data Sent [kB]
Layer
Unified MARS API Figure 3: A comparison of MARS and regular sock-
ets sending varying amounts of data.
MarsSocket m = new MarsSocket(hostname, port);
// write data
// read input data
// close streams and socket programs and implement and deploy it on a Cingular 8525
smart phone running Windows Mobile 5.0. The phone has a
400MHz processor, 128Mb of ROM and 64 Mb of RAM. We
test the efficiency of the MARS interface by timing trans-
Figure 2: MARS can be used for local as well as for missions for different amounts of data. A client initiates a
remote communications. Here we show what code connection, sends the corresponding number of bytes and
differences a programmer will experience depending waits to receive an “OK” acknowledgement from the server.
on the context in which MARS is used. Figure 3 shows our results. The setup time includes time
needed to create client and server sockets, obtain applica-
tion IDs, open any necessary files, complete a TCP/IP hand-
and destination application IDs. A client program writes a shake, and so on. The transmission time, on the other hand,
communication request, while a server periodically checks is the time for sending all the bytes over and receiving the
the file for outstanding messages. These two actions are acknowledgement. Both sockets and MARS have a steady
equivalent to the remote socket listen() and connect() meth- setup overhead regardless of the data size - between 1700
ods for in Java. and 1800 ms. The communication speed, however, differs
Communication Period Once an application discovers dramatically between the two methods. Sending as little as
a “hello” message, the two peers proceed to exchange data. 1kB of data benefits from a 2X communication latency im-
The exchange of data does not require the programmer to provement when MARS is used and the savings go up to
know whether communication is local or remote. All that is 25X or more for sending 100kB. Socket communication via
necessary is the declaration of the MarsOutputStream and the loopback interface using TCP/IP involves the operating
MarsInputStream objects, used for sending and receiving system as well as the underlying physical network interface,
data respectively. Under the cover, MARS determines if thus affecting negatively the speed of communication. On
data is to be sent using a network connection or simply writ- the other hand, cell phones use flash-based storage systems,
ten to a file. MARS has a file naming convention that allows therefore making writing and reading data fast. In addi-
applications to easily detect the read and write files without tion, MARS operates at the OS level resulting in addition
any effort on the programmer’s side. speedups. Overall, the time savings provided by MARS in-
Every application-to-application local communication re- crease without a bound after the one-time setup period is
sults in the creation of two files. Each one is a data input completed.
stream for one of the peers and a output stream for the other
peer. Therefore, if an application want to communicate to 3. CASE STUDY: RESOURCE-AWARE CAM-
two peers, it will create two different output files, and will ERA USAGE
read from two different input files. Again, this is analogous
to using different port numbers for different communication Previous work has looked at economic models for resource
sharing in wireless networks [4]. For example, in a network
pairs. Allowing only one application to write to a file in
of mobile phones, one handset might request to use another
a given communication round eliminates many of the con-
one’s camera. Taking advantage of this idea and existing
tention and locking issues we would see if two applications
wireless infrastructure, farmers in rural areas could request
were sharing one file.
photos of crops from each other. This would enable them
As in the case of network communications, we assume
to have up-to-date information from various locations where
that the applications that are exchanging data have previ-
good are grown. We would like provide every cell phone with
ously agreed on a protocol. Therefore, MARS allows the
a program that determines if there is sufficient energy to take
program to block waiting for input. At the end of a com-
a photo, and if so, take a snapshot and send it to another
munications period, each application is expected to send a
phone. We could simply write one large program responsi-
“goodbye” message, indicating that communication files are
ble for monitoring system status, accessing camera to take
ready to be deleted. Removing files at the end of a successful
pictures, as well as communicating with other nodes. This is
connection ensures that the required storage space is freed
feasible if we assume that all participating phones are run-
up.
ning the same operating system. However, in the more likely
Results We developed MARS for use with Java and C# !"#$ %%
BatteryLevel batteryLevel =
SystemState.PowerBatteryStrength; iBatteryStrengthIndex =
iBatteryInfoV1.iChargeLevel
BatteryState batteryState =
SystemState.PowerBatteryState; iBatteryInfoV1.iChargeLevel;
iState = EStateChargerInfo; &'()*
&+,)*- .,./ )01
.2)345 43 3'6)
CameraCaptureDialog ccd = new
CameraCaptureDialog();
ccd.Mode = CameraCaptureMode.Still; iState = ESnappingPicture;
ccd.Resolution = new Size(160, 120); iCamera->StopViewFinder();
ccd.StillQuality = iCamera->CaptureImage();
CameraCaptureStillQuality.High;
ccd.ShowDialog();
Show();
fileName = ccd.FileName;
photo.Image = new Bitmap(fileName);
Figure 4: Since cell phones run on proprietary operating systems and access system-level information through
proprietary languages, one needs to rewrite system-specific code for various platforms.
1: int peerID = CommunicationReg.getPeerID(“ProccessName”);
2: MarsSocket local_m = new MarsSocket("mars." + myID, peerID);
3: MarsInputStream local_in = local_m.getInputStream();
4: battery = local_in.read(); MARS local and
5: image_filename = local_in.read(); remote
communications
6: MarsSocket remote_m = new MarsSocket(“168.126.8.11”, 1337);
7: MarsOutputStream remote_out = remote_m.getOutputStream();
8: remote_out.writeBytes(new ImageObject(image_filename).getBytes());
Figure 5: The MARS APIs provide a unified way to establish both local and remote connections. Where
possible local connections are transparently converted to file accesses, thus decreasing communication laten-
cies.
case, users will own cell phones with the Windows Mobile tains data from its peer local application. Lines 6 through 8
OS, Symbian OS, Linux, and even Openmoko [6]. Thus we show how we create a remote socket and send a photo, byte
would like to reuse code as much as possible, while still al- by byte.
lowing system-specific operations. Therefore a MARS-based Overall, we have achieved two main goals:
approach is ideal; an upper level code will be used for com- • code has been successfully divided into an upper, system-
munication between devices and system-independent tasks, independent layer and a lower, system-specific layer al-
while a lower level will be used to access the system-specific lowing code reusability and system interoperability
information (camera availability and battery level) and de-
vices such as the camera itself. • the APIs for local and remote communications have been
We implement this example on the Cingular 8525 hand unified by using MARS sockets, while transparently con-
set and use our MARS prototype to enable fast communi- verting local connections to file accesses that improve
communication latencies.
cations. Figure 4 shows code snippets for obtaining bat-
tery information and taking a picture on Windows Mobile In this example, the data sent using local MARS commu-
OS and Symbian OS. This is the lower level code which is nications is about 100 bytes (battery and camera informa-
system-specific and needs to be rewritten for different oper- tion). In Figure 6 we see how the speed of communication
ating systems. Then in Figure 5 we present MARS code that compares depending on whether MARS or regular sockets
is partially used for local communications on both the upper are used. As expected, MARS performs better, showing a
and lower level of software, as well as for remote communi- 2X improvement over standard sockets via localhost. The
cation on the upper, Java level. In Figure 5, lines 1 through setup time for both types of connections is about the same,
5 show how an application obtains a peer ID, creates a new therefore, it is the usage of files that causes the speedup
local socket (transparently translated to file access), and ob- in communication latencies. An application that monitors4000
Time [ms] 3500
3000 send setup
2500
2000
1500
1000
500
0
MARS Sockets
Type of Communication
Figure 6: For the system monitoring example,
MARS communication latencies are roughly one half
that of the sockets implementation.
system status in a similar way but on regular basis will ben-
efit from MARS even more because once setup cost is paid,
regular fast data transmissions will keep bringing additional
time savings.
4. CONCLUSION
This paper explores the design and implementation issues
of MARS, an interprocess communication method aimed at
cellular phones. MARS allows us to connect processes writ-
ten in different languages and thus provides the ability to
separate code into system-specific and system-independent
counterparts. The separation into lower and upper level
code promotes reusability of the upper layer on various cell
phone and desktop operating systems. Our experiments
show that for a 100kB chunk of data sent from a C# to
a Java application, communication times are 25 times faster
using MARS instead of regular network sockets. The MARS
APIs make the transition from sockets easy by unifying
method calls for remote and local connections. We believe
that a fast and efficient method for local communications
will allow re-usability of code and foster the creation of new
application to be deployed on variety of cellular phone.
5. REFERENCES
[1] Community Based Participatory Research Conference
Summary, 2001.
http://www.ahrq.gov/about/cpcr/cbpr/.
[2] CIA world factbook. https://www.cia.gov/library/
publications/the-world-factbook/, 2007.
[3] iMedia Connection. Cell Phone Usage Continues to
Rise, Apr. 2002.
http://www.imediaconnection.com/news/581.asp.
[4] Kazandjieva, M., and Martonosi, M. Lightweight
Economic Models for Resource Sharing in Wireless
Networks, Mar. 2007. Poster. In Proc. ACM SIGCSE.
[5] Learner Voice, 2007. http://futurelab.co.uk.
[6] OpenMoko. http://www.openmoko.org/, 2007.
[7] Symbian Developers Network.
http://developer.symbian.com, 2007.
[8] Timmons, H. For the rural poor, cellphones come
calling, 2007. http://www.iht.com/articles/2007/05/
06/business/wireless07.1-44394.php.
[9] Windows Mobile Developer Center.
http://msdn2.microsoft.com/en-us/windowsmobile,
2007.You can also read
