Conference PaperPDF Available

Location-based Publish/Subscribe


Abstract and Figures

This paper introduces the concept of location-based publish/subscribe (LPS), which allows mobile ad hoc applications to anonymously communicate with each other, depending on their locations. With this concept, publish/subscribe topics are typically expressed in a dynamic manner including proximity criteria, e.g., "I subscribe to all events on topic T published within some range R". We advocate that location-based publish/subscribe is a key programming paradigm for building mobile ad hoc application, and sketch our current implementation, which is based on standard APIs of the Java 2 platform, Micro Edition
Content may be subject to copyright.
Location-based Publish/Subscribe
Patrick Th. EugsterBenoˆıt GarbinatoAdrian Holzer
Sun Microsystems
Client Solutions
CH-8604 Volketswil, Switzerland
Universit´e de Lausanne
Distributed Object Programming Lab
CH-1015 Lausanne, Switzerland
{benoit.garbinato, adrian.holzer}
UNIL Technical Report
This paper introduces the concept of location-based publish / subscribe, which allows
mobile ad hoc applications to transparently and anonymously communicate with each oth-
ers, based on their location. With such a service, publish/subscribe topics are typically
expressed as dynamic proximity criteria, e.g., ”I subscribe to all events published by peers
located within a given range”. We advocate that location-based publish/subscribe is a key
programming paradigm for building mobile ad hoc applications. Indeed, a mobile ad hoc
application can be characterized as having an inherently ”here & now” semantics, i.e., it only
makes sense (and should thus only execute) when adequate conditions are met ”right here
and right now”. We illustrate the use of our location-based publish/subscribe (LPS) abstrac-
tion on two typical mobile ad hoc applications, namely a Peer-to-Peer Trac Jam Warning
service and a Ubiquitous Flea Market application. We also sketch our implementation of
LPS, based on asynchronous messaging APIs and location APIs of the Java 2 platform,
Micro Edition (J2ME).
1 Introduction
In recent years, several researches have been studying the next generation of mobile commu-
nication and information infrastructures, based on self-organisation approaches, e.g., Termin-
odes [20], CarNet [26], AODV [28]. In this context, ad hoc networks are expected to play a key
role in the future, although nobody knows which emerging technology will win (Bluetooth [23],
Wi-Fi [5], GPRS/UMTS [4], etc.) and when it will be ready for prime time. When this will
happen however, it seems reasonable to forecast that adequate programming frameworks will
be necessary to leverage ad hoc networks and build the next generation of mobile applications.
In this paper, we propose a framework that is independent of the actual network technology.
This research is partly funded by the Swiss National Science Foundation, in the context of Project number
This approach makes it possible to develop mobile ad hoc applications right now, using today’s
widely spread technology (e.g., GPRS). This approach will also facilitate the porting of mobile
ad hoc applications to future emerging networks (e.g., Wi-Fi-based metropolitan area networks).
In a genuine ad hoc network, no fixed infrastructure is available, and it is the distance among
nodes, or rather their proximity, that determines its boundaries. The underlying technology then
defines the actual network range: some technologies are limited to Personal Area Networks (up
to 10 meters for Bluetooth), whereas other technologies allow for Local Area Networks (almost
100 meters for recent Wi-Fi technologies). For Murphy et al. however, the mere collocation of
nodes is a necessary but not sucient condition to form an ad hoc network: collocated nodes
must in addition be willing to collaborate [27]. Since nodes appear and disappear often in an
ad hoc network, this willingness to collaborate usually results in transitory communities.
Typical mobile ad hoc applications imply a mix of virtual and real-world interactions. With
the Ubiquitous Flea Market application [16] for instance, sellers and buyers first interact with
each other virtually, to find each other and agree on a deal, and then carry out a real-world
exchange of physical goods. More precisely, a buyer (resp. seller) is notified when an interested
seller (resp. buyer) is located within some user-defined range, allowing both peers to eventually
carry out a real-world interaction, i.e, the actual physical exchange. Likewise, mobile ad hoc
applications such as FriendZone by Swisscom and SynchroBeat by Swatch alert closely located
users with matching profiles, in order to encourage real-world dating. Furthermore, mobile
ad hoc games such as Mogi [10], CityTag [31, 30], and Pirates! [3], all rely on the geographical
locations of players to determine their positions on some virtual arena.
1.1 Programming Abstractions
Many authors have proposed abstractions for programming in mobile ad hoc environments.
Most approaches rely on a form of tuple space combined with a notion of context [7, 22, 14].
The tuple space provides anonymous communication between peers, while the context is used
to improve location-awareness. To provide asynchrony, tuple spaces are extended by callback
primitives on the consumer side, coming close to a publish/subscribe style. To further decouple
peers, interacting entities are viewed as agents, which may roam across several tuple spaces.
One can however argue that it is somewhat contradictory to promote tuple spaces in a mobile
ad hoc environment. Indeed, the tuple space abstraction originally modelled one global, unique,
shared space [17], which presents a paradigm mismatch with the very notion of mobile ad hoc
applications forming transitory collaborating communities.
For the above reasons, we strongly advocate that the publish/subscribe style is what best
suits mobile ad hoc applications: this leads to a slimmer and more asynchronous interaction,
and better fits such applications. The key dierence between our location-based publish/subscribe
(LPS) and more classical topic- & content-based variants lies in the existence of an external con-
text that impacts the matching of published events and subscriptions. This notion of context,
which is used in addition to the dynamic content of events for matching them against sub-
scriptions, makes LPS a generalization of the topic- & content-based publish/subscribe mixture,
which has become the de facto standard in industrial settings. Similar to a topic, a context
is handled separately from events to which it is associated. Just like inherently static topic
information can be used by a topic-based engine to eciently route and filter events by pre-
establishing connections between potential publishers and subscribers, context information can
be used by a LPS implementation for improving eciency when conveying location information
in an ad hoc application.
1.2 Contribution & Roadmap
The contributions of this paper are the following. In Section 2, we propose a definition of
mobile ad hoc applications that is independent of ad hoc networks. This independence allows
us to accurately capture the essence of mobile ad hoc applications and to better point out
their need of an asynchronous and anonymous, yet location-aware communication paradigm. To
address this need, we introduce Pervaho, a platform providing high-level support for programing
mobile ad hoc applications; the location-based publish/subscribe (LPS) communication model
is the cornerstone of the Pervaho platform. Section 3 presents the LPS paradigm in details,
along with the specification of a corresponding service in Java. We also illustrate the use
of LPS via two concrete examples of mobile ad hoc applications. Section 4 then provides
an overview of our current implementation of the LPS service in Pervaho, based on standard
asynchronous messaging APIs and location APIs of the Java 2 platform, Micro Edition (J2ME).
Finally, Section 5 discusses related work, while Section 6 concludes with some open issues and
perspectives for future work.
2 The Pervaho Platform
Ad hoc networks exhibit an inherent here & now nature: at some point in time (now), the
network is defined by all nodes that are both within a given range and online (here). This
“here & now” nature is also what characterizes ad hoc applications [16]. However, we believe
that defining ad hoc applications simply as pieces of software that run on ad hoc networks does
not adequately capture their essence. By coupling ad hoc applications to a particular network
architecture, one reduces the generality and eectiveness of the definition. In an ad hoc network
for instance, the willingness to collaborate directly translates to going online or oine, which
does not allow for finer control over the membership of ad hoc communities. As a consequence, we
propose hereafter a definition of mobile ad hoc applications that does not require the existence of
an underlying ad hoc network (yet does not exclude it). We then introduce Pervaho, a platform
for programming mobile ad hoc applications.
2.1 Mobile Ad Hoc Applications
We define an ad hoc application as a self-organizing application composed of mobile autonomous
devices, interacting as peers and whose relationships are meaningful because they are within some
physical range defined by the application semantics. That is, an ad hoc application must exhibit
three features: (1) a set of autonomous mobile devices, (2) a peer-to-peer communication model,
and (3) a proximity-based semantics.
It is important to note that our definition neither requires nor excludes the presence of an
ad hoc network. The peer-to-peer communication model, for example, is implied but by no means
limited to ad hoc networks, as demonstrated by the success of peer-to-peer music distribution
over the Internet [11]. Peer-to-peer communication simply means that collaborating entities do
not assume predefined client or server roles but rather interact directly, via some underlying
communication layer. The fact that the communication layer relies on a genuine ad hoc network
or not is irrelevant for ad hoc applications, just as applications using TCP do not see gateways
through which connections are routed.
By abstracting the network level, we can now imagine mobile ad hoc applications defin-
ing proximity criteria within the range of a Metropolitan Area Network (MAN), i.e., several
kilometers, and communicating in a peer-to-peer manner across such distances. This is simply
impossible with genuine ad hoc network technologies currently available, yet can be achieved
today if we set up mobile phones to access Internet via some GPRS/UMTS gateway and to
build a peer-to-peer overlay network. The responsibility of building such an overlay network
would typically be that of the LPS service.
2.2 Location-Aware Communication
Having decoupled mobile ad hoc applications from the underlying network technology, we still
need a way to express proximity-based semantics. Here, we advocate that mobile ad hoc appli-
cations require some kind of location-aware communication, supporting anonymous and asyn-
chronous interactions, in addition to the obvious location service.1Furthermore, we strongly
believe that location-aware communication should be provided in the form of a Location-based
Publish/Subscribe service. The Pervaho platform precisely aims at oering such programming
support for mobile ad hoc applications. Its architecture consists of two main layers: a high-level
programming model and an underlying location-aware communication service.
Connected Limited Device Configuration (CLDC)
Mobile Information Device Profile (MIDP)
Location (JSR!179) Wireless Messaging (JSR!120)
Location-based Publish/Subscribe
The Bystander Programming Model
J2ME Core
J2ME Optional
The Pervaho
Focus of
this paper
Figure 1: The Pervaho Platform Architecture
Figure 1 presents an overview of the Pervaho platform architecture. At the top level, the
Bystander programming model allows programmers to express mobile ad hoc applications via a
declarative extension of the Java 2 platform, Micro Edition (J2ME). This model stems from the
following observation: a mobile ad hoc application has an inherently ”here & now” semantics,
i.e., its life-cycle is beyond the sole control of its users, and strongly depends on its geographical
and temporal context as well. To capture this specificity, the Bystander model is implemented
as a lightweight Java language extension oering the notion of condition-driven methods: a
mobile ad hoc application consists of a set of condition/method pairs associated declaratively,
where the condition expresses what the context should oer ”right here and right now” for the
corresponding method to be executed. Further details about this Java extension are beyond the
scope of this paper.
The other key layer of the Pervaho platform is the Location-based Publish/Subscribe service,
which constitutes the focus of this paper. Next section presents its specification in Java, together
1The Location API of the Java 2 platform, Micro Edition (J2ME), oers a typical example of location ser-
vice [21].
with concrete examples on how to use it directly, i.e., bypassing the Bystander declarative
programming model. Section 4 then presents the implementation of our current prototype. As
suggested in Figure 1, this implementation relies on the mobility APIs of the Java 2 platform,
Micro Edition (J2ME).
3 Location-based Pub/Sub
The core concept underlying publish/subscribe is to view interacting entities in two roles: a
first role, that of publisher, consists in generating events, and a second one, that of subscriber,
consists in advertising interests in particular kinds of events. The goal of the publish/subscribe
service is to, upon occurrence of an event, trigger notifications on the subscribers whose interests
match the given event.
Original Flavors. In the original topic-based publish/subscribe paradigm, static topics are
used to make the matching between events and subscribers, i.e., subscribers express interest
in particular topics, under which events are explicitly advertised by publishers. In that sense,
topics can be viewed as a form of context external to the events, or more precisely, to the data
associated with the events. In content-based publish/subscribe, the inherent data associated
with the dynamic events defines which events will be notified to which subscribers.
Blends. Content-based publish/subscribe, which advocates the very attributes of events as
matching criterion between publications and subscriptions, is often viewed as a generalization
of topic-based publish/subscribe, as the former can be used to express the latter. As illustrated
by most systems deployed on an Internet-scale, this argument is however not entirely true,
as these systems provide a mixture of both, precisely because the (static) notion of context,
external to the event data, though a simplistic one in topic-based publish/subscribe, is useful
for implementation eciency. For instance, the underlying publish/subscribe engine can rely on
multicast groups, which are mapped to topics and built prior to publications taking place.
A New Recipe. Location-based publish/subscribe starts from a generalization of the combi-
nation topic & content-based publish/subscribe. That is, an event is published in a particular
geographical context and the matching process is performed dynamically on this context, as well
as on the content of events. The explicit distinction of content and geographical context is
motivated by the nature of mobile ad hoc applications, and location information must clearly
be treated as first class object, for the LPS engine to eciently handle this information (just
like topics).
Location is of course not the only context information that could be relevant to mobile
ad hoc applications. Other physical values (e.g., speed, temperature, etc.), as well as resource
availability (e.g., battery power, computing resources, etc.) could be useful as context informa-
tion, depending on the actual application, and on the sensing and monitoring capabilities of the
mobile devices being used.2Nevertheless, we strongly advocate that location-aware communi-
2In Pervaho, any context information is made available to the Bystander model (including location) via pred-
icates controlling method executions. The corresponding context events might however originate from dierent
underlying services (one of them being LPS), depending on their types.
cation is a fundamental need of mobile ad hoc applications, and that it should be provided as a
location-based Publish/Subscribe service.
3.1 Location-based Pub/Sub Service
The Location-based Publish Subscribe/Service allows mobile ad hoc applications to transpar-
ently and anonymously communicate with each others via a subscription and publication system,
based on their location. As illustrated in Figure 2, the LPS service interface proposes four meth-
ods, which will be described in the following.
public interface LPSS extends Connection {
void publish(Event e, long range);
Publication publish(Event e, long range,
long timeToLive);
void unpublish(Publication pub);
Subscription subscribe(Event e, EventHandler hd,
long range);
void unsubscribe(Subscription sub);
Figure 2: API of the LPS Service in Java
Publications. A publication represents an event distributed within a determined geographical
range around the publisher. This range is called the publication space. To create a publication,
publishers use the publish() method. A publication can be persistent or non-persistent. With
a non-persistent publication, the event is oered for distribution to all subscribers located in the
publication space at the time of the publication. A non-persistent publication is performed thanks
to the publish() variant taking two arguments, i.e., an event and a publication range (expressed
in meters). With a persistent publication, the event is oered for distribution to all interested
subscribers located or entering the publication space before the event is unpublished. A persistent
event can be unpublished either by the publisher or by the service after a determined period
known as its time-to-live. The publication space is centered around the publisher, implying that
the publication space moves along with the publisher between the time the event is published
and the time the event is unpublished. A persistent publication is performed thanks to the
publish() variant taking three arguments, i.e., an event, a publication range and a time-to-live
(expressed in milliseconds). This method also returns a publication object, which can be used to
explicitly unpublish the persistent event before its time-to-live expires, using the unpublish()
Subscriptions. A subscription is a request to receive events published by producers located
within a determined geographical range around the subscriber. This range is called the subscrip-
tion space. In addition, content-based selection of events can be achieved via an event template.
A subscription is performed thanks to the subscribe() method, which takes an event template,
a subscription range (in meters) and an event handler as arguments. The event template is
an event object used as filter: this object contains all attributes a published event is required
to have in order to be considered a match. The event handler is an object implementing the
standUp() callback, which is triggered asynchronously when a matching event is found (the
event being passed as argument). This method is responsible for handling the matching event.
The subscribe() method also returns a subscription object, which can be used to cancel the
corresponding subscription via the unsubscribe() method.
Matching Rule. In order to be called a match, a publication/subscription couple has to
meet two conditions: (1) the location match and (2) the content match. The location match
condition is met when the publisher and the subscriber are both located in the intersection of the
publication and the subscription spaces, as illustrated in Figure 3. The content match condition
is met when the published event contains at least all attributes specified in the subscribed event
template. This is similar to what most content-based publish/subscribe platforms are oering.
Figure 3: Location-based Event Matching
In the remainder of this section, we illustrate the use of our LPS Service via two typical mobile
ad hoc applications, namely a Trac Jam Warning system and a Ubiquitous Flea Market ap-
plication. The first example relies on a pure publish/subscribe communication scheme, whereas
the second example relies on a publish/subscribe scheme to achieve a kind of application-based
peer discovery, which then leads to a private point-to-point communication. Since our goal is
to illustrate how the LPS paradigm supports the programming of mobile ad hoc applications,
we greatly streamlined the code presented hereafter, for sake of clarity and conciseness. In
particular, we left out user interaction and persistent storage issues, as well as sophisticated
content-based event selection.
3.2 Trac Jam Warning
The Trac Jam Warning system is a mobile ad hoc application allowing drivers to share infor-
mation about trac jams that might aect them. When some driver experiences a trac jam,
he can use the application to inform other users, allowing them to take an alternate route. A
trac jam is an event that occurs at a determined geographical location for an undetermined
period of time. As such, it is necessary to persist the trac jam warning at its location. So,
as shown in Figure 4, the application relies on fixed devices, known as trac agents, which are
placed along the road. These agents are responsible for persisting trac jam warning events.
A driver experiencing a trac jam will inform trac agents nearby (Step 1), who will in turn
inform the other drivers (Step 2).
Trac Agent Implementation. Trac Agents are fixed communication devices located
along the road and relying on the methods listed in Figure 5. The startAgent() method is
called when the application is switched on. This method subscribes to trac events published
by drivers within a 5 km range. When such an event is received, the message handler calls
Figure 4: Trac Jam Warning System
informDriverAgents(). This method publishes a persistent trac jam warning event for a one
hour within a 20 km range.3When the application is switched o, the stopAgent() method is
called and the agent unsubscribes from trac jam warning events.
Driver Agent Implementation. Drivers use mobile devices to communicate, e.g., smart
phones or PDAs. Each such device is running a so-called driver agent, which represents the driver
with respect to the application. The driver agent relies on the methods listed in Figure 6. The
startAgent() method is called when the application is switched on. This method subscribes to
trac events published by trac agents within a 20 km range. Upon delivery, the message han-
dler notifies the driver by displaying a trac jam warning, thanks to method displayWarning().
A driver experiencing a trac jam executes the informTrafficAgents() method, which pub-
lishes a trac jam warning event aimed at trac agents situated within a 5 km range. When the
application is switched o, the stopAgent() method is called and the driver agent unsubscribes
from trac jam warning events.
3.3 Ubiquitous Flea Market
The Ubiquitous Flea Market is a peer-to-peer mobile ad hoc application that mimics traditional
flea markets but somehow loosens their temporal and geographical constraints. Indeed, a tra-
ditional flea market takes place at a given time in a given place, and assume predefined buyer
and seller roles. By contrast, the Ubiquitous Flea Market (UFM) is available anywhere and at
any time, and each user has the ability to provide both a list of items to sell and a list of items
to look for. As the mobile device is moving, a local UFM agent is scanning its surroundings
for peer sellers and buyers. The UFM application is also responsible for the matching process,
so the user is only notified when one of the supplied or demanded items is matching that of
another user. At this point, both users have to explicitly confirm their will to contact each other
(for obvious privacy reasons). Because all deals are eventually finalized on a physical level (the
3Other Trac Agents situated within a 5 km range could also receive and hence relay the published event,
which is not what we want. We are using content-based filtering to avoid this (via the receiver attribute).
class TrafficAgent {
LPSS lpss;
Subscription sub;
static long timeToLive= 3600000;
static long range= 5000;
public void startAgent() {
lpss = (LPSS)"lpss://trafficJam");
Event tmpl = new EventImpl();
tmpl.setAttribute("receiver", "agent");
EventHandler handler = new EventHandler() {
public void standUp(Event e) {
sub = lpss.subscribe(tmpl, handler, range);
public void stopAgent() {
public void informDriverAgents() {
Event warning = new EventImpl();
warning.setAttribute("receiver", "driver");
warning.setAttribute("road", "A1");
warning.setAttribute("direction", "Geneva");
warning.setAttribute("area", "Coppet");
lpss.publish(warning, 4 * range, timeToLive);
Figure 5: Trac Agent Implementation
actual exchange), each item supply or demand is associated with a range restricting the area
where matching could occur.
Flea Agent Implementation. Flea agents are typically running on small mobile devices, e.g.,
smart phones, PDAs,4and rely on the methods listed in Figure 7. The startAgent() method
is called when the application is switched on: it initializes the various instance variables, in
particular two hash tables keeping track of supplied and demanded items. This method also
defines the event handler that will be triggered when a match is found. The addSupply() method
is called whenever the user has a new item to oer. This method builds up and publishes a
persistent event containing the item description and the URL of the agent itself. In addition, the
user can express geographical contraints on the actual exchange, by restricting the publication
area via the range parameter. The URL is then used by the buyer to contact the seller when
a match is found (see description of method standUp() hereafter). Finally, the time-to-live
parameter is set to 0, meaning that the publication will never expire unless cancelled explicitly.
The addDemand() method plays a similar role for items that the user is looking for. The key
dierence lies in the fact that demands are advertised via subscriptions, not publications. As a
consequence, it is the LPS that performs the matching of demands and supplies. Here again,
the user can express contraints on the exchange by restricting the subscription range. Methods
addSupply() and addDemand() are also keeping track of publications and subscriptions, via the
supplies and demands hash tables. These hash tables are used by methods removeSupply(),
4As driver agents in our previous example, a flea agent executes within a MIDlet [2].
public class DriverAgent {
LPSS lpss;
Subscription sub;
static long range= 5000;
public void startAgent() {
lpss = (LPSS)"lpss://trafficJam");
Event tmpl = new EventImpl();
tmpl.setAttribute("receiver", "driver");
EventHandler handler = new EventHandler() {
public void standUp(Event e) {
Subscription sub =
lpss.subscribe(tmpl, handler, 4 * range);
public void stopAgent() {
public void informTrafficAgents() {
Event warning = new EventImpl();
warning.setAttribute("receiver", "agent");
lpss.publish(warning, range);
private void displayWarning(Event e) { ... }
Figure 6: Driver Agent Implementation
removeDemand() and stopAgent() to cancel publications and subscriptions.
The standUp() method of the event handler defined in startAgent() is triggered when-
ever a supply and a demand are matching. When this happens, the local buyer is noti-
fied and asked whether the agent should contact the seller; this notification is performed
by method notifyMatch(). If the buyer tells the agent to go on with the deal, method
contactPeerFleaAgent() initiates a point-to-point communication with the other peer, us-
ing the supplied URL. To ensure fairness in privacy, this communication remains anonymous for
both users, until the seller explicitly accepts to go on with the deal.
4 Implementation Overview
Our current implementation of LPS is based on the Mobile Information Device Profile (MIDP)
of the Java 2 platform, Micro Edition (J2ME) [19, 2]. The MIDP specification extends the
Connected Limited Device Configuration (CLDC), which is based on a limited and compact
Java virtual machine, the K virtual machine (KVM) [1]. The CLDC specification defines the
base set of APIs along with the KVM for resource-constrained devices like mobile phones,
pagers, and mainstream personal digital assistants. When coupled with a profile such as MIDP,
it provides a solid Java platform for developing applications to run on devices with limited
memory, processing power, and graphical capabilities.
From the communication viewpoint, LPS relies on the Generic Connection Framework (GCF),
an essential part of CLDC that provides an extensible, generic I/O framework for resource con-
strained devices. A total of seven interfaces are defined in GCF, with Connection at the root.
public class FleaAgent {
LPSS lpss; String myURL;
Hashtable supplies, demands;
EventHandler handler;
public void startAgent() {
lpss = (LPSS)"lpss://fleaMarket");
myURL = "ssl://";
supplies = new Hashtable();
demands = new Hashtable();
EventHandler handler = new EventHandler() {
public void standUp(Event e) {
if ( notifyMatch(e.getAttribute("item")) )
public void stopAgent() {
Enumeration keys = supplies.keys();
while (keys.hasMoreElements())
(Publication) supplies.get(keys.nextElement()) );
keys = demands.keys();
while (keys.hasMoreElements())
(Subscription) demands.get(keys.nextElement()) );
public void addSupply(String item, long range) {
Event supply = new EventImpl();
supply.setAttribute("item", item);
supply.setAttribute("url", myURL);
Publication pub = lpss.publish(supply, range, 0);
supplies.put(item, pub);
public void addDemand(String item, long range) {
Event demand = new EventImpl();
demand.setAttribute("item", item);
Subscription sub =
lpss.subscribe(demand, handler, range);
demands.put(item, sub);
public void removeSupply(String item) { ... }
public void removeDemand(String item) { ... }
private boolean notifyMatch(String item) { ... }
private void contactPeerFleaAgent(String url) { ... }
Figure 7: Flea Agent Implementation
While many device vendors only support HTTP, the GCF foresees support for various protocols.
The Connector class acts as a factory for instantiating such protocols. As illustrated in Section 3,
our LPS implementation integrates in the GCF infrastructure, which supports URL-based pro-
tocol selection, e.g.,,ssl://,lpss://trafficJam,
etc. As far as location-oriented support is concerned, LPS relies on the Java Specification Re-
quest (JSR) 179 [21], an APIs for managing location information in J2ME. More precisely, we
have been using the ocial reference implementation provided by Nokia to test our approach.
4.1 LPS Architecture
Our current prototype of LPS relies on a web service accessed via HTTP by clients, i.e., mobile
devices; this web service plays the role of communication backbone and performs the matching
between published events and subscribers. In addition to the web sercice, our architecture is
based on a client module running on each mobile device; this module is in charge of relaying
information to the web service, which acts as a typical broker in message-oriented middleware.
This hybrid approach (static backbone/dynamic clients) is simple to implement and oers a
high degree of availability and reliability. Furthermore, given the current uncertainty regarding
the future winning ad hoc network technology, this architecture is well suited for a realistic and
present implementation of LPS, relying of the mobile telephony infrastructures of GSM oper-
ators. It is important to note that this implementation does not contradict our definition of
mobile ad hoc applications (Section 2). On the contrary, it illustrates the freedom one obtains
when decoupling mobile ad hoc applications from the notion of ad hoc network.
Client module. The client module is responsible for handling all five incoming requests from
the ad hoc application, e.g., publish (persistent and non-persistent), subscribe, unsubscribe and
unpublish. For each request it creates a specific message containing (1) the client ID, (2) the
request type (publish, subscribe, etc.) and (3) a publication or subscription ID. In the case
of new subscriptions or publications, the message also contains the publication/subscription
information (e.g., event, range) and the device’s current geographic location, which is obtained
thanks to the JSR-179 location service. The client module also sends a second type of messages:
location update messages. These messages are sent to the server whenever the module detects
a location change. More precisely, this is only necessary if the corresponding mobile ad hoc
application has an active subscription or an active persistent publication. The stack layering of
the client module is pictured in Figure 1. Contrary to what this figure suggests, however, the
client stack is not strictly vertically layered. For example, some parts of the LPS layer directly
access the MIDP or the even CLDC APIs.
Web Service. The web service is responsible for checking potential event matches each time
it receives a relevant update from some client, i.e., a new publication, a new subscription or
a location change. To achieve this, it keeps track of (1) all the persistent publications and
the location of their publishers and (2) all subscriptions, the location and the address of their
subscribers. When a new match is found, it sends the matching publication/subscription couple
to the concerned subscriber’s client module, using its address. Upon reception of this message,
the client module triggers the standUp() method on the subscription’s event handler.
4.2 A Decentralized Alternative
To validate our approach on genuine ad hoc networks, we are currently working on the im-
plementation of a gossip-based algorithm for propagating both events and subscriptions within
ad hoc network communities. Our algorithm is inspired by approaches such as [9, 24], which
it extends by additionally making use of application-defined location information to both guide
and limit the space of propagation of events. For example, if the range associated to some
persistent event exceeds the range supported by the actual ad hoc network technology, the event
must be stored by some intermediate peer. This issue is avoided by alternative abstractions (see
Section 5), by shifting the responsibility to application developers, making their job significantly
more complex. Providing strong end-to-end guarantees is indeed in certain cases hard if not im-
possible. As node mobility defines the interaction, and not vice versa, certain scenarios with
strong mobility might simply lack opportunities for storing and relaying events. More precisely,
nothing ensures that an event which is made persistent within a given perimeter can indeed
be stored within that geographical region, as nothing ensures the presence (and willingness to
collaborate) of peers within that region.
To address this issue, our approach considers dierent levels of reliability. With simple,
unreliable, semantics, no strong guarantee is given on the delivery of potentially matching events.
Through the use of gossip-based techniques, such a guarantee typically takes the form of a
probability. We expect a quantification of such guarantees to be the outcome of our ongoing
work on analyzing our gossip-based algorithm. For achieving strong reliability guarantees, the
use of (and access to) a web service can not be avoided.
5 Related work
This section summarizes eorts closest to LPS, and points out dierences between the discussed
approaches and our own.
5.1 Tuple space et al.
Many related programming abstractions for ad hoc computing [14, 7, 22] inherit from the Linda
tuple space, where producers insert tuples, and consumers extract tuples. These approaches
dier from the original tuple space in three points, namely in the (1) the assumption that there
is not a single, globally accessible, space, but rather various “local” spaces, (2) the introduction
of a notion of “context” that may influence the matching of tuples between producers and
consumers, and (3) the addition of, mostly complex, mechanisms for “reactive” programming,
i.e., the reaction to particular events.
The first dierence, which seems to contradict the original idea of a (global) shared memory
underlying the tuple space, is motivated by the nature of ad hoc computing, i.e., physical mobility
of nodes. Since the actions/reactions of components depend on the accessibility of nodes, yet
coupling of nodes is unwanted at the abstraction level, i.e., nodes are to remain anonymous to
each other, all three approaches foresee not only physical, but also logical mobility. Applications
are hence modeled as mobile agents roaming among nodes, exchanging data indirectly. In
Limelite [14], tuple spaces are “local” to individual agents, and the set of accessible agents
are managed through acquaintance lists, which enable mutual access to respective tuples. In
contrast, Mars (mobile agent reactive spaces [7]) and EgoSpaces [22] promote a model where
each node hosts a tuple space, and hence agents may at a given moment only interact with the
space of the host they reside upon. While Limelite provides certainly more flexibility, and can
be used to express latter variant, it does re-introduce a form of participant-awareness, whose
avoidance initially motivated the use of the tuple space as indirect communication medium.
The second dierence is clearly an enrichment with respect to the original tuple space, and
resembles the notion of locality in LPS, which makes applications aware of their environment and
context. As an example, tuple space operations in EgoSpaces include an additional parameter
representing the context (view in EgoSpaces) as in LPS.
The third distinction somewhat conveys the very nature of ad hoc applications, and the need
for reacting to events, whether they are triggered by the environment or the application. Thus,
all three approaches provide the possibility of triggering asynchronous notification of consumers
upon the occurrence of a tuple of interest. In addition, mechanisms are provided for reacting
to further events, such as the removal of tuples, or such based on contextual changes. While
Limelite and EgoSpaces provide specific primitives on tuple spaces to that end, Mars defines
reactions via meta-tuples, which are inserted into the space. However, it is not exactly clear
whether such reactions can then cross node boundaries, and if not, what is the advantage of
reifying reactions as tuples over simply providing primitives on the tuple space for expressing
the main reactions, e.g., a callback upon occurrence of a given tuple. Meta-tuples are namely
not trivial to handle, and seem somewhat artificial: for instance, the insertion of a meta-tuple
can not recursively trigger a reaction, i.e., a meta-tuple can not be referenced by a meta-tuple.
Most likely, this mechanism has been chosen as the very interface of JavaSpaces [15], which tuple
spaces in Mars subtype, do not provide any proper asynchronous consumption of tuples.
These abstractions nicely demonstrate the diculty of balancing between the desire of keep-
ing participants anonymous, and the requirement for awareness. Mobile agents act as interme-
diary between nodes, which thus remain unknown to each other, though aware of their peers
through these agents. Asynchronous consumption of tuples is in most cases strongly advo-
cated, which boils down to a publish/subscribe-like scheme. The main asset of the tuple space
paradigm, which is its possibility of synchronizing concurrent processes by having a tuple being
consumed by one out of several participants ony, seems to make little sense when consider-
ing multiple spaces which are each local to a node. A direct communication with any entity
on such a node can yield the same behavior. Mobile agents are surely interesting for many
applications, but still somewhat represent special cases. Publish/subscribe is in that sense a
more succinct, basic communication substrate, which could be easily used in combination with
a mobile agent paradigm. Furthermore, as shown by the Ubiquitous Flea Market example,
publish/subscribe-like communication can also be used as a lookup service for exchanging URLs
and hence introducing direct peer interaction.
5.2 Publish/subscribe et al.
Several authors have started from a publish/subscribe-like abstraction, e.g., [13, 25, 29]. [13]
introduces a notion location-aware subscriptions. Context-related criteria are viewed as filters,
similar to content-based ones. Publications are however not associated with proximity criteria,
and publish / subscribe is viewed as sole mechanism for peer interaction. A more thorough
comparison with [13] is not possible at this point, as no information is provided on the imple-
mentation and no programming examples are included.
[25] makes use of a mixture of topic-/content-based addressing, which is advocated as useful
and sucient per se for programming ad hoc applications, without the introduction of a notion of
context or proximity. Little information is provided on implementation issues, besides that filters
are deployed on, and applied by, both producers and consumers. Also, [25] lacks programming
The sentient objects in CORTEX [29] are mobile agents, which roam within ad hoc networks,
and communicate via a publish/subscribe scheme. [29] describes the use of publish/subscribe as
mechanism for data sharing, as well as for discovery of peers. This illustrates the benefits of such
a mechanism as basic and essential communication scheme. Sentient objects also view contextual
information as first class, just like our LPS abstraction, yet [29] lacks code samples, which
makes a side-by-side comparison of functionalities impossible. Since the CORTEX middleware
is viewed as a set of component frameworks (CFs), such as a context CF, or a publish/subscribe
CF, accessible to sentient objects, one is strongly tempted to conclude that these two things are
clearly separated. Quite interestingly, CORTEX defines a group communication CF in addition
to the publish/subscribe CF; from [29] the dierence between the two is not clear, as latter CF
seems to use multicast protocols defined in former CF.
Like LPS, the CORTEX publish/subscribe CF derives from content-based publish/subscribe.
In CORTEX, subscriptions are however expressed through a specific language called filter expres-
sion language (FEL), and involve filters on content, context, as well as on topics of events. While
topics seem somewhat superfluous, as they are subsumed by content-based publish/subscribe [6],
the use of a subscription language such as FEL oers much expressiveness. This expressiveness
however makes ecient filtering and routing of events hard [8]. In contrast, the template-based
attribute-wise matching of events in LPS oers less expressiveness, yet can be implemented
more eciently. In the same sense we have refrained from implementing a form of type-based
publish/subscribe making use of specific event types (in the programming language sense) such
as in JavaSpaces [15], as this would require a global agreement on types, which is hard to achieve
in highly dynamic ad hoc systems.
Borrow/Lend Borrow/lend (BL) [12], just like query/advertise (QA) [18], aims at enabling
exchange of objects in peer-to-peer settings. Similar to LPS, BL and QA include notions of
unpublishing, not present in common publish/subscribe engines. However, they lack a notion
of context, as they assume that any pair of peers might communicate by some means. At the
abstraction level, BL introduces a type criterion used for matching events and subscriptions,
which is again based on the assumption of global knowledge of types.
6 Concluding remarks
Few paradigms have benefited from as thorough investigation as publish / subscribe. Due
to its decoupling of participating entities, publish/subscribe has been especially advocated for
peer-to-peer or mobile ad hoc networks. In this paper, we first made an attempt of precisely
characterizing applications that are typical of ad hoc networks. We presented a paradigm for pro-
gramming such applications, called location-based publish/subscribe, as well as an J2ME-based
implementation of it. LPS leverages on the blend of topic- & content-based publish/subscribe,
by generalizing the notion of topic to a that of a context expressing a proximity criteria. We
also illustrated LPS on two typical mobile ad hoc applications, and compared it to related
work, pointing out that although a more basic building block, LPS removes much burden from
the application developer. Regarding ongoing work, we are currently investigating a decentral-
ized implementation of LPS, as well as a more flexible way than mere templates to perform
content-based selection of events.
[1] J2ME building blocks for mobile devices (white paper). Sun Microsystems, 2000.
[2] MIDP APIs for wireless applications (white paper). Sun Microsystems, 2001.
[3] Pirates! Using the Physical World as a Game Board, 2001.
[4] 3G wireless standards for cellular mobile services. Siemens AG, 2002.
[5] AirPort Extreme, Technology Overview. Apple Computer, April 2004.
[6] M. Aguilera, R. Strom, D. Sturman, M. Astley, and T. Chandra. Matching Events in a Content-
Based Subscription System. In Proceedings of the 18th ACM Symposium on Principles of Distributed
Computing (PODC 1999), pages 53–62, Nov. 1999.
[7] G. Cabri, L. Leonardi, and F. Zambonelli. MARS: A Programmable Coordination Architecture for
Mobile Agents. IEEE Internet Computing, 4(4):26–35, 2000.
[8] A. Carzaniga, D. Rosenblum, and A. Wolf. Achieving Scalability and Expressiveness in an Internet-
Scale Event Notification Service. In Proceedings of the 19th ACM Symposium on Principles of
Distributed Computing (PODC 2000), pages 219–227, July 2000.
[9] R. Chandra, V. Ramasubramanian, and K. Birman. Anonymous Gossip: Improving Multicast
Reliability in Mobile Ad-hoc Networks. pages 275–283, Apr. 2001.
[10] T. Daniel. Making wireless roaming fun. Wired News Online, April 2004.
[11] T. Estier and P. Rupp. A model for a better understanding of the digital distribution of music in
a peer-to-peer environment. In Proceedings of the 36th Hawaii International Conference on System
Sciences, January 2003.
[12] P. Eugster and S. Baehni. Abstracting Remote Object Interaction in a Peer-to-Peer Environment.
In 2002 Joint ACM Java Grande - ISCOPE Conference, pages 46–55, Nov. 2002.
[13] L. Fiege, F. C. Grtner, O. Kasten, and A. Zeidler. Supporting Mobility in Content-Based Pub-
lish/Subscribe Middleware. In 4th ACM/IFIP/USENIX International Middleware Conference (Mid-
dleware 2003), pages 103–122, June 2003.
[14] C. Fok, G.-C. Roman, and G. G. Hackmann. A Lightweight Coordination Middleware for Mo-
bile Computing. In Proceedings of the 6th International Conference on Coordination Models and
Languages (Coordination 2004), pages 135–151, Feb. 2004.
[15] E. Freeman, S. Hupfer, and K. Arnold. JavaSpaces Principles, Patterns, and Practice. Addison-
Wesley, June 1999.
[16] B. Garbinato and P. Rupp. From ad hoc networks to ad hoc applications. In Proceedings of the 7th
International Conference on Telecommunications, pages 145–149, Zagreb (Croatia), June 2003.
[17] D. Gelernter. Generative Communication in Linda. ACM Trans. Prog. Lang. Syst., 7(1):80–112,
Jan. 1985.
[18] D. Heimbigner. Adapting Publish/Subscribe Middleware to achieve Gnutella-like Functionality. In
SAC ’01: Proceedings of the 2001 ACM symposium on Applied computing, pages 176–181, Mar.
[19] Java 2 Platform, Micro Edition (J2ME). Sun Microsystems.
[20] J. P. Hubaux, T. Gross, J. Y. L. Boudec, and M. Vetterli. Towards self-organized mobile ad hoc
networks: the Terminodes project. IEEE Communications Magazine, 31(1):118–124, 2001.
[21] JSR-179 Expert Group. Location API for Java 2 Micro Edition, Version 1.0, September 2003.
[22] C. Julien and G.-C. Roman. Egocentric Context-aware Programming in Ad Hoc Mobile Envi-
ronments. In Proceedings of the 10th International Symposium on the Foundations of Software
Engineering (FSE-10), pages 21–30, Nov. 2002.
[23] J. Kardash. Bluetooth architecture overview. Intel Technology Journal, 2000.
[24] J. Luo, P. Eugster, and J.-P. Hubaux. Probabilistic Reliable Multicast in Ad Hoc Networks. Elsevier
Ad Hoc Networks, 2(4):369–386, 2004.
[25] R. Meier and V. Cahill. Steam: Event-based middleware for wireless ad hoc network. In Proceedings
of the 22nd International Conference on Distributed Computing Systems (ICDCS ’02) Workshops,
pages 639–644, July 2002.
[26] R. Morris, J. Jannotti, F. Kaashoek, J. Li, and D. De Couto. CarNet: A scalable ad hoc wireless
network system. IEEE Communications Magazine, 31(1):118–124, September 2000.
[27] A. L. Murphy, G.-C. Roman, and G. Varghese. An exercise in formal reasoning about mobile
communications. In I. C. Society, editor, Proceedings of the Ninth International Workshop on
Software Specification and Design, pages 25–33, Ise-Shima (Japan), 1998. IEEE Computer Socitey
Technical Council on Software Engineering.
[28] C. Perkins and E. Royer. Ad-Hoc On Demand Distance Vector Routing. In Proceedings of the 2nd
IEEE Workshop on Mobile Computing Systems and Applications, pages 90–100, February 1999.
[29] C. Sorensen, M. Wu, T. Sivaharan, G. Blair, P. Okanda, and A. F. and. Duran-Limon. A Context-
aware Middleware for Applications in Mobile Ad Hoc Environments. In Proceedings of the 2nd
Workshop on Middleware for Pervasive and Ad-hoc Computing, pages 107–110, 2004.
[30] Y. Vogiazou and B. Raijmakers. Urban space as a large-scale group playground. In Ubicom 2004
Workshop ”UbiComp in the Urban Frontier”, 2004.
[31] Y. Vogiazou, B. Raijmakers, B. Clayton, M. Eisenstadt, E. Geelhoed, J. Linney, K. Quick, J. Reid,
and P. Scott. ”you got tagged!”: The city as a playground. In Second International Conference on
Appliance Design 2AD, HP labs, Bristol, UK, 2004.
... According to the authors, the flexibility of the system and its efficiency in a dynamic scenario is otherwise severely limited. In the following, we discuss how location-based filtering can be enabled i) by extending existing attribute-or content-based publish/subscribe systems as proposed in [13,30,43,51,78,202], and ii) by introducing new subscription models for context-based filters [6,11,20,41,80,108,200]. Fiege et al. discuss the consequences of logical mobility for the content-based publish/subscribe system Rebeca in [43,202]. ...
... To deal with frequent location updates, dedicated subscription models and the corresponding filter schemes have been proposed in the literature [6,11,20,41,80,108,200]. In all these approaches, location-based filtering is a key primitive of the filter Dedicated location-based filtering scheme, resulting in increased efficiency and expressiveness in dynamic scenarios. ...
... An intuitive representation of location-based subscriptions is proposed by Brimicombe et al. in [11] with Space-Time Envelopes (STEs). STEs describe a circular area around a client's current location, as also proposed in [41]. However, an STE is further extended with a conical shape in the direction of the client's movement. ...
Internet traffic caused by mobile devices will exceed the traffic originating from PCs by the year 2020, according to Cisco. With a projected 61-fold increase, location-based applications and augmented reality applications exhibit the fastest growth in the mobile sector. The success of interactive augmented reality games such as Google’s Ingress or Pokémon Go is the latest indicator for the increasing popularity of location-based mobile social applications. However, the direct interaction among users and the inherent locality of this interaction in such applications pose considerable challenges to a communication system. Efficient brokering of content based on the physical location of mobile clients is further complicated by application-specific attraction points and the resulting heterogeneities and dynamics of client mobility. The publish/subscribe paradigm is well suited to model this interest-based communication pattern between users. Distinct mechanisms for both location-based filtering and locality-aware dissemination of events have been proposed for numerous application domains. However, their combined utilization and their adaptation to user mobility, network heterogeneity, and dynamic workload characteristics of mobile social applications remains an open research challenge. In this thesis, we design and implement transitions between distinct mechanisms for location-based filtering and locality-aware dissemination of events as our first contribution to address this challenge. We develop a methodology for the encapsulation of mechanisms and the execution of transitions within our publish/subscribe framework Bypass.KOM. Consequently, we apply our methodology to location-based filter schemes and dissemination mechanisms for locality-aware publish/subscribe, integrating state of the art mechanisms into Bypass.KOM. We propose distinct execution strategies for transitions, focusing on the seamless operation of the publish/subscribe system during execution by means of state transfer between mechanisms. By deriving common abstractions for transition-enabled mechanisms and the coordinated execution of transitions, we generalize our methodology as part of the Simonstrator.KOM platform. These abstractions for the design and evaluation of transition-enabled communication systems constitute our second contribution. This includes mobility and workload models for location-based mobile social applications. Based on a prototype of Bypass.KOM, we conduct an extensive evaluation of our contributions using the Simonstrator.KOM platform. We show that our state transfer mechanism and the proposed abstractions for transition-enabled mechanisms lead to a seamless execution of transitions. Additionally, we demonstrate the combined utilization of location-based filtering and locality-aware event dissemination as coexisting transition-enabled mechanisms. Overall, we show that our contributions allow the publish/subscribe system to adapt to application-specific mobility and workload characteristics by executing the respective mechanism transitions.
... Hereafter, we provide a literature review of location-based publish/subscribe abstractions aimed at context-aware applications. Eugster et al. (2005) introduced the concept of Location-based Publish/Subscribe Service (LPSS) that allows mobile ad hoc applications to transparently and anonymously communicate with each other using a subscription and a publication, based on their location. With LPSS, publications as well as subscriptions are distributed and bound to a geographical range around the publisher and the subscriber respectively. ...
... These ranges define the publication space and the subscription space. Publications are persistent, i.e. the published event is distributed to all interested subscribers located or entering the publication space before the event is unpublished (Eugster et al., 2005). A persistent publication is unpublished by its producer or by the service once its determined period known as Time-To-Live (TTL) is elapsed. ...
... Another Context-Aware Publish/Subscribe scheme (CAPS) is proposed in (Cugola et al., 2009;Cugola and Migliavacca, 2008). In CAPS context is not encoded into the event, but treated separately as a first class object very much like in LPSS (Eugster et al., 2005). The implementation of CAPS proposes three message routing techniques, publisher forwarding, subscriber forwarding and context-forwarding. ...
... A match occurs between a given publication and a given subscription if both a content criterion and a context criterion are met simultaneously. The content criterion expresses a semantic relationship between the publication and the subscription, as captured by traditional publish-subscribe systems such as the Java Messaging Service API. 2 The context criterion then expresses some proximity condition between the publication space and subscription space, hence the term location-based or sometimes locationaware publish-subscribe [6], [16]. ...
... To our knowledge, despite the fact that some studies [2], [3], [6], [11] approach location-based publish and subscribe from a distributed-system perspective, none of them focus on horizontal scalability. Interestingly, by addressing scalability in a vertical manner, a huge body of literature recently focused on improving the computation of spatial matches on a single node. ...
... RELATED WORK Several approaches have been proposed to extend the Publish/Subscribe paradigm. For instance, in [10], [11], [12], [13], [14], [15] the authors propose approaches to accommodate location awareness for better service delivery. In [16] the authors propose MQTT-G, an extension of the MQTT protocol to include geo-location data. ...
Conference Paper
Full-text available
Location-aware applications are becoming popular nowadays because of the increasing adoption of edge and fog computing. This poses novel difficulties to the conventional applications that utilize the Message Queuing Telemetry Transport (MQTT) as their prevalent communication channel. Also, developers are obliged to figure out the code at whatever point they need to build up MQTT-based location-aware applications. This can causes various issues, for example, protocol standard infringement or problems in data acquisition. This paper proposes a novel extension of the recently released MQTT5 protocol that will permit message delivery by not only respecting the topics of interest but also in addition to geo-referenced information provided by both publishers and subscribers.
... RELATED WORK Several approaches have been proposed to extend the Publish/Subscribe paradigm. For instance, in [10], [11], [12], [13], [14], [15] the authors propose approaches to accommodate location awareness for better service delivery. In [16] the authors propose MQTT-G, an extension of the MQTT protocol to include geo-location data. ...
Full-text available
Location-aware applications are becoming popular nowadays because of the increasing adoption of edge and fog computing. This poses novel difficulties to the conventional applications that utilize the Message Queuing Telemetry Transport (MQTT) as their prevalent communication channel. Also, developers are obliged to figure out the code at whatever point they need to build up MQTT-based location-aware applications. This can causes various issues, for example, protocol standard infringement or problems in data acquisition. This paper proposes a novel extension of the recently released MQTT5 protocol that will permit message delivery by not only respecting the topics of interest but also in addition to geo-referenced information provided by both publishers and subscribers.
... Location-based publish/subscribe (LPS) allows for communication depending on the location [25]. In LPS, the message delivery to subscriber undergoes three conditions. ...
Full-text available
Sharing information would not only raise awareness and increase knowledge, but could also save lives. Occasionally, governments need to provide critical information to citizens accurately and in a timely manner. There are different information dissemination channels such as: Television, Radio, SMS and Social Media. However, these channels have several limitations. A dissemination approach is needed that intelligently target specific citizens with critical information that concern them from trusted sources on time. In this research, we propose a dissemination model that addresses these issues and utilizes the needed features. Comparing several dissemination architectures, the proposed model is an enhanced architecture designed based on publish/subscribe. The study proposed a novel idea of information dissemination by integrating many trusted sources in a unified source that can be accessed by the stakeholders at any time. The study would be a building block for an official information dissemination system in Saudi Arabia.
A mobile phones provides portability and personalized computing with ubiquitous connectivity. This combination makes them an ideal choice to use for various applications of personal use. The portability of mobile devices is the most important and useful feature of mobile devices. However, portability is achieved at the high cost of limited power and computation ability of the mobile device. Cloud computing fulfills the need of providing more computation power to complete the tasks that cannot be done on a mobile platform. The cloud provides an always available platform and do not have typical limitations, e.g. limited battery and computation power, of mobile platforms. Therefore combining cloud computing with mobile provides us best of both worlds i.e. we have a computing platform available for us all the time which we move, and yet we can access services and perform tasks that require high-power computation.
In our analysis of related work, we identified a gap in the combined utilization of mechanisms for location-based filtering and locality-aware dissemination of events. As discussed in Chap. 3, applying these mechanisms to the dynamic scenario of location-based mobile social applications is further hindered by their limited adaptability. We designed BYPASS.KOM [19] as a framework to study the potential of mechanism transitions for location-based filtering and locality-aware event brokering. BYPASS.KOM enables us to include a wide range of existing mechanisms identified in our literature survey when studying the impact of transitions. At the same time, it allows us to combine mechanisms that alter the structure of the publish/subscribe system with mechanisms that alter the content of publications and subscriptions. Enabling this combined utilization of mechanisms is essential to address both, location-based filtering and locality-aware event dissemination.
In this chapter, we discuss the state of the art in adaptive event brokering for location-based mobile social applications. We discuss how existing mechanisms and systems address three distinct questions resulting from the scenario of mobile social applications.
Full-text available
When striving for reliability, multicast protocols are most commonly designed as deterministic solutions. Such an approach seems to make the reasoning about reliability guarantees (traditionally, binary, “all-or-nothing”-like) in the face of packet losses and/or node crashes. It is however precisely this determinism that tends to become a limiting factor when aiming at both reliability and scalability, particularly in highly dynamic networks, e.g., ad hoc networks. Gossip-based multicast protocols appear to be a viable path towards providing multicast reliability guarantees. Such protocols embrace the non-deterministic nature of ad hoc networks, providing analytically predictable probabilistic reliability guarantees at a reasonable overhead.This paper presents the Route Driven Gossip (RDG) protocol, a gossip-based multicast protocol designed precisely to meet a more practical specification of probabilistic reliability in ad hoc networks. Our RDG protocol can be deployed on any basic on-demand routing protocol, achieving a high level of reliability without relying on any inherent multicast primitive. We illustrate our RDG protocol by layering it on top of the “bare” Dynamic Source Routing protocol, and convey our claims of reliability and scalability through both analysis and simulation.
Conference Paper
Full-text available
Some of the most dynamic systems being built today consist of physically mobile hosts and logically mobile agents. Such systems exhibit frequent configuration changes and a great deal of resource variability. Applications executing under these circumstances need to react continuously and rapidly to changes in operating conditions and must adapt their behavior accordingly. The development of such applications demands a reexamination of the notion of context and the mechanisms used to manage the application's response to contextual changes. This paper introduces EgoSpaces, a coordination model and middleware for ad hoc mobile environments. EgoSpaces focuses on the needs of application development in ad hoc environments by proposing an agent-centered notion of context, called a view, whose scope extends beyond the local host to data and resources associated with hosts and agents within a subnet surrounding the agent of interest. An agent may operate over multiple views whose definitions may change over time. An agent uses declarative specifications to constrain the contents of each view by employing a rich set of constraints that take into consideration properties of the individual data items, the agents that own them, the hosts on which the agents reside, and the physical and logical topology of the ad hoc network. This paper formalizes the concept of view, explores the notion of programming against views, discusses possible implementation strategies for transparent context maintenance, and describes our current prototype of the system. We include examples to illustrate the expressive power of the view abstraction and to relate it to other research on coordination models and middleware.
Conference Paper
Full-text available
Novel ubiquitous computing applications such as intelligent vehicles, smart buildings, and traffic management require special properties that traditional computing applications do not support, such as context-awareness, massive decentralisation, autonomous behaviour, adaptivity, proactivity, and innate collaboration. This paper presents a new computational model and middleware that reflect support for the required the properties. The sentient object model is proposed by the CORTEX1 project to support the construction of ubiquitous applications. A flexible, run-time reconfigurable component-based middleware has been built to provide run-time support to engineer the sentient object programming paradigm. An application infrastructure using sentient objects to enable cooperation between autonomous and proactive vehicles has been implemented to demonstrate the appropriateness of the computational model and the validity of the middleware for pervasive mobile ad hoc computing.
In this paper, I describe CitiTag, a research project aiming to explore the potential of spontaneous social behaviour and playful group interaction in public spaces through the use of mobile technologies. I discuss briefly the idea and motivating themes, the design of CitiTag, a wireless location based multiplayer game and findings from two user studies.
Conference Paper
Leveraged by the success of applications aiming at the ``free'' sharing of data in the Internet, the paradigm of peer-to-peer (P2P) computing has been devoted substantial consideration recently. This paper presents an abstraction for remote object interaction in a P2P environment, called borrow/lend (BL). We present the principles underlying our BL abstraction, and its implementation in Java. We contrast our abstraction with established abstractions for distributed programming such as the remote method invocation or the tuple space, illustrating how the BL abstraction, obviously influenced by such predating abstractions, unifies flavors of these, but also how it captures the constraints specific to P2P environments.