A Lightweight Service Discovery Mechanism for Mobile Ad Hoc Pervasive
Environment Using Cross-layer Design
Li Li and Louise Lamont
Communications Research Centre of Canada
{li.li, louise.lamont}@crc.ca
Abstract
This paper presents a lightweight service discovery
mechanism for the mobile ad hoc pervasive environment,
applying cross-layer design to reduce the infrastructure
and protocol overhead, and to improve service
accessibility. Integrated with the network routing layer,
the proposed mechanism automatically identifies the
proper service discovery model for the current network
configuration. The solution adapts to network expansion
with enhanced scalability. Simulation studies of real-time
service scenarios employing the proposed mechanism are
presented, demonstrating the efficiency of the mechanism
and the satisfactory service performance results.
1. Introduction
In mobile ad hoc pervasive environment, service
execution has to be carried out with minimum
configuration or user intervention when end devices and
network hosts often have no fixed networking relationship. An effective service discovery scheme is thus
essential. The mobile communication nodes, including
mobile servers, cause unpredictable topology dynamics in
an ad hoc network. The lightweight mobile devices with
confined battery power also means that the ad hoc
environment is limited on its computing and networking
resource. The topology dynamics and resource limitations
give rise to special considerations when adopting a
service discovery scheme in the ad hoc network.
This paper presents a lightweight service discovery
mechanism for the support of pervasive applications over
Mobile Ad-hoc Networks (MANET), using cross-layer
design. Effectively integrated with the routing layer, the
proposed mechanism reduces the system infrastructure
and protocol overhead. Meantime, the mechanism offers
enhanced capabilities in managing network mobility, e.g.,
handling the case when the directory is partitioned from
the rest of the network. The solution scales for large sized
networks, and interoperates with the existing service
locating scheme if already built into a service.
The rest of the paper is organized as follows: Section 2
reviews different service discovery models and compares
the related work; Section 3 elaborates the lightweight
service discovery mechanism; Section 4 presents the
performance simulation results; Section 5 concludes the
paper.
2. Service discovery models and related work
There have been intensive research efforts in the field
of service discovery mechanisms. In [13], the service
discovery models are classified into two categories:
client-service model and client-service-directory model.
In the client-service model, clients broadcast or multicast
queries to inquire about services’ availability. The
services that find them match with the criteria in a
received query would return replies. After receiving
responses from services, clients select and contact
services. This model brings the advantage of requiring no
directory server in the network, while having the
shortcoming of not being able to scale well for big
networks with large numbers of services deployed. In the
client-service-directory model, a client queries a directory
for service information and then contacts the services.
Services, on the other hand, register service information
with the directories. The client-service-directory model
offers better scalability when handling large numbers of
services deployed. However, in a MANET, managing
directory server(s) has become of a non-trivial task [1]. A
new algorithm for managing distributed directories has
been proposed to ensure the availability of the directories
in a mobile ad hoc network, though such algorithm
usually brings overhead of extra messages and computing
phases [1]. In SSDS [18] and PrudentExposure [13], the
client-service-directory model is adopted for better
scalability.
Recently, most of the service discovery solutions
proposed for MANET attempt to apply the client-service
model to avoid the management of the directories. In
Konark [14], the middleware layer applies the clientservice model for service discovery and delivery.
Protocol efficiency, i.e., a lightweight messaging
This work was funded by the Defense Research and Development Canada (DRDC)
Proceedings of the 3rd Int’l Conf. on Pervasive Computing and Communications Workshops (PerCom 2005 Workshops)
0-7695-2300-5/05 $20.00 © 2005 IEEE
mechanism for discovery, is also a major goal in the
various proposals [2][7][11].
Among the lightweight service discovery mechanisms
for MANET, the service query-and-response messages
are often piggybacked onto the reactive ad hoc routing
protocols, including unicast and multicast routing
protocols [2][7][11]. In all these proposals, the clientservice model is employed as no centralized directory
server is assumed in the MANET.
The LSD (Lightweight Service Discovery) solution
proposed in this paper differs from existing service
discovery protocols in that it leverages on the topology
information and messaging capability provided from a
proactive routing layer [3][10]. The proactive routing
offers a more comprehensive view of network topology.
Such an approach brings about enhanced capability for
network mobility management. The proposed mechanism
can detect promptly, for example, the network size
change, and then activate the cooperative caching or the
directory function if available for enhanced scalability.
Almost all of the previous work on lightweight service
discovery for MANET assumes reactive routing protocols
[2][7][11], though a proactively routed network may
improve the service access latency and real-time data
transmission delay - factors that are critical to the
performance of real-time applications desired in many
pervasive communication scenarios.
3. The LSD mechanism
3.1. Service discovery model
The proposed Lightweight Service Discovery (LSD)
mechanism can support both the client-service and the
client-service-directory models. LSD in fact automatically
identifies if a directory server is currently available in the
network, and then adapts to the required operations.
In LSD a directory server periodically advertises itself
triggered by the timer of t_advertise or a change in its
configuration information. If not hearing any directory for
a defined time 'T , a service node may after a random
backup time broadcast a query requesting about the
directory service, to which the directory would respond;
so may a client node to discovery the directory.
When a directory is available in the network, service
nodes register with the directory about their service
records, and refresh the records periodically. If no
directory is known, a node replies directly to a query if it
has a matching service. A service in this case also has an
option to periodically advertise in the network unless its
t_advertise is set to f to limit the network traffic load.
When not knowing any directory, a client sends the
service query to the entire network, using the messaging
mechanism elaborated in the next subsection. If having
the information of a directory server, the client sends the
query to the directory server. When the directory fails to
reply to the query (after a limited number of retries), the
client would resend the query with a flag to the network
asking the service to directly respond. If no directory
responds to this query, the directory is marked then as not
available by all the nodes that hear the flagged query, and
the response message from the service node instead of
from a directory. Thus, the LSD automatically switches
between the client-service and the client-service-directory
models, adapting to the dynamics in the MANET.
3.2. Service discovery messaging
To achieve the system efficiency, IETF standard
Optimized Link State Routing (OLSR) protocol [3] is
selected to embed the LSD. In the OLSR protocol, Hello
messages are periodically sent to sense and establish the
sender’s neighbors, and TC (Topology Control) messages
are flooded periodically via the so-called MultiPoint
Relay (MPR) nodes throughout the entire network to
advertise the topology information of each node; the
topology information is then used to build the routing
table locally at each node [3]. MPR forwarding provides
an efficient broadcasting mechanism in MANET.
The specification of the OLSR protocol facilitates
extension of the protocol functionality through the
addition of new message types [3]. OLSR provides the
backward compatibility enabling the nodes that do not
understand a new message to function seamlessly in the
network [3]. To implement the LSD mechanism, a new
message type, Service Location Extension (SLE), is
introduced into OLSR, which performs the service
advertising, query, response and register functions.
Using MPR forwarding, the advertising SLE messages
are sent to reach the entire network to advertise services
and directories. So are the query SLEs when service
directories are not known. When the locations of the
service directory are available, the query SLE is unicasted
to the service directory. A response SLE may be sent
using unicast, though it may also be sent using MPR so
that other nodes that are also interested in the service can
cache the information for later use. In some instances this
“MPR forwarding” response strategy can be excessive,
but in other cases especially for popular services required
by most of the nodes in a network without directory, it
reduces redundant queries that would otherwise be
generated by other nodes.
3.3. Scalability for hierarchical network
Harnessing the topology information provided by the
routing layer, LSD offers scalability to handle the size
changes of the network. For large sized MANET, the
proactive routing protocol often employs clusters and
http://www.unik.no/personer/paalee
Proceedings of the 3rd Int’l Conf. on Pervasive Computing and Communications Workshops (PerCom 2005 Workshops)
0-7695-2300-5/05 $20.00 © 2005 IEEE
hierarchies [16][17][18][19][20] to curb the routes
advertising traffic volume. In the OLSR case, for
example, the HOLSR (Hierarchical OLSR) [16] forms
clusters and hierarchies to limit the propagation of the
Hello and TC messages within a cluster. The cluster head
summarizes the information of the cluster in a different
new message other than Hello and TC, and then
propagate it outside of the local scope further onto the
next level of the hierarchy.
Given node set N ={n1, n2, … nk}, for each ni  N , ni
is responsible to forward the summarized route
information of the current cluster/group/level to the next
cluster/group/level. Node set N actually contains the
cluster head or level/group leader of the hierarchical
routing protocol [16][17][19]. In LSD, node ni  N also
sends the SLE messages externally to the next cluster or
level. However in general, the SLE message cannot be
summarized, but has to be sent in its full content to reach
the destination(s), which may include the entire network.
Define the size of the scope of the network that node ni
 N sees as S(ni), where S(ni) includes not only the
