Content uploaded by Barun Saha
Author content
All content in this area was uploaded by Barun Saha on Sep 20, 2018
Content may be subject to copyright.
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
1
Evaluation of Opportunistic Service Provisioning
with Ordered Chaining
Barun Kumar Saha and Sudip Misra, Senior Member, IEEE
Abstract—Opportunistic Mobile Networks (OMNs) enable communication among the otherwise disconnected devices via intermittent
contacts. Based on this premise, the paradigms of Opportunistic Computing (OC) and Opportunistic Service Provisioning (OSP) were
proposed, where a user can request remotely available hardware and software services from the relevant nodes that are not in direct
contact with the user’s device. In this work, we consider the problem of OSP together with ordered chaining. Chaining (or composition)
refers to the scenario where two or more services must be availed by a given data object one after the another, for example, translating
a text file and converting it to another format. Such a chaining is termed as ordered when the required services must be availed in a
specific sequence. We discuss four schemes for achieving OSP with ordered chaining. One of the proposed schemes unicasts the
OSP request messages, while another one adapts a popular unicasting algorithm for OMNs. The third scheme is based on flooding,
whereas in the final one, nodes replicate requests only to those who provide the concerned services. The results of performance
evaluation using real-life traces and synthetic mobility models show that up to about 99% of the service requests can be satisfied. The
results also indicate that unicasting is rather unsuitable to achieve OSP.
Index Terms—Opportunistic Service Provisioning, Opportunistic Mobile Networks, Opportunistic Computing, service chaining,
ordered chaining
F
1 INTRODUCTION
Mobile devices in OMNs [1], [2], [3] have intermittent
connectivity among themselves, and, unlike the traditional
networks, for example, the TCP/IP-based Internet, typically
lack in end-to-end communication paths. Communication
opportunities (also known as “contacts”) among the other-
wise disconnected devices arise when they come within the
transmission ranges of one another. Although such charac-
teristics make OMNs suitable for use in diverse scenarios,
such as the aftermath of a disaster and relaxing load on
network infrastructure in urban areas, they also make even
the basic form of communication in OMNs, for example,
unicasting, a non-trivial task. To cope with such difficulties,
messages are usually replicated to multiple devices with the
hope that at least a single such copy of the message would
reach the concerned destination. Consequently, it becomes
far more challenging to accomplish advanced services, for
example, content dissemination and processing.
OMNs have evolved from a mere communication
paradigm into the more generalized domains of OC and
OSP [4], [5], [6], [7]. OC and OSP are envisaged as a layer
above the OMN, which enables users to opportunistically
avail resources present in other disconnected devices (for
example, smartphones) as well as the environment (for
example, sensors). Given that heterogeneous hardware and
software resources are available, the primary objectives of
OC include opportunistic delegation of computations, com-
position of two or more functionalities, and returning back
the result to the originating node. In the similar spirit, OSP
considers everything as a service, and deals with combina-
•B. K. Saha and S. Misra are with the Department of Computer Science
and Engineering, Indian Institute of Technology Kharagpur, India.
E-mail: {barun.kumar.saha, smisra}@sit.iitkgp.ernet.in.
tion of services as well as delegation of such requests.
Figure 1 presents a high-level overview of OSP with a
typical example. A user has an XML file, but wishes to
consume the content in a different format. In particular, the
user wishes to extract the text from the XML file sans the
tags, translate the text into a different language, and finally,
convert that into a PDF file. The user has no software avail-
able in his/her device that can perform the aforementioned
sequence of job. Moreover, the mobile device lacks in Inter-
net connectivity and therefore, the tasks cannot be offloaded
to the cloud [8], [9]. However, the other mobile devices
in the OMN provide one or more of these functionalities.
The goal of OSP is to opportunistically determine a feasible
temporal path for task processing so that the requesting user
receives the original content back in the desired format.
This task is fundamentally challenging, because it is not
known a priori when a given pair of devices providing
certain set of services would come in contact. Consequently,
available contact opportunities between any two mobile
devices should be fully utilized. We shall describe the other
terminologies from Figure 1 in the remainder of this paper.
In this work, we consider the problem of OSP in the
context of OMNs. In particular, we explore the aspect of
service composition or chaining, where two or more ser-
vices/functionality must be applied sequentially upon a
given data object. Such a chaining may be ordered, where the
services must be processed in the exact order specified, or
unordered, where the specified services can be availed in any
arbitrary sequence. Our objective herein is to explore how
service requests can be disseminated efficiently in order to
achieve OSP with ordered chaining in practice. To this end,
we leverage technical know-how from unicast communica-
tions in OMNs. Our target is to quantify the performance of
OSP under different approaches, and interpret their usabil-
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
2
Fig. 1: Illustration of OSP, where disconnected mobile de-
vices can avail heterogeneous software/hardware services
provided by other devices.
ity. Moreover, we aim to examine whether or not traditional
unicasting is a suitable mechanism to achieve OSP.
The specific contributions of this work are as follows.
•Proposing four schemes to achieve OSP with ordered
chaining in an OMN formed by mobile devices and
lacking in network infrastructure.
•Evaluating the performance of OSP using real-life
connection traces and synthetic mobility models.
•Experimentally demonstrating that traditional uni-
casting, in general, is ineffective in achieving OSP.
The remainder of this work is organized as follows.
Section 2 surveys the contemporary literature. Section 3
presents the system model and the assumptions made in
this work. Subsequently, it explains the aspects of OSP and
service chaining together with examples. Section 4 presents
four schemes to serve requests for OSP with ordered chains.
The Section also discusses different types of messages used
in the process together with the corresponding message
formats. In Section 5, we discuss the simulation setup and
performance evaluation metrics. The experimental results
are discussed in Section 6. Finally, Section 7 concludes this
work.
2 RE LATED WORK
The interest on content-centric networking has vastly grown
in the recent years. Saha and Misra [10] proposed a scheme
for content searching in OMNs based on the Named Data
Networking (NDN) [11] approach. In particular, users send
out interest messages to request contents. Such messages are
replicated in the network until they reach a node containing
the corresponding content, which then responds back with
a data message. However, [10] deals only with unicasting
a single data object of interest to the concerned requesting
node. Elgazzar et al. [12] presented an architecture for user-
centric data and services sharing together with privacy
preservation. Such “personal services” are usually offered
to others who are in the contact list of a user.
Service provisioning has been considered in the context
of different types of networks, for example, NDN, mobile
ad hoc networks (MANETs) [13], [14], sensor networks [8],
[15], [16], cloud computing [17], [18], [19], industrial Internet
of Things, [20], mobile edge computing [21], and so on.
Tschudin and Sifalakis [22] discussed the applications of
Named Function Networking [23] (NFN)1for media deliv-
ery, where both content items and functions to be applied
upon them are identified by names.
Shah et al. [16] addressed the problem of fault-tolerant
composition of services having geospatial relevance in the
context of Wireless Sensor Networks (WSNs). In particu-
lar, the authors proposed cost- and gain-based models to
configure the services in the devices. Recently, the concept
of traditional WSNs has been extended into sensor clouds.
In this context, Chatterjee et al. [8] addressed the problem
of providing sensors as a service and their corresponding
pricing models.
Groba and Clarke [24] addressed the issue of service
composition in MANETs. In contrast to the traditional
service provisioning, where a request is bound to all the
required providers before execution commences, Groba and
Clarke [24] proposed to execute individual services as soon
as they are bound, which is referred to as opportunistic
or partial service composition. Although such innovation is
noble in the context of mobile ad hoc networks, late binding
is the norm in OMNs. Astail and Saab [13], on the other
hand, proposed caching of service responses in order to
mitigate the effects of communication disruption arising due
to mobility. It may be noted that disruptions in connectivity
in OMNs is usually the norm. Moreover, in the problem
addressed in this work, same services can be requested for
different input files. Consequently, caching such responses
is less likely to be helpful.
Guerrero-Contreras [25] noted that local mobile clouds
are useful in the absence of direct Internet connection, and
investigated the variation in service availability in the con-
text of MANETs. The authors proposed a service replication
scheme that is suitable for small to medium size networks.
The work presented in [25], however, is different from the
problem that we address. First, our target networks are
OMNs – and not MANETs – that can span over very large
terrains and form a large-scale network. Second, we are
not interested how services are managed at nodes. Rather,
we assume that the services are randomly distributed with
some probability. Given such a context, our object is to
efficiently route a service request. Moreover, unlike [25], we
explicitly consider chaining of services, where multiple sub-
requests must be satisfied in a specific order to satisfy a
given request. In particular, we study and evaluate the fea-
sibility of chaining multiple services in largely disconnected
networks such as, OMNs. The highly dynamic nature of
OMNs make this a challenging task.
Deng et al. [26] considered the case of service provision-
ing in a community of mobile nodes. The authors proposed
a modified version of the random waypoint (RWP) mobility
model this purpose, which, however, does not appropriately
reflect human mobility in real-life. Moreover, by geograph-
ically constraining service compositions to certain regions,
one may not be able to leverage potential services that are
offered elsewhere in the network.
Passarella et al. [5] analyzed the performance of OSP.
In their model, a service-seeking node sends requests to an
1. NFN extends NDN by combing data and functionalities together.
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
3
TABLE 1: Notations Summary.
Notation Description
NSet of nodes in the OMN
SiSet of services offered by node i
SSet of all services available in the OMN
RiSet of services requested by node i
hDiService directory
⊕Service composition
kDegree of chaining
pij Delivery predictability of node ifor node j
qi(s)Service predictability
Bi(s)Set of best providers for service s
optimal number of nodes. Once a task has been uploaded
to a service provider node, the provider performs the com-
putation and stores the result, which is delivered back to
the corresponding seeker node at their next contact. Thus,
if a seeker uploads a task request to say, n, nodes, it can
download the results from any of those nnodes. Replication
of requests may stop before reaching the optimal number if
the results of the task are already obtained.
Unlike [5], where a single service was considered, Sadiq
et al. [7] considered the aspects of selection and composition
of multiple services. In particular, in [7], the nodes maintain
a service graph indicating the services provided by them.
When two nodes come in contact, they aggregate their ser-
vice graphs to discover new service paths. The edge weight
of such a graph takes into account the temporal distance
between the pair of nodes as well the load at a given node.
Based on these information, the system determines what
service to request next and from which node.
The present work differs from the contemporary liter-
ature in multiple aspects. First, while the focus of [7] was
more on service discovery and composition, we consider
the scenario where the nodes in OMNs are already aware
of the services that they require. Consequently, we focus on
how such service requests can be efficiently transmitted to
the provider nodes. In other words, in contrast to [7], which
largely decouples service selection from routing, we investi-
gate aspects related to the routing of service messages. The
contemporary literature, in general, does not shed light on
whether or not traditional unicasting is a suitable choice
for achieving OSP. In this work, we, however, show that
it is rather not a desirable choice. Finally, in contrast to
NFN [27], we consider the scenario where data objects that
should avail one or more services are actually provided by
the requesting node.
3 OPPORTUNISTIC SERVICE PROVISIONING
This Section presents the system model, assumptions, differ-
ences between OSP and unicasting, and different aspects of
OSP and service chaining. Table 1 summarizes the notations
used in this work.
3.1 System Model and Assumptions
The OMN consists of a set of nodes (mobile devices) repre-
sented by N={1,2,...,|N|}, where each node is assumed
to have a unique identifier. Let Sibe the set of services
provided by any node i∈N. It may be noted that Sican
possibly be empty. Then, the set of all services offered by
the nodes in the OMN is given by S=∪i∈NSi. Any node
in the OMN requests for one or more services from the
network by creating a service request message (SRM). Let
Ri∈Sbe the set of services requested by node i;Ri6=∅.
When the last requested service as mentioned in an SRM
is served by a node, it creates a unicast message with the
requesting node as its intended destination. The details of
routing these request and response messages are discussed
in the remainder of this work.
Let hDSibe the service directory consisting of the lookup
function DSsuch that, DS(s)⊆N,∀s∈S. In other words,
given a service s,DStells the list of its providers.
In this work, we assume that:
•The sets Si– and consequently, S– do not alter with
time. In other words, there is no addition or removal
of any service.
•Each service in the set Scan be uniquely identified
by their name or other relevant attribute.
•Each node has complete knowledge of the service di-
rectory, i.e., node-to-service mapping and vice versa2.
•The nodes in the OMN are trusted and well behaved.
Additionally, we assume the availability of reliable com-
munication. In particular, two nodes can exchange messages
without any error as long as they are within one another’s
transmission ranges; message exchange fails when they
go out of range. Moreover, since OMNs, in general, have
sparse node density, certain link layer aspects, for example,
interference, are ignored. The core goal is to investigate how
available pairwise contact opportunities (which are rare) can
be efficiently leveraged to relay messages.
3.2 How OSP is Different from Unicasting?
The goal in OSP is to let the nodes in an OMN avail a set
of one or more services provided by the mobile devices
of the other users. Such service requests are disseminated
and processed opportunistically depending upon the con-
tact among the nodes. For example, a user may wish to
apply certain filters on one or more images that he/she has.
However, with no appropriate software being available, the
user may decide to avail the corresponding service from the
other relevant users in the OMN. At this point, the service
requesting process may apparently seem trivial – send the
image to a user that provides the required service, let the
latter’s device process it, and return back the image to its
origin. However, in practice, it is not that straightforward.
First, although the list of potential providers of a given
service may be known, it is not known who among them
is/are the “best” providers. For example, if we assume that
the quality of a particular service provided all the nodes are
equivalent, then “best” would translate to minimum latency
in receiving back the service response. In the absence of any
such information, determining the destination of a unicast
message becomes difficult.
2. This is not a hard assumption. In particular, the nodes can maintain
a local list of services available, and synchronize the lists as they
come in contact with others. When done over a period of time, the
locally maintained lists would gradually converge to the global service
directory. We, however, do not consider this aspect further in the
remainder of this work.
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
4
Second, the unicast-based approach still might be suit-
able when a single service is requested. However, in prac-
tice, one may request multiple services for a given object – a
phenomena that we refer to as chaining (or composition [7]).
Continuing with the above example, the user may request
that after the desired filters are applied upon the image, it
should be exported as a PDF file. The user whose device
processed the image, may not have such a conversion tool
available. Consequently, the half-processed service request
must be sent again to another user whose device provides
the file conversion utility. Such repeated back and forth
movement between a requesting node and service provider
would introduce considerable latency. Nevertheless, we
consider a unicast-based scheme in the following Section
for the sake of completeness.
3.3 Chaining of Services
As noted earlier, the focus of this work is upon chaining of
services in the context of OSP. In particular, chaining refers
to the scenario, where a given object needs to be subjected
to a series of services one after another. One such example
was provided in Section 3.2, where an image must be edited
and then converted. Here, let us revisit the example from
Figure 1 in further detail.
To briefly recollect, a user has an XML file; he/she wants
to extracts the text from the file, translate them into a differ-
ent language, and get the resulting translated text as a PDF
file. Let us assume that no software capable of achieving
these tasks is available with the user or any other mobile
device in the OMN. However, suppose that three distinct
services exist and are provided by the devices, where each of
the concerned tasks (extract text, translate text, and convert
file) can be processed separately. Let us call these services as
s1,s2, and s3, respectively.
Let fbe the input file here. In general, frepresents an
object upon which a given service would be applied. With
respect to Figure 1, frepresents the XML file. Let us now
apply the service s1to fso that we get an output object o1
(file containing only text with no XML tags):
o1=s1(f).(1)
Next, we apply the service s2upon o1to get the second
intermediate output o2(file containing translated text):
o2=s2(o1).(2)
Finally, let us apply s3upon o2to get o3(PDF file):
o3=s3(o2).(3)
Note that the operations shown in (1)–(3) are performed
at two different nodes. However, from the network point of
view, we can combine (1)–(3) into a single equation:
o3=s3(s2(s1(f))) = (s3⊕s2⊕s1)(f).(4)
The ⊕operator in (4) is used to denote the service com-
position or chaining operation – given an input object, one
or more services can be applied repeatedly in sequence so
that the output of the first operation becomes the input for
the second operation, and so on. Moreover, we say that the
operation in (4) has a chaining degree (also referred to as the
“composition length” in [7]) of two. In general, if k≥1
services are composed together, the process is said to have a
chaining degree of k. In particular, the service chain shown
in Figure 1 has a degree k= 3.
An interesting question arises here – are si⊕sjand
sj⊕siequivalent? The answer depends upon what specific
services siand sjdenote. Certain services must be availed in
a particular order or sequence. For example, in the example
presented in Section 3.2, the image filters must be applied
before it is exported as a PDF file. Reversing the sequence
of services in this case would not produce the same end
result. We refer to such a set of service requests, where their
relative sequence is important, as an ordered chain of services.
In particular, in an ordered chain, we have si⊕sj6≡ sj⊕si,
i.e., the services are not commutative.
On the other hand, there are services available whose
relative ordering does not matter. For example, the order
of the services s2and s3described earlier can perhaps
be interchanged depending upon the underlying software.
We refer to such a set of services as an unordered chain.
It may be noted that if we consider a chain of degree k,
then k!different orderings are possible. If we consider one
particular ordering out of the k!different ones, then the
problem of unordered chaining translates to that of ordered
chaining. Consequently, we do not address the issue of
unordered chaining of services in the remainder of this
work. However, we note that the two problems need not
necessarily be equivalent, and it might be possible to design
a better algorithm rather than merely treating an unordered
chain as an ordered one.
4 SERVING ORDERED CHAINS
In this Section, we look at different schemes for achieving
OSP with ordered chaining. We also discuss the types of
messages and their format that help in OSP.
4.1 Message Format
When a node wishes to avail a set of services, it creates an
SRM. The structure of an SRM is slightly different from a
unicast message. First, an SRM has no destination address.
This is because, rather than a pre-defined and particular des-
tination, the message has to be sent to a node that provides
earliest communication opportunity (direct or transitive) for
availing the desired service(s).
Second, the required services are listed within the mes-
sage in the specific order that they should be processed.
Considering the text translation example once again, when
the user creates the SRM, its SERVICES field would list the
values hs1;s2;s3i. Since s1is listed before s2, the former
service must be availed before the latter. Let us consider that
a node say, x, has processed the request for s1. Subsequently,
it removes s1from the requested services list, and updates
the SERVICES field to hs2;s3i.
Third, an SRM also has a PAYLOAD field, which contains
the original file upon which all services are to be applied.
Unlike the payload field in traditional communication, for
example, unicasting, multicasting, and content sharing, the
PAYLOAD here is repeatedly updated. Continuing with the
example from the previous paragraph, to process the service
request s1, node xmakes a local copy of the payload
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
5
from the SRM, performs the requested operation, and then
updates the content of the PAYLOAD field with the locally
processed copy. Consequently, when xreplicates the SRM
to any other node, the latter nodes can directly serve the
request for s2without any further pre-processing.
When the last requested service in the sequence has been
served by a node, the SERVICES field in the SRM becomes
empty. At this point, the concerned node creates a response
message, which is sent to the requesting node via traditional
unicasting. The payload of the response message contains
the intended outcome of the composition of the requested
services. The concerned SRM is dropped by the final service
providing node.
4.2 Achieving OSP with Ordered Chaining
In the remainder of this Section, we look at a few OSP
schemes. These are based on some of the well known
approaches used for unicasting in OMNs.
4.2.1 Flooding-based Request (FBR)
In the flooding scheme [28], a message is replicated to all
possible nodes in the OMN until it reaches its intended des-
tination. We borrow the similar concept in FBR. In particular,
an SRM is replicated by the requesting node to all the other
nodes that come in contact with it. Those nodes, in turn,
further replicate the SRM to the others. During this repli-
cation process, one or more nodes satisfy the first service
request so that when that SRM is subsequently replicated,
the latter nodes need only to satisfy the remaining requests.
Consequently, the chances of having all the service requests
processed increases. As mentioned earlier, when a node
serves the final request, it creates a response message, and
unicasts it back to the requesting node.
4.2.2 Direct Request (DR)
In the direct delivery [29] approach of unicasting, a source
node never replicates its message to anyone, but delivers
directly to the intended destination node if and when they
come in contact. The DR scheme for OSP follows this ap-
proach.
Let us consider a node xcarrying an SRM m. Let sbe the
next service required by m. When xcomes in contact with
another node say, y, it checks whether or not yprovides
the desired service s. If it does, then xreplicates mto y; no
replication occurs otherwise.
Both FBR and DR are simple schemes, but represent two
extremes. While FBR overloads the network, DR can run
into higher latencies. It may be noted that these two schemes
would work even if we do not assume the knowledge of
a global services directory (see Section 3.1 and footnote
2). However, in case of DR, the nodes would require to
advertise the services offered by them at the beginning of
each contact.
4.2.3 PRoPHET-based Request (PBR)
PRoPHET [30], [31] uses delivery predictability, a time-
varying metric that quantifies the probability of contact
between two nodes. In particular, for every known node
j∈N, node i∈Nmaintains the value pij , the delivery
predictability of ifor j;i6=j. When iand jcome in contact,
iupdates its delivery predictability according to (5).
pij =pij + (1 −pij )×pinit,(5)
where pinit is an initialization constant. In PRoPHET, time
is divided into discrete units. If the two nodes do not meet
for ksuch consecutive time units, node idecays its delivery
predictability value according to (6).
pij =pij ×γk.(6)
Here, 0< γ < 1is called the aging constant. Finally, it
may so happen that nodes iand jdo not come in contact
frequently, but ioften comes in contact with node l∈N,
and lfrequently meets k;i6=j6=l. Consequently, node i
comes in contact with jtransitively. Equation (7) takes this
aspect into account.
pij =pij + (1 −pij )×pil ×plj ×β, (7)
where 0≤β≤1is called the transitivity constant.
In PBR, we use the pij values to compute a new metric,
service predictability, of a node for the set of available services
in the OMN. Since the nodes have the service directory
available with themselves, for a given service say, s, it is
known which all nodes provide that service. Accordingly,
node icomputes the predictability for service sas:
qi(s) = 1
|DS(s)− {i}| X
x∈DS(s),x6=i
pix.(8)
In other words, in (8), we average the delivery pre-
dictability of all nodes that provide a particular service
s∈S. This computation is performed at the beginning of
every contact event between any pair of nodes. Moreover,
the service predictability vector is also exchanged among
the nodes for replication decision making, as discussed later.
In PRoPHET, node ireplicates a message, which is
destined for say, x, to kif pkx > pix. We follow a similar
approach in PBR. Let sbe the next service that needs to be
processed for a given SRM say, m. Then, node ireplicates m
to jif qj(s)> qi(s). Otherwise, the SRM is not replicated.
Algorithm 1 summarizes the steps for computation of
qi(s)for each service. It iterates over all the available ser-
vices (line # 1), and maintains a running sum of delivery
predictabilities for each node providing the service (line #
7). Finally, it determines the quality of service by converting
the sum into average (line # 8). Let us assume that hDSi
is stored as a key-value pair, where a key indicates the
name of a service, and the value is the set of its providers.
Then, the membership checking operation over DScan be
performed in constant time. Therefore, the time complexity
of Algorithm 1 becomes O(|S| × |N|). However, one would
need to store the delivery and service predictabilities. So, the
space complexity of the Algorithm becomes O(|S|+|N|).
Figure 2 illustrates the overall functionality of PBR when
two nodes iand jcome in contact. At the beginning, the
nodes exchange their delivery predictability vectors. Sub-
sequently, the service predictability vectors are computed
and exchanged. This is followed by screening of each SRM
carried by the nodes. An SRM is replicated to the other node
if it is found a suitable candidate. On the other hand, if
all services requested by an SRM are processed, a service
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
6
Algorithm 1: Computation of service predictabilities
by node i
Input:
•hpii: List of delivery predictabilities
•S: Set of services
•hDSi: Service directory
Output:
•hqii: List of service predictabilities
1for each service s∈Sdo
2K=|DS(s)−i|;// Count of nodes that
provide service sexcept this node
3p= 0
4for each node x∈Ndo
5if x6=iand x∈DS(s)then
6;// xprovides the service s
7p=p+pix
8qi(s) = p/K
Fig. 2: Illustration of actions taken by node iwhen it comes
in contact with j. Both the nodes are using the PBR scheme.
response message is created. Additionally, the response
messages are also replicated as dictated by PRoPHET. This,
however, is not shown in Figure 2.
4.2.4 Unicast-based Request (UBR)
The UBR scheme is aimed at achieving OSP based on the
traditional unicast mechanism. UBR, too, leverages the de-
livery predictability values computed by PRoPHET. How-
ever, unlike the previously discussed three schemes, in UBR,
SRMs are sent as unicast (using PRoPHET) messages to the
best service providers. Given an arbitrary service s, node i
determines its best provider(s) as:
Ai(s) = arg maxx{pix |x∈DS(s)}.(9)
In other words, node iconsiders any node xproviding
the concerned service and having the highest delivery pre-
dictability among all such nodes as the best service provider.
However, it may so happen that a node knows who the
providers of a particular service are, but does not have
the delivery predictability for any of those nodes. In such
a scenario, the former node assumes the node having the
highest delivery predictability as the “best” service provider.
Then, (9) translates into:
Bi= arg maxx{pix}.(10)
Combining (9) and (10), we define the composite set of best
service providers as:
Bi(s) = (x∈Bi, if Ai(s) = ∅
x∈Ai(s), otherwise (11)
Let us now consider a node i∈Nthat intends to request
a set of services. Let sbe the first service that must be
processed among those. Following (11), the node creates
a unicast message, fills in the SERVICES field, and sets
the destination to any randomly chosen node b∈Bi(s).
Subsequently, the mechanism of PRoPHET is followed to
route the unicast message.
When another node receives such a request message
and itself offers the service currently sought after by the
message, the node does the necessary processing, and re-
moves the corresponding service from the SERVICES field,
as discussed previously. Subsequently, it identifies the next
service that must be provided for that message. Once again,
using the formulation presented in (11), it identifies the best
provider for the corresponding service, and updates the
destination of the unicast message to that particular node.
This process continues until the message reaches a node
that provides the last service following which, the request
message is no more replicated.
5 PERFORMANCE EVALUATION
Here, we discuss the experimental setup and metrics used
to evaluate the performance of different OSP schemes.
5.1 Simulation Setup
We implemented the previously discussed four schemes for
OSP using the Opportunistic Network Environment (ONE)
[29] simulator. In particular, we considered a set of ten
(|S|= 10) different services that were provided in the OMN;
the services offered by the individual nodes were randomly
chosen from that set. The SRMs were created every 10–20
minutes, and their (payloads’) size varied from 10–500 KB.
For each SRM created, a list of different services were added
to the SERVICES field based on the degree of (ordered)
chaining (k). The time-to-live (TTL) for the messages were
set to 20 hours.
We conducted two experiments using this setup. First,
while keeping the value of kfixed, we varied the number of
services offered by the nodes. In particular, we considered
that the nodes provided 10–50% of the total number of
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
7
available services. This helped us to determine how the per-
formance of OSP varied as more nodes engaged in offering
services to the others.
Second, while keeping the number of services provided
by a node fixed, we varied the value of kfrom 1–5. Intu-
itively, as the degree of chaining increases, the percentage
of service requests satisfied should fall. The objective of this
experiment was to quantify the extent of such degradation.
We used the Sassy [32] real-life connection traces in our
experiments. The Sassy trace consists of connection up-
down events from 27 devices having transmission ranges
of about 10 m. We considered the connection change events
for the first 120 from the Sassy traces. We also considered
the truncated Levy Walk (TLW) [33] mobility model, which
captures movement patterns of humans. In this scenario, we
considered 50 nodes moving in a terrain of size 1.5×1.5sq.
Km. Additionally, the RWP mobility model was also used.
Each node transmitted data with a speed of 2 Mbps up to a
distance of 100 m.
Since the simulation setup and algorithms involve ran-
domization, we simulated each scenario for five different
values of the random number generator. The results were
obtained by taking the average of the five scenarios.
5.2 Evaluation Metrics
Let RC=∪
i∈NRiand RS, respectively, be the set of service
requests created and satisfied in the OMN. For any r∈RS,
let tC(r)and tS(r), respectively, be the time instants when
the service request rwas created and satisfied (i.e., the
requesting node received the corresponding response mes-
sage). Based on these, we define the following performance
evaluation metrics.
•Requests satisfied: It is the ratio of the number of
service requests satisfied in the OMN to the number
of such requests created, i.e., |RS|
|RC|. A higher value
indicates better performance.
•Latency of satisfaction: It is the time taken, on an
average, to have a service request processed and
satisfied. It is evaluated as 1
|RS|Pr∈RS[tS(r)−tC(r)].
The goal of any OSP scheme is to reduce this latency.
•Requests overhead: Since both SRMs and response
messages in the OMN are replicated to several nodes,
it introduces overhead. We measure the overhead in
routing SRMs as the ratio of the number of replicas
received by the nodes to the number of SRMs created
(|RC|). All other things being equal, one should
attempt to reduce the requests overhead.
6 RE SU LTS
In this Section, we discuss the results of performance eval-
uation, which are presented as a series of heatmaps, with
variation in the color scale denoting the differences in the
values of the concerned metrics. The corresponding values
are also indicated in the Figures for ease of interpretation.
6.1 Effects on Service Requests Satisfied
Figures 3 and 4, respectively, show the percentage of service
requests satisfied in the Sassy and TLW scenarios. The x-
axis shows the percentage of services that were available
with the nodes. For example, “20%” indicates that the nodes
offered two randomly chosen (out of ten) services. The y-
axis shows the degree of chaining used with the SRMs.
Two general trends can be observed here. First, as the
number of services available in the OMN increased for
a given degree of chaining, more service requests were
satisfied. Second, for a given number of service providers,
as the degree of chaining increased, the number of interests
satisfied considerably fell down. This is due to the reason
that when the degree of chaining increased, a message
usually had to be moved from one device to the other. Given
that the SRMs had a fixed TTL and the inter-contact time
among the nodes in OMNs is, in general, high, the entire
chain of the services requested could not be processed.
Consequently, such SRMs remained unsatisfied.
In particular, the worst performance was obtained when
10% of the services were available and the degree of chain-
ing was 5. On the other hand, the best performance was
recorded when 50% of the services were offered by the
nodes and the chaining degree was unity.
Figure 3 (a) indicates that FBR fared very well in the
lower triangular region of the heatmap (low chaining-more
services). On the other hand, PBR (Figure 3 (c)), in gen-
eral, outperformed DR, although its own performance was
marginally lower than that of FBR (Figure 3 (b)). Figure 3
(d) shows that UBR, however, offered a mixed performance.
When up to 30% service availability were considered with
single degree of chaining, UBR outperformed PBR by a large
extent. However, it resulted in the least number of requests
satisfied when the chaining degree was five.
In the TLW scenario in Figure 4, FBR fared relatively
better than PBR and DR. UBR, on the other hand, lagged
behind DR in terms of the number of requests satisfied. On
the other hand, Figure 5 shows that almost 99% of the SRMs
were satisfied under the RWP mobility model. This was true
even when DR was used. To understand this phenomenon,
we look at Figure 6, which shows that the frequency of
hourly contacts among the nodes under RWP were signifi-
cantly high as compared to TLW. In fact, it is a characteristic
of RWP where the nodes tend to visit the center of a terrain
more often than its boundaries. Consequently, they get more
opportunities to exchange messages among themselves.
6.2 Effects on Satisfaction Latency
Figures 7 and 8 show the average latencies3of service
request satisfaction in the Sassy and TLW scenarios, respec-
tively. Figure 7 (a) shows that FBR resulted in the least
latency among the four schemes considered here. This can
be accounted to the flooding of SRMs to all possible nodes in
the OMN. This general trend also largely prevailed in Figure
8 even though the inter-scheme differences were minor.
Figures 7 (b) and (c) indicate that PBR resulted in less la-
tency, on an average, than DR. UBR, on the other hand, fared
significantly worse than the other three schemes (Figures 7
(d) and 8 (d)). A possible reason behind this is the likely
imprecision of the local notion of “best service provider”,
as considered in (11). In the RWP scenario in Figure 9, we
observe that the latencies, in general, are less than those
3. The reader should note that average delivery latencies in OMNs,
in general, are high due to intermittent connectivity among the devices.
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
8
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
84.74 87.75 89.94 89.98 89.90
58.02 86.14 89.32 89.28 89.20
33.73 77.69 87.55 89.03 89.28
13.11 54.43 84.29 88.45 89.11
5.53 38.60 72.99 86.76 88.99
0
10
20
30
40
50
60
70
80
90
Requests satisfied (%)
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
32.29 52.99 65.73 71.96 78.10
20.00 43.75 56.29 66.31 72.74
13.32 39.26 55.42 66.02 74.68
10.93 34.52 49.36 64.95 71.34
7.18 38.76 51.22 67.75 73.11
0
10
20
30
40
50
60
70
80
Requests satisfied (%)
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
65.48 79.13 85.03 86.27 87.84
49.73 72.99 79.84 84.87 84.70
41.07 70.10 82.14 84.21 85.24
21.24 68.41 81.57 83.92 84.74
10.14 61.65 79.09 83.63 83.92
10
20
30
40
50
60
70
80
90
Requests satisfied (%)
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
79.46 89.61 89.11 89.32 88.91
42.19 73.57 79.71 80.54 79.79
28.82 54.56 72.12 78.43 78.43
10.80 41.77 60.66 73.20 75.18
2.35 22.10 42.80 60.49 70.80
0
10
20
30
40
50
60
70
80
90
Requests satisfied (%)
(d) UBR
Fig. 3: Variation in the percentage of service requests satisfied in the Sassy scenario using different OSP schemes. (Color
online)
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
36.78 43.18 46.97 48.54 51.34
26.85 35.92 38.76 42.35 42.23
19.13 32.29 37.57 35.88 38.68
15.01 24.78 29.86 34.76 34.06
9.36 27.05 28.82 33.28 36.82
5
10
15
20
25
30
35
40
45
50
55
Requests satisfied (%)
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
21.15 33.69 42.31 46.60 49.65
12.49 23.26 31.01 34.02 41.65
7.42 19.84 28.33 30.35 33.81
5.81 14.85 22.52 31.42 31.71
4.58 14.97 22.39 29.11 28.45
0
5
10
15
20
25
30
35
40
45
50
Requests satisfied (%)
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
31.01 42.56 45.28 48.99 50.52
24.66 32.82 38.64 39.42 41.94
19.59 22.23 35.22 39.13 38.31
11.26 24.70 30.52 33.81 36.62
10.14 20.58 23.75 30.97 29.24
10
15
20
25
30
35
40
45
50
55
Requests satisfied (%)
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
25.48 33.11 34.89 38.89 41.65
11.71 23.26 30.64 31.30 30.27
6.64 15.38 17.77 23.71 28.82
4.29 9.15 20.70 20.70 24.87
2.14 8.29 8.74 12.25 16.74
0
5
10
15
20
25
30
35
40
45
Requests satisfied (%)
(d) UBR
Fig. 4: Variation in the percentage of service requests satisfied in the TLW scenario.
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
99.58 99.79 99.86 99.79 99.72
96.52 99.58 99.72 99.51 99.58
86.62 99.37 99.72 99.58 99.58
70.17 98.47 99.37 99.65 99.58
57.14 97.21 99.51 99.65 99.58
55
60
65
70
75
80
85
90
95
100
Requests satisfied (%)
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
99.09 99.72 99.65 99.79 99.93
98.33 99.44 99.58 99.86 99.79
97.91 99.09 99.37 99.51 99.58
96.93 98.89 99.23 99.16 99.37
97.63 99.09 99.16 99.44 99.44
96.5
97
97.5
98
98.5
99
99.5
100
Requests satisfied (%)
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
99.30 99.72 99.72 99.72 99.93
94.77 99.58 99.65 99.58 99.58
91.15 99.37 99.44 99.65 99.58
92.96 99.23 99.23 99.23 99.65
89.20 99.30 99.16 99.51 99.51
88
90
92
94
96
98
100
Requests satisfied (%)
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
96.79 99.16 99.30 99.65 99.72
97.49 98.95 99.30 99.51 99.30
94.01 98.68 98.89 99.37 99.16
81.53 98.12 98.82 99.23 99.30
59.30 96.79 98.95 98.95 99.16
55
60
65
70
75
80
85
90
95
100
Requests satisfied (%)
(d) UBR
Fig. 5: Variation in the percentage of service requests satisfied using the RWP mobility model.
0
100
200
300
400
500
600
0 10 20 30 40 50 60 70
No. of contacts
Simulation time (hours)
TLW
RWP
Fig. 6: Hourly contact frequencies under the TLW and RWP
mobility models.
in Sassy and TLW. Once again, this follows from the high
frequency of node contacts in RWP.
6.3 Effects on Requests Overhead
Finally, we look at the overhead incurred due to replication
of the SRMs in the OMN. Figures 10 and 11 show the
corresponding overheads obtained in the Sassy and TLW
scenarios, respectively. It can be noted from Figures 10 (b)
and 11 (b) that DR resulted in the least overhead. This is due
to the reason that DR replicates an SRM only to a node that
provides the required service. Unsurprisingly, the highest
request overhead was caused by FBR, because it replicates
SRMs to all nodes that come in contact. PBR in Figures 10
(c) and 11 (c), on the other hand, caused only a moderate
overhead, which was far lower than both FBR and UBR.
Figure 12 shows that the overhead incurred under the RWP
mobility was high even when DR was used. Such a high
redundancy in transmission for all the OSP schemes helped
in satisfying 99% of the service requests under RWP.
6.4 Discussion
Taking a holistic view, PBR tends to offer good compromise
in terms of all the performance metrics considered. In partic-
ular, Figures 10 and 11 indicate that the overhead incurred
on using FBR can be up to about 3–4times that of PBR.
Overhead of message replications has direct impact upon
the energy consumption of the mobile devices. In contrast,
although DR has a lower overhead, PBR, in general, helps in
satisfying more service requests, especially those that have
higher chaining degrees.
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
9
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
8.54 5.61 3.81 3.57 3.65
10.22 7.01 5.98 5.22 4.49
15.76 11.77 8.25 5.44 5.55
27.13 21.61 9.91 6.69 5.44
40.24 19.98 12.79 9.69 5.88
0
5
10
15
20
25
30
35
40
45
Latency (minutes)
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
59.47 51.00 36.80 32.91 23.80
88.79 61.49 51.87 42.34 33.17
79.99 71.60 59.26 43.41 35.35
122.89 78.13 64.15 51.65 42.37
114.82 80.14 62.45 45.04 45.41
20
30
40
50
60
70
80
90
100
110
120
130
Latency (minutes)
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
45.48 30.81 27.18 17.19 15.25
64.62 38.00 33.62 26.80 19.34
66.92 54.10 34.18 33.58 26.49
81.29 54.06 47.13 37.98 28.41
80.04 61.27 44.56 36.71 33.97
10
20
30
40
50
60
70
80
90
Latency (minutes)
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
50.24 19.83 22.53 20.27 25.01
261.99 180.30 153.21 118.76 101.68
416.15 336.32 242.89 196.74 166.97
516.40 441.18 374.03 301.31 239.94
568.86 567.89 471.03 413.78 326.26
0
100
200
300
400
500
600
Latency (minutes)
(d) UBR
Fig. 7: Variation in the average latency of requests satisfaction in the Sassy scenario. Note that the color palette is inverted
in this Figure for the sake of readability.
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
527.80 361.85 320.56 248.46 195.31
791.45 575.30 549.32 474.83 387.22
890.44 761.47 684.71 591.23 573.50
979.83 838.34 734.83 688.82 655.77
997.82 978.66 846.63 771.90 676.98
100
200
300
400
500
600
700
800
900
1000
Latency (minutes)
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
337.18 301.77 268.87 219.26 203.42
616.73 518.30 467.61 399.43 356.69
740.45 665.29 568.84 456.18 467.95
941.30 778.00 677.82 602.20 536.08
979.07 830.55 698.74 655.49 670.24
200
300
400
500
600
700
800
900
1000
Latency (minutes)
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
531.67 374.78 284.61 221.24 195.04
740.48 579.52 524.11 404.21 401.31
949.70 721.51 596.57 525.37 445.04
1006.47 818.89 748.20 616.30 636.33
1142.26 943.51 814.17 732.30 704.01
100
200
300
400
500
600
700
800
900
1000
1100
1200
Latency (minutes)
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
699.55 541.77 464.69 419.63 383.75
958.98 771.47 687.17 581.65 530.06
1144.40 894.22 848.25 758.85 697.99
1137.51 962.19 934.72 816.44 739.58
1246.791017.95 915.48 921.52 789.32
300
400
500
600
700
800
900
1000
1100
1200
1300
Latency (minutes)
(d) UBR
Fig. 8: Variation in the average latency of requests satisfaction in the TLW scenario
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
18.75 12.44 10.11 7.67 6.21
27.14 20.38 16.83 14.27 12.32
31.63 24.60 20.65 18.27 16.56
36.37 28.20 24.16 21.25 19.03
39.29 31.26 26.10 23.94 21.42
5
10
15
20
25
30
35
40
Latency (minutes)
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
33.36 16.61 10.22 7.85 6.18
65.14 31.25 21.54 17.03 14.06
87.46 41.97 29.96 23.76 20.14
98.03 47.30 34.64 28.24 24.11
96.90 52.00 38.75 31.77 26.93
0
10
20
30
40
50
60
70
80
90
100
Latency (minutes)
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
26.31 16.01 10.93 9.31 6.88
37.52 27.63 21.38 17.79 15.79
48.58 33.74 26.42 23.38 20.85
54.84 37.24 30.14 27.19 25.05
57.76 39.53 33.70 29.89 26.89
0
10
20
30
40
50
60
Latency (minutes)
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
38.81 32.52 27.85 23.15 19.39
53.63 41.70 35.91 30.55 25.63
62.14 47.86 39.89 33.87 30.28
71.91 53.28 43.84 39.17 34.65
76.44 58.97 47.53 41.90 36.77
10
20
30
40
50
60
70
80
Latency (minutes)
(d) UBR
Fig. 9: Variation in the average latency of requests satisfaction in the RWP scenario.
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
57.28 57.87 58.20 58.19 58.11
51.56 57.72 58.32 58.15 58.13
46.17 55.98 58.14 58.34 58.35
41.66 50.82 57.44 58.31 58.43
39.98 47.24 54.93 57.98 58.45
38
40
42
44
46
48
50
52
54
56
58
60
Request Overhead
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
4.41 7.00 8.59 9.34 10.12
3.90 7.53 9.59 11.04 12.09
3.61 8.28 11.48 13.57 15.24
3.61 8.89 12.52 15.98 17.56
3.35 11.22 15.15 19.57 20.85
2
4
6
8
10
12
14
16
18
20
22
Request Overhead
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
14.22 14.22 14.00 13.19 12.78
18.13 19.33 18.76 17.64 16.68
22.08 25.14 24.48 22.61 21.32
21.43 30.58 29.20 27.28 25.16
17.69 33.06 33.84 31.19 28.74
10
15
20
25
30
35
Request Overhead
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
30.83 31.49 30.44 29.84 29.04
27.08 30.58 30.63 30.05 29.36
25.76 28.23 29.47 29.76 28.93
23.54 27.46 28.93 29.74 29.24
22.51 25.02 27.00 28.38 28.94
22
23
24
25
26
27
28
29
30
31
32
Request Overhead
(d) UBR
Fig. 10: Variation in the requests overhead in the Sassy scenario using different OSP schemes.
On the other hand, the unimpressive performance by
UBR, in general, suggests that adapting unicast as it is for
OSP may not be very useful. Flooding-based FBR results
in a lot of overhead, whereas DR can cause high latencies.
Moreover, all the other three schemes – FBR, DR, and PBR
– are relatively more resilient as compared to UBR. This is
due to the reason that by unicasting in UBR, an SRM is
sent to a specific device. However, if the concerned device
is unavailable (for example, battery completely exhausted
or moved to a distant region), then the desired service
would not be rendered. In contrast, since the other three
schemes do not target a particular node, any device in the
OMN can provide the required service. Therefore, taking a
holistic view, PBR stands out among the four schemes for
OSP considered in this work.
7 CONCLUSION
In this work, we addressed the problem of OSP in the con-
text of OMNs. Given that two or more services are requested
for a given data object in a specific sequence, the objective
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
10
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
74.48 70.18 77.50 74.27 74.82
70.36 75.28 77.08 78.80 72.80
63.35 77.22 82.83 74.16 75.72
64.30 68.92 73.57 76.10 66.88
63.61 79.38 72.03 76.86 82.41
62
64
66
68
70
72
74
76
78
80
82
84
Request Overhead
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
3.73 5.96 6.87 8.60 7.59
4.13 6.36 8.45 9.29 10.57
3.55 8.96 11.31 11.24 11.69
3.97 7.66 10.04 14.12 14.28
3.88 9.39 12.17 15.64 14.25
2
4
6
8
10
12
14
16
Request Overhead
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
13.35 13.89 12.86 10.93 9.35
21.09 18.42 16.02 14.70 13.17
24.02 17.46 21.88 21.60 19.46
21.72 26.00 22.84 21.96 20.14
28.49 25.60 22.61 23.82 20.56
8
10
12
14
16
18
20
22
24
26
28
30
Request Overhead
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
24.57 28.71 26.01 23.19 24.29
22.02 22.77 26.59 24.47 18.72
21.47 23.58 18.44 21.36 22.35
22.99 20.65 25.20 20.89 22.84
24.21 22.69 17.52 17.01 18.48
16
18
20
22
24
26
28
30
Request Overhead
(d) UBR
Fig. 11: Variation in the requests overhead in the TLW scenario.
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
147.14 147.25 147.21 147.24 147.23
145.70 147.20 147.22 147.19 147.19
140.83 147.13 147.22 147.16 147.21
132.60 146.72 147.18 147.18 147.19
126.11 145.98 147.15 147.17 147.17
125
130
135
140
145
150
Request Overhead
(a) FBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
50.98 51.19 51.22 51.23 51.23
52.65 53.05 53.16 53.33 53.35
54.41 55.07 55.34 55.33 55.50
56.13 57.16 57.37 57.46 57.60
58.61 59.24 59.57 59.69 59.74
50
51
52
53
54
55
56
57
58
59
60
Request Overhead
(b) DR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
58.26 54.72 53.42 53.00 52.44
65.74 61.18 58.35 56.67 55.76
73.46 67.10 62.34 60.38 58.74
88.29 73.48 66.91 63.72 61.90
95.52 79.67 71.61 67.58 65.06
50
55
60
65
70
75
80
85
90
95
100
Request Overhead
(c) PBR
1
2
3
4
5
10 20 30 40 50
Chaining degree
Services available (%)
144.15 145.61 145.60 145.50 145.55
145.34 145.98 145.93 145.87 145.85
143.54 145.65 145.80 145.80 145.86
137.52 145.59 145.82 145.86 145.81
126.50 145.02 145.85 145.89 145.77
126
128
130
132
134
136
138
140
142
144
146
Request Overhead
(d) UBR
Fig. 12: Variation in the requests overhead in the RWP scenario using different OSP schemes.
is to efficiently route the service requests to appropriate
providers. We considered four schemes in this regard, which
were evaluated using real-life connection traces as well as
a synthetic mobility model. Among them, the PRoPHET-
based PBR scheme was found to fare the best, in general,
in terms of the percentage of service requests satisfied,
satisfaction latency, and related overhead. The performance
of UBR degraded, in general, when ordered chains of at least
two services were considered.
In the future, this work can be extended in different
ways. For example, it would be interesting to consider a
hybrid scheme that adapts itself in between the extreme
ends of flooding and direct requesting based on the contacts
and offered services density. Along with that, consideration
of devices’ processing capabilities – how many requests it
can process at a time – would also be an interesting problem.
Moreover, in this work, we implicitly assumed that the
nodes advertised and offered genuine services. However,
this may not be necessarily true in practice, for example, a
malicious node may provide a service that corrupts the data
object. Therefore, it would be interesting to study a scheme
that verifies the genuineness of an offered service.
REFERENCES
[1] S. Misra, B. K. Saha, and S. Pal, Opportunistic Mobile Networks:
Advances and Applications. Cham, Switzerland: Springer Interna-
tional Publishing, 2016.
[2] B. K. Saha, S. Misra, and S. Pal, “Utility-based exploration for
performance enhancement in opportunistic mobile networks,”
IEEE Transactions on Computers, vol. 65, no. 4, pp. 1310–1322, 2015.
[3] B. K. Saha, S. Misra, and S. Pal, “SeeR: Simulated annealing-based
routing in opportunistic mobile networks,” IEEE Transactions on
Mobile Computing, vol. 16, no. 10, pp. 2876–2888, 2017.
[4] M. Conti, S. Giordano, M. May, and A. Passarella, “From oppor-
tunistic networks to opportunistic computing,” IEEE Communica-
tions Magazine, vol. 48, no. 9, pp. 126–139, Sep. 2010.
[5] A. Passarella, M. Kumar, M. Conti, and E. Borgia, “Minimum-
delay service provisioning in opportunistic networks,” IEEE Trans-
actions on Parallel and Distributed Systems, vol. 22, no. 8, pp. 1267–
1275, 2011.
[6] R. Lu, X. Lin, and X. Shen, “SPOC: A secure and privacy-
preserving opportunistic computing framework for mobile-
healthcare emergency,” IEEE Transactions on Parallel and Distributed
Systems, vol. 24, no. 3, pp. 614–624, March 2013.
[7] U. Sadiq, M. Kumar, A. Passarella, and M. Conti, “Service com-
position in opportunistic networks: A load and mobility aware
solution,” IEEE Transactions on Computers, vol. 64, no. 8, pp. 2308–
2322, Aug 2015.
[8] S. Chatterjee, R. Ladia, and S. Misra, “Dynamic optimal pricing
for heterogeneous service-oriented architecture of sensor-cloud
infrastructure,” IEEE Transactions on Services Computing, vol. 10,
no. 2, pp. 203–216, March 2017.
[9] D. Ardagna, M. Ciavotta, and M. Passacantando, “Generalized
nash equilibria for the service provisioning problem in multi-cloud
systems,” IEEE Transactions on Services Computing, vol. 10, no. 3,
pp. 381–395, May 2017.
[10] B. K. Saha and S. Misra, “Named content searching in opportunis-
tic mobile networks,” IEEE Communications Letters, vol. 20, no. 10,
pp. 2067–2070, Oct 2016.
[11] L. Zhang, A. Afanasyev, J. Burke, V. Jacobson, K. Claffy, P. Crowley,
C. Papadopoulos, L. Wang, and B. Zhang, “Named data network-
ing,” SIGCOMM Comput. Commun. Rev., vol. 44, no. 3, pp. 66–73,
Jul. 2014.
[12] K. Elgazzar, P. Martin, and H. S. Hassanein, “Personal mobile
services,” Service Oriented Computing and Applications, vol. 10, no. 1,
pp. 55–70, 2016.
[13] H. Artail and S. Saab, “A distributed system for consuming web
services and caching their responses in MANETs,” IEEE Transac-
tions on Services Computing, vol. 2, no. 1, pp. 17–33, Jan 2009.
[14] C. Groba and S. Clarke, “Opportunistic service composition in
dynamic ad hoc environments,” IEEE Transactions on Services Com-
puting, vol. 7, no. 4, pp. 642–653, Oct 2014.
[15] S. C. Geyik, B. K. Szymanski, and P. Zerfos, “Robust dynamic
service composition in sensor networks,” IEEE Transactions on
Services Computing, vol. 6, no. 4, pp. 560–572, Oct 2013.
[16] S. Y. Shah, B. K. Szymanski, P. Zerfos, and C. Gibson, “Towards
relevancy aware service oriented systems in wsns,” IEEE Transac-
tions on Services Computing, vol. 9, no. 2, pp. 304–316, March 2016.
[17] M. Amini and F. Osanloo, “Purpose-based privacy preserv-
ing access control for secure service provision and compo-
sition,” IEEE Transactions on Services Computing, 2016, DOI:
10.1109/TSC.2016.2616875.
Accepted Version (For Personal Use Only)
© 2016 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See http://www.ieee.org/publications_standards/publications/rights/index.html for
more information.
11
[18] V. Cardellini, V. D. Valerio, and F. L. Presti, “Game-theoretic
resource pricing and provisioning strategies in cloud sys-
tems,” IEEE Transactions on Services Computing, 2016, DOI:
10.1109/TSC.2016.2633266.
[19] X. Wang, J. Cao, and Y. Xiang, “OSPN: Optimal service provision-
ing with negotiation for bag-of-tasks applications,” IEEE Transac-
tions on Services Computing, 2018, DOI: 10.1109/TSC.2017.2787707.
[20] G. Fortino, C. Savaglio, and M. Zhou, “Toward opportunistic
services for the industrial internet of things,” in 2017 13th IEEE
Conference on Automation Science and Engineering (CASE), Aug 2017,
pp. 825–830.
[21] P. Bellavista, S. Chessa, L. Foschini, L. Gioia, and M. Girolami,
“Human-enabled edge computing: Exploiting the crowd as a dy-
namic extension of mobile edge computing,” IEEE Communications
Magazine, vol. 56, no. 1, pp. 145–155, Jan 2018.
[22] C. Tschudin and M. Sifalakis, “Named functions for media deliv-
ery orchestration,” in 2013 20th International Packet Video Workshop,
Dec 2013, pp. 1–8.
[23] M. Sifalakis, B. Kohler, C. Scherb, and C. Tschudin, “An infor-
mation centric network for computing the distribution of com-
putations,” in Proceedings of the 1st ACM Conference on Information-
Centric Networking. New York, NY, USA: ACM, 2014, pp. 137–146.
[24] C. Groba and S. Clarke, “Opportunistic composition of
sequentially-connected services in mobile computing environ-
ments,” in 2011 IEEE International Conference on Web Services, July
2011, pp. 17–24.
[25] G. Guerrero-Contreras, J. L. Garrido, S. Balderas-Diaz, and
C. Rodriguez-Dominguez, “A context-aware architecture support-
ing service availability in mobile cloud computing,” IEEE Transac-
tions on Services Computing, vol. 10, no. 6, pp. 956–968, 2017.
[26] S. Deng, L. Huang, J. Taheri, J. Yin, M. Zhou, and A. Y. Zomaya,
“Mobility-aware service composition in mobile communities,”
IEEE Transactions on Systems, Man, and Cybernetics: Systems, vol. 47,
no. 3, pp. 555–568, March 2017.
[27] C. Marxer, C. Scherb, and C. Tschudin, “Access-controlled in-
network processing of named data,” in Proceedings of the 3rd ACM
Conference on Information-Centric Networking. New York, NY, USA:
ACM, 2016, pp. 77–82.
[28] A. Vahdat and D. Becker, “Epidemic routing for partially-
connected ad hoc networks,” Duke University, Tech Report CS-
2000-06, 2000.
[29] A. Ker ¨
anen, J. Ott, and T. K¨
arkk¨
ainen, “The ONE simulator for
DTN protocol evaluation,” in Proceedings of the 2nd International
Conference on Simulation Tools and Techniques, ser. Simutools ’09.
ICST, Brussels, Belgium, Belgium: ICST (Institute for Computer
Sciences, Social-Informatics and Telecommunications Engineer-
ing), 2009, pp. 55:1–55:10.
[30] A. Lindgren, A. Doria, and O. Schel´
en, “Probabilistic routing
in intermittently connected networks,” in Proceedings of the 1st
International Workshop on Service Assurance with Partial and Inter-
mittent Resources (SAPIR), Berlin, Heidelberg: Springer Berlin /
Heidelberg, Aug. 2004, pp. 239–254.
[31] S. Grasic, E. Davies, A. Lindgren, and A. Doria, “The evolution
of a DTN routing protocol - PRoPHETv2,” in Proceedings of the
6th ACM Workshop on Challenged Networks. New York, NY, USA:
ACM, 2011, pp. 27–30.
[32] Greg Bigwood, Tristan Henderson, Devan Rehunathan,
Martin Bateman, and Saleem Bhatti, CRAWDAD
dataset st andrews/sassy (v. 2011-06-03), downloaded
from https://crawdad.org/st andrews/sassy/20110603,
https://doi.org/10.15783/C7S59X, Jun 2011. [Accessed: 20
Feb. 2017].
[33] I. Rhee, M. Shin, S. Hong, K. Lee, S. J. Kim, and S. Chong, “On
the levy walk nature of human mobility: Do humans walk like
monkeys?” IEEE/ACM Transactions on Networking, vol. 19, no. 3,
pp. 630–643, Jun. 2011.
Barun Kumar Saha received his PhD de-
gree in Computer Science and Engineering
from the Indian Institute of Technology Kharag-
pur, India. His research has been published
in several journals and conferences. He has
co-authored the book titled Opportunistic Mo-
bile Networks: Advances and Applications pub-
lished by Springer. He maintains a blog on
DTN and the ONE simulator at http://delay-
tolerant-networks.blogspot.com/, which is widely
acclaimed in the community. Further details
about Barun can be found at http://barunsaha.me
Sudip Misra is a Professor in the Department of
Computer Science and Engineering at the Indian
Institute of Technology Kharagpur. He received
his Ph.D. degree in Computer Science from Car-
leton University, in Ottawa, Canada. Dr. Misra
is the author of over 230 scholarly research
papers and 8 books, and recipient of several
awards and fellowships including IEEE Com-
Soc Asia Pacific Outstanding Young Researcher
Award (IEEE GLOBECOM 2012, USA), (Cana-
dian) Governor General’s Academic Gold Medal
at Carleton University, India – Swarna Jayanti Puraskar (Golden Jubilee
Award), the Canadian Government’s prestigious NSERC Post Doctoral
Fellowship, and the Humboldt Research Fellowship in Germany. Dr.
Misra is the Editor-in-Chief of the International Journal of Communica-
tion Networks and Distributed Systems (IJCNDS), and Associate Editor
of several other journals including Telecommunication Systems Journal
(Springer SBM), Security and Communication Networks Journal (Wiley),
and EURASIP Journal of Wireless Communications and Networking.
Dr. Misra was also invited to deliver keynote/invited lectures in over 30
international conferences in USA, Canada, Europe, Asia and Africa.