number of nodes that ni has in its cluster/group/level, but
also the number of nodes below the level of ni should ni
reside in a higher level of the hierarchy. As the route
information is often summarized when reported outside of
its local scope by the routing protocol, node ni may not
know about the true size of the clusters/groups that are
below it in the hierarchy. A simple solution is to let the
routing protocol message carry the size parameter of a
cluster/group when sent to the higher level.
The LSD offers two options to maintain the messaging
efficiency when the network scales up, with and without a
directory server. In MANET, the case without a directory
server may be more practical and is thus described here.
Assume a network without a directory is expanding with
new nodes joining. A ni  N that has S(ni)>STh, where
STh is a threshold size, would cache the service response
and advertising SLE messages. Then when node ni
receives a query SLE for a service that it has a matching
SLE, ni stops the forwarding of the query SLE to the next
level and replies a response SLE with the cached
information.
4. Performance studies
4.1. Simulation environment
The proposed LSD mechanism is implemented in an
OPNET simulator. In the simulations, each mobile node
modifies its location within the subnet based on the
“random waypoint” model [8]. The standard real-time SIP
(Session Initiation Protocol) [4] service is running in the
network to establish on-demand multimedia sessions. For
each SIP end terminal, i.e., SIP User Agent (UA), the
inter-arrival time of SIP calls is exponentially distributed
with a mean value of 360sec. The duration of the SIP call
is also exponentially distributed with an average of
180sec. In addition to SIP real-time voice traffic, UDP
data transmissions between nodes are effected at an
approximate rate of 2Kbps at each source node. The
OLSR timers for the Hello and TC messages are assigned
default values in accordance with RFC 3626 [3]. The
802.11 WLAN (Wireless LAN) interface is set to a speed
of 1Mbps.
The simulated network is comprised of 51 nodes. Of
those, 40 are SIP UA nodes. There are 25 pairs of UDP
transmissions in the network, distributed randomly
between all the nodes. During the simulations, 31 of the
51 nodes are assumed to reside within the network, with
another 20 SIP nodes coming into the network at an
average of every 360 seconds. The nodes are entering the
network in groups of two. That is, two nodes enter the
network after approximately 360 seconds; after
approximately 720 seconds, another two nodes arrive, etc.
In the simulations, the response SLE is sent using
MPR forwarding. The SLE advertising timer t_advertise is
set to f .
Two types of scenarios are studied, a network N1 of
about 5 u 5 km2 in its size, and a less dense network N2
of 15 u 10 km2.
A SIP network may have its own registrar/proxy
server that locates the UAs in session establishment [4].
To locate such a SIP registrar/proxy server, SIP protocol
specifies the use of DHCP [6] and DNS [5] servers that
may not exist in a MANET. In fact, even the SIP
registrar/proxy server may not be deployed in a MANET.
The SIP specifications also permit the UAs to establish
sessions without the assistance of a proxy/registrar server,
if the UAs can manage to locate each other. We name the
first configuration option as the proxy-based, and the
second option the proxy-less. In the proxy-based
configuration, end terminal UAs discover the information
of the SIP proxy/registrar using LSD, and then send SIP
messages to interact with the proxy/registrar servers to
register and to complete the service access of establishing
sessions with other UAs. In the proxy-less configuration,
UAs apply the LSD to discover the location information
of other UAs, and then establish the session directly with
them. The service specific information of server attributes
carried in the advertising or response SLE message
indicates to the application layer that the server is of “SIP
proxy/registrar” or “UAS” type. This SIP service example
demonstrates the capability of LSD to interoperate with
existing service registrar/discovery mechanism should
such mechanism be aptly deployed in a MANET. LSD
thus expedites service deployment in MANET via reusing
as much as possible the existing capabilities and
implementations of the service.
Proceedings of the 3rd Int’l Conf. on Pervasive Computing and Communications Workshops (PerCom 2005 Workshops)
0-7695-2300-5/05 $20.00 © 2005 IEEE
Call Setup Latency
Percentage of SLE in Total
OLSR Traffic
Compared to the OLSR route advertisement traffic, the
traffic overhead generated by the SLE message is
negligible (under 1%) as illustrated in Figure 1, due to a
much longer time interval between the SLE messages
(e.g., 6 minutes of average query interval) than those
between Hello and TC messages of every few seconds.
Though a proxy-less architecture entails more SLE
messages than a proxy-based option, the additional SLE
message overhead incurred in the proxy-less architecture
is still insignificant in proportion to the overall OLSR
message overhead. The SLE message overhead is not
much affected by the density and node movements of the
network, as topology changes do not bring SLE updates.
In the Hierarchical OLSR scenario where the overall
OLSR traffic is reduced [16], SLE still generates only the
marginal traffic overhead (< 1%) in proportion to the total
HOLSR message overhead, when LSD scales up using
caching (HOLSR S1). Without caching activated
(HOLSR S2), the SLE overhead may reach to more than
2% of the total OLSR traffic overhead.
SLE Message Overhead
2.50%
2.00%
1.50%
1.00%
0.50%
0.00%
proxyless
one
proxy
dense sparse HOLSR HOLSR
net
net
S1
S2
Scenarios
Figure 1. OLSR Traffic Overhead
The simulations have confirmed that most of the SIP
application performance results are quite satisfactory. For
example, the average SIP application packet (voice
packets) and data packets delivery ratio (i.e., the ratio of
the number of received packets over the number of the
totally sent packets from all the source nodes) is above
99% in both the dense and sparse network scenarios.
Figure 2 plots the average call-setup delays encountered
in the different simulated cases, which also meet the call
setup latency requirement for the real-time session based
services.
Time (msec)
4.1. Simulation results
30
25
20
15
10
5
0
sparse
net
dense
net
proxy-less
with proxy
server
Scenarios
Figure 2. Average SIP Call Setup Delays
The delay time shown in the above diagram does not
include the time spent waiting for the server(s) to be
heard. In the simulations, the query message sent by each
UA solicits all the SIP servers of its interest, including the
proxy/registrar and the UAs to respond. Therefore, except
for the first call at each UA, there is often no service
discovery delay during the call setup phase. The average
service query delay is mostly less than 10msec in the
network. The sparse sized network with more topology
dynamics seems to “outperform” the dense network
because that the call throughput in the latter is higher and
so is the overall traffic load. The proxy-less network
achieves slightly better results, as its call setup traverses
fewer SIP nodes along the call setup path.
In the sparse networks, the call throughput metric that
captures the number of successful call setups during a
one-hour simulation has shown considerable degradation
under the proxy-server architecture. In the same way, the
directory based service discovery model is hindered in its
performance if the directory is separated from the rest of
the network. Figure 3 illustrates several cases to compare
the performance results on the service throughputs in the
sparse network. The first scenario has no directory in the
network. The second scenario consists of one directory
server with no capability switching to the directory-less
model if the directory is not available to some of the
nodes due to a network partitioning. The third scenario
deploys multiple directories to provide the redundancy
and robustness, still with no capability switching to the
directory-less model. And the fourth scenario deploys the
LSD that can automatically switch from the clientservice-directory model to the client-service directoryless model.
It is observed that having multiple directory servers
does not significantly improve the performance of service
accessibility, as the positions of the directory servers in
the network are important for maintaining the query
service for each segregated network areas when the
network partition takes place. LSD maintains a better
performance by switching to the directory-less operation
when the directory is no longer available.
Proceedings of the 3rd Int’l Conf. on Pervasive Computing and Communications Workshops (PerCom 2005 Workshops)
0-7695-2300-5/05 $20.00 © 2005 IEEE
Number of Successful
Calls
Service Throughput
50
40
30
20
10
0
1
2
3
4
Scenarios
Figure 3: Call Throughputs Comparison
5. Conclusion
In this paper, we have proposed a lightweight service
discovery mechanism LSD for the mobile ad hoc
pervasive environment. Applying cross-layer design, LSD
employs the messaging mechanism of the OLSR routing
layer to efficiently implement the service discovery
protocol with reduced infrastructure and protocol
overhead. Leveraging on the topology information
obtained at the routing layer, the LSD has enhanced
capability in accommodating the topology change and in
supporting network scalability. LSD also interoperates
with existing service registrar mechanism if already built
into a service. We implemented LSD in the OPNET
simulator and evaluated the performance measurements
for supporting the real-time multimedia SIP service. The
OLSR traffic overhead introduced by the SLE messages
for service discovery was found to be insignificant. And
the SIP service delivers satisfactory performance metrics
running on the LSD mechanism.
10. References
[1] U Kozat and L Tassiulas, “Service Discovery in Mobile Ad
Hoc Networks: An Overall Perspective on Architectural Choices
and Network Layer Support Issues”, Ad Hoc Networks, Vol 2,
2004, pp.23-44
[2] Paal E. Engelstad et al, “Name Resolution in on-demand
MANETS and over external IP Networks” IETF Internet Draft,
draft-engelstad-manet-name-resolution-01.txt, Jan 2004
[3] T. Clausen, P. Jacquet et al., “Optimized Link State Routing
Protocol”, IETF RFC 3626, October 2003
[4] J. Rosenberg et al., “SIP: Session Initiation Protocol”, IETF
RFC 3261, June 2002
[5] J. Rosenberg and H. Schulzrinne, “Session Initiation
Protocol (SIP): Locating SIP Servers”, IETF RFC 3263, June
2002
[6] H. Schulzrinne, “Dynamic Host Configuration Protocol
(DHCP-for-IPv4) Option for Session Initiation Protocol (SIP)
Servers”, IETF RFC 3361, August 2002
[7] Rajeev Koodli and Charles Perkins, “Service Discovery in
On-Demand Ad Hoc Networks”, draft-koodli-manet-servicediscovery-00.txt, IETF Internet Draft, 2003
[8] David B. Johnson and David A. Maltz, Dynamic Source
Routing in ad hoc Wireless Networks, in Mobile Computing,
edited by Tomas Imielinski and Hank Korth, Chapter 5, pages
153-181, Kluwer Academic Publishers, ISBN: 0792396979,
1996
[9] E. Guttman et al. “Service Location Protocol, Version 2”,
IETF RFC 2608, June 1999
[10] M. Chandra, “Extensions to OSPF to Support Mobile Ad
Hoc Networking”, IETF Internet Draft, draft-chandra-ospfmanet-ext-00.txt, February 2004
[11] Liang Cheng, “Service Advertisement and Discovery in
Mobile Ad Hoc Networks”, Workshop on Ad hoc
Communications and Collaboration in Ubiquitous Computing
Environments, in conjunction with the ACM 2002 Conference
on Computer Supported Cooperative Work, New Orleans,
Louisiana, USA, November 16-20, 2002.
[12] C. Perkins, E. Belding-Royer and S. Das, “Ad hoc OnDemand Distance Vector (AODV) Routing”, IETF RFC 3561,
July 2003.
[13] F Zhu, M Mutka and L Ni, “PrudentExposure: A Private
and User-centric Service Discovery Protocol”, Proceedings of
the Second IEEE International Conference on Pervasive
Computing and Communications, PerCom’04, Orlando, Florida,
USA, March 2004
[147] S Helal, N Desai, V Verma and C Lee, “Konark – A
Service Discovery and Delivery Protocol for Ad-hoc
Networks”, Proceedings of the Third IEEE Conference on
Wireless Communication Networks (WCNC), New Orleans,
March 2003
[15] S. Czerwinski et al, “An Architecture for a Secure Service
Discovery Service”, Mobicom’99, Seattle, Washington, USA,
Sept 1999.
[16] Y. Ge, L. Lamont, L. Villasenor, "Improving Scalability of
Heterogenous Wireless Networks with Hierachical OLSR",
OLSR Workshop, San Diego, Aug 2004
[17] A. Iwata, C.-C. Chiang, G. Pei, M. Gerla, and T.-W. Chen,
"Scalable Routing Strategies for Ad Hoc Wireless Networks"
IEEE Journal on Selected Areas in Communications, Special
Issue on Ad-Hoc Networks, Aug. 1999, pp.1369-79
[18] K. Xu, and M. Gerla, “A Heterogeneous Routing Protocol
Based on a New Stable Clustering Scheme”, IEEE MILCOM
2002, Anaheim, CA, Oct. 2002
[19] M Joa-Ng and I.-T. Lu, "A Peer-to-Peer zone-based twolevel link state routing for mobile Ad Hoc Networks" IEEE
Journal on Selected Areas in Communications, Special Issue on
Ad-Hoc Networks, Aug. 1999, pp.1415-25.
[20] C.-C. Chiang, H. Wu, W. Liu and M. Gerla, "Routing in
Clustered Multihop, Mobile Wireless Networks with Fading
Channel" Proc. IEEE SICON'97, Apr.1997, pp.197-211
Proceedings of the 3rd Int’l Conf. on Pervasive Computing and Communications Workshops (PerCom 2005 Workshops)
0-7695-2300-5/05 $20.00 © 2005 IEEE