S e r v i c e D i S c o v e r y
A Survey of Service
Discovery Protocols
in Multihop Mobile
Ad Hoc Networks
Adnan Noor Mian, Roberto Baldoni, and Roberto Beraldi
University of Rome La Sapienza
An in-depth review of service discovery protocols (SDPs) in multihop
mobile ad hoc networks analyzes SDP building blocks and determines
SDP suitability based on architecture, mobility, and network size.
M
obile ad hoc networks (manets) include a variety of devices, such as cell phones, PDAs, laptops, and other relatively larger devices. These devices can move at high or low speeds or even remain stationary, entering and leaving the system when switched on or off. Such a variety of devices also offers a variety of services. A ser-vice is any tangible or intangible facility a deviceprovides that can be useful for any other device. Services comprise those for software and hardware. A software service, for example, can be a simple file, such as an MP3 file, or a software implementa-tion of an algorithm, such as converting one audio file format to another. A hardware service, for example, can be a printer that a mobile device can use wirelessly. To ben-efit from these services, a device must be able to both locate them in the network and invoke them. Service discovery protocols (SDPs) enable these capabilities.
SDPs play a role in wired networks, single-hop wireless networks, and multisingle-hop manets. In wired networks, the many industry standard SDPs include Sun’s Jini, Microsoft’s Universal
Plug and Play, IBM’s Salutation, and the Inter-net Engineering Task Force’s Service Location Protocol. In single-hop wireless networks, SDPs include DEAPSpace and the industry standard Bluetooth SDP. Wired networks have stationary devices, whereas single-hop wireless ad hoc net-works have restricted mobility with a low rate of devices joining and leaving.
This survey focuses on multihop manet SDPs, one of the many approaches to realizing per-vasive computing environments. In these net-works, devices can have unrestricted mobility— that is, no constraints on joining or leaving the network—making service discovery difficult. (SDPs for wireless sensor networks, such as the ZigBee standard SDP, are out of our work’s scope, because such SDPs focus on energy opti-mization rather than mobility.)
Most SDPs in wired networks work at the ap-plication level. In theory, any such apap-plication- application-level SDPs can work for manets as well. In prac-tice, however, mobility and resource scarcity introduce two dimensions that SDPs for wired or single-hop wireless networks don’t take into account: location awareness and physical prox-imity between the service provider and the user. Thus, physical proximity remains undetect-able. In multihop manets, the service provider and user’s physical proximity is a factor. Using
bandwidth efficiently and reducing link breakages requires services that are physically close and at fewer hops. The Open Systems Interconnection archi-tecture layering approach works well in wired networks without resource con-straints, but it introduces inefficiencies in resource-constrained manets. Cross-layering can improve efficiency, for ex-ample, in a specially designed SDP that integrates service discovery with rout-ing. Many proposals have focused on multihop manet SDPs, but none are as developed as those for wired or single-hop ad hoc networks.
Several comparative studies cover SDPs in all three types of networks, such as those by Chunglae Cho and Duckki Lee;1 Feng Zhu, Matt Mutka,
and Lionel Ni;2 and Raluca
Marin-Perianu, Pieter Hartel, and Hans Schol-ten.3 However, none closely analyzes
only SDPs for multihop manets. We selected 12 multihop manet SDPs,4–15
identified the basic building blocks of SDPs in general, and analyzed the se-lected SDPs in the context of these building blocks.
Service Discovery
Protocol Framework
Figure 1 shows the basic building blocks of a manet SDP framework: descrip-tion, registradescrip-tion, discovery (compris-ing search and selection), rout(compris-ing, and mobility support. We’ll explain each of these components in detail later in this section, but, first, we’ll provide an overview.
A user interacts with the SDP by first initiating service description, registra-tion, or discovery. (By “user,” we mean either an end user or a software appli-cation that acts on the end user’s be-half.) The service description describes the service in a format usable for reg-istration or search. A proper descrip-tion makes searching the service easier. After accessing the service description, the user can choose to search for the service or to register it. If the service is new, the user must register it—that is, store the service description in a
loca-tion—so that it’s available for later dis-covery. Once the service is registered, users can find it through discovery.
The user interacts with the discov-ery mechanism, specifying the service through service description and selec-tion criteria. The search component searches for the service and, when it finds all instances, the selection mech-anism chooses the most suitable ser-vice provider. The separation between search and selection mechanisms is often only logical. For example, if the user wants a printer service, the SDP first will search for all the printers and then select one according to some cri-teria. In this case, the search and selec-tion phases are independent. In other cases search and selection might occur simultaneously, meaning that search continues until the SDP finds a suit-able printer.
SDP can also form overlay networks. An overlay network, which sits on top of the existing network, is a virtual
network comprising a subset of nodes from the existing network and logical links between these nodes. The user se-lects the nodes to form a topology with special properties. A multihop proto-col creates links between these nodes. An overlay network directs traffic to specific nodes, thus greatly reducing network traffic. Registration and dis-covery mechanisms can use overlay net-works to help route the registration or search messages to selected nodes.
In manets, the network’s topology changes because nodes are mobile. If an SDP depends on a specific overlay topology, it must maintain the overlay, which might become faulty because of node mobility. So, to compensate for node mobility, the SDP includes a mo-bility support component.
Service Description
Service description is an abstraction of a service’s facilities and characteris-tics. A service requires a description to
Discovery Search Selection Registration
Local cache/all nodes Directory nodes
Algorithm Manual Mobility support Subset of nodes n-hop
(neighbor nodes or mulitcast group) XML DARPA Agent Markup Language Routing No routing Flooding Overlay routing Limited multicast
All nodes/local cache
Mobility support
Description
Periodically updating service information Reducing advertisement diameter Reducing advertisement time interval Maintaining overlay structure
Figure 1. Manet service discovery protocol framework. To compensate for node mobility, manet SDPs include a mobility support component.
Service DiScovery
enable other services or devices to use it. The nodes search for services only by looking at service descriptions the service provider advertises. A service without a proper description can re-main completely unknown to other network devices. Service description includes service properties (such as ser-vice ID), server properties (such as load on a service provider), and network properties (such as maximum number of hops from the current host to a ser-vice provider).
XML and its extensions, such as DARPA Agent Markup Language (DAML) and Web Ontology Language (OWL), are the most common service description approaches.5,7,15 The
de-scription is a plain text file that contains all of the service’s information. XML service description enables interopera-bility between different hardware and software platforms, but it also requires more resources for parsing. SDPs can also be independent of any description language, in which case, any language or description method will work.6,8,9,12
To achieve this independence, users will sometimes impose constraints on the specific language.8
registration
Registration includes information in-cluding where and how long to store the service description and the dis-tance and number of hops the informa-tion will travel according to the service provider.
SDPs manage service descriptions in different ways. Some SDPs store service descriptions only in the nodes’ local cache, in which case, the search must cover all nodes to find the service. Other SDPs store service descriptions on every node of the network—that
is, service advertisements flood the whole network. In this case, the service searches only the local cache. Another approach is to store service descrip-tions in a subset of nodes by distribut-ing advertisements to n hops5,14 (the
advertisement diameter) or distribut-ing advertisements to multicast groups of nodes.7 By restricting advertisement
flow, the protocols reduce memory re-quirements and increase the probability of discovering a service in the service provider’s vicinity. When service
de-scriptions are stored only in immediate neighbors, the advertisement diameter can be just one hop.6,15
SDPs can also store service descrip-tions in special selected nodes, called
directory nodes. A directory or direc-tory node is an entity that stores infor-mation about services available in the network, facilitating service discov-ery.1 The selection of such nodes
de-pends on specific protocols. In some SDPs, these are preassigned nodes.11
Whereas, in other protocols the direc-tory nodes might change according to network conditions. For example, nodes might form groups physically close to each other.8,13 Each group
selects a node, which keeps record of the services present in that group. For some of the mobile nodes, Ulas Kozat and Leandros Tassiulas’ SDP forms the virtual backbone containing service descriptions.10
Discovery
Discovery comprises search and selec-tion. These two mechanisms can be in-dependent or integrated. For example, an SDP might first search for all in-stances of a service provider and then se-lect a suitable service, or might perform the two functions simultaneously.
Search. The search mechanism is re-sponsible for searching services that have already been registered by the reg-istration mechanism. In networks that don’t have special directory nodes to keep service descriptions, search for a service depends on how the registration mechanism registered the services.
In SDPs that register services in the local cache, search takes place in all nodes by flooding the search message.4
This type of discovery is active search.12
In SDPs that register their services in all nodes, search takes place in only the lo-cal cache. This type of discovery is pas-sive search.6,12 Passive search is more
efficient in detecting changes in the en-vironment. With passive search, when a device receives an advertisement from a new device, it automatically knows a new node is in the vicinity offering services.6 With active search, however,
the SDP must send a search message. Active search does have the advantage, though, of generating less network traf-fic because the SDP sends the search message only when a node needs a service. Passive search generates more network traffic owing to the periodic advertisement distributions. An SDP can support both active and passive approaches.7,12
Another approach to search is selec-tively forwarding search requests. In this method, the SDP first searches a node’s local cache. If it doesn’t find a service, the node selectively forwards the request to other nodes on the basis of the ontology descriptions.15 When
a node doesn’t have enough informa-tion to selectively forward a request, it simply broadcasts the request to its neighboring nodes. The SDPs that se-lectively forward service requests scale well compared with SDPs using simple flooding.15 However, high mobility
might strain these protocols when they forward messages in regions where the service is no longer available because of node mobility.15
In networks that have directories for storing service descriptions, the service provider nodes advertise services only
Passive search is more efficient
than active search in detecting changes
to directory nodes. Depending on the protocol, these directory nodes might be preassigned the task of storing ser-vice descriptions,11 or the SDP might
select them at runtime.8 The clients
search only these directory nodes. For example in Service Rings, the protocol searches only the service rings’ service access point (SAP) nodes.8 In Kozat and
Tassiulas’10 and Jerry Tyan and Qusay
Mahmoud’s13 work, the client queries
only the virtual backbone nodes (VBNs) and each cell’s gateway, respectively. In Lanes, SDP nodes group together to form an overlay network that creates lanes of nodes.9 Each group is called a
lane, and nodes in the same lane have the same directory replicated in each node cache. So, search uses unicast on any of these directory nodes in a lane overlay instead of on one specific node.
Selection. The query request from a cli-ent node to the network can result in many responses from matching ser-vices. Selection from among the discov-ered services is then essential to invoke one of the services. Selection can be done manually by the user or automati-cally, using a criteria-based algorithm. The criteria can be the service
provid-er’s lowest hop count, current load, or velocity, or the available bandwidth of the communication channel between the service provider and the client.13
Search and selection are often in-tegrated. Alex Varshavsky, Bradley Reid, and Eyal de Lara demonstrated that proper integration improves over-all network performance by localizing network communication, thus reducing interference and allowing multiple con-current transmissions in different parts of the network.12 In Vincent Lenders,
Martin May, and Bernhard Plattner’s work, the client selects services using two metrics: the number of hops from the service provider and the service’s capacity.14 The service selection
algo-rithm is distributed and doesn’t involve direct interaction with the client.
Many manet SDPs simply ignore the selection issue.4–10,15
routing
The SDPs that register4 or search in
all of the network’s nodes flood query or registration messages. An SDP can scale well if the network traffic it gen-erates is limited. To limit network traffic, SDPs employ different rout-ing mechanisms. For example, SDPs
limit the flooding to n hops5 or use
multicast routing to specially formed groups of service providers,7 selective
forwarding based on ontology,5,15 or
selective forwarding based on the no-tion of potential.14
SDPs can also form overlay net-works and have specific routing mech-anisms within these overlay networks. For example, the Service Rings8
proto-col shown in Figure 2a forms an over-lay structure, called a service ring, by grouping nodes that are physically close and offer similar services. Each service ring has a designated SAP that keeps the directory and has informa-tion about available services in the service rings. The SAPs are connected with other service rings’ SAPs. When a node wants to search for a service, the query is routed through the ring struc-ture, passing through SAPs of other rings and reaching only those subrings that can possibly offer the service.
Kozat and Tassiulas’ SDP forms the virtual backbone for the VBNs, as Figure 2b shows.10 These VBNs
con-stitute a dominating set in which all of the network’s nodes are either in this set or only one hop away from at least one member of the set. The VBNs
(b) R1 R3 R4 2 n1 n5 n7 n8 n9 n3
Service access points
Rn Service rings
(a)
n10
Virtual backbone nodes
Ordinary nodes
Figure 2. Routing mechanisms. (a) The Service Rings protocol forms an overlay structure by grouping nodes that are physically close and offer similar services. (b) Kozat and Tassiulas’ SDP forms the virtual backbone nodes.
Service DiScovery
keep the directory, which stores the advertised information about other services in the network. The client for-wards the service request to the VBNs, which in turn multicast the query mes-sage to all the other VBNs. Multicast-ing the backbone nodes, rather than flooding all nodes in the network, re-duces the overhead of broadcasting a query. The arrows in Figure 2 indicate the routing path of query or registra-tion messages. Tyan and Mahmoud’s SDP divides the environment in hex-agonal cells, with each cell having a gateway node.13 Each cell’s gateway
node provides the directory services. When a client wants to search for a service, the query routes to only the gateway nodes. In Lanes,9 each node
in the lane has the same copy of the directory. The registration or search messages travel through lanes by any-cast routing.
Mobility Support
In manets, nodes frequently move and change their positions with respect to each other. In SDPs without directory nodes, all nodes keep information of only their own services. In such a case, the SDPs automatically handle mobility
by flooding to all nodes or multicasting query messages to a few nodes.4
Mobil-ity is a challenge for SDPs with direc-tory nodes.
One approach for handling mobil-ity is periodically updating service in-formation.7,11,14 When a service
pro-vider advertises its services, it also announces the timeout, or when the service information will expire. The mobile nodes cache this information. The service provider must reannounce the service information periodically. SDPs also use service rediscovery and
reselection to handle mobility. In re-discovery, SDPs probe the network for up-to-date information about the available service providers. In reselec-tion, the SDPs select services based on only the current entries in the service table.18 Another method for handling
mobility is reducing the advertisement diameter and advertisement time in-terval to compensate for the effects of rapidly changing vicinities.5,6,15
SDPs that form overlay networks have special algorithms for main-taining the overlay structure, which becomes faulty due to mobility and logging in and out of nodes from the network. Service rings8 have special
algorithms to maintain the ring over-lay’s consistency. Each ring member knows only its successor and it pre-decessor. The appropriate SAPs peri-odically initiate RingCheck messages. The messages circle through each ring to check its consistency. If a node doesn’t receive such a message in one of its rings for a given amount of time, it checks for link breakage or a parti-tion in the network. If the SAP detects either of these cases, it initiates an ap-propriate algorithm to repair the ring. Similarly Lanes9 and Kozat and
Tassi-ulas’s SDP10 use different algorithms
to maintain the lane structure and the dominating set feature of the virtual backbone. Tyan and Mahmoud’s SDP has two methods for supporting mobil-ity.13 The first approach is that when a
gateway node moves to another cell, it broadcasts the service information to nodes in its previous cell. These nodes elect another gateway node. The sec-ond method specifies a time-to-live parameter, which is the clock time after which a service must refresh its advertisement.
SDP Architectural views
Broadly speaking, architecture speci-fies a structure’s layout and how its major components connect. An archi-tectural view would thus be a specific perspective for looking at the SDPs.
Directory-based vs. Directory-less
In multihop manet SDPs, the architec-ture can be directory-based or direc-tory-less. In a directory-based archi-tecture, the user chooses certain nodes in a manet to be directory nodes. The registration and discovery mecha-nisms are specially tailored to access these nodes. For example, the Lanes,9
Splendor,11 Kozat and Tassiulas,10 and
Tyan and Mahmoud13 SDPs are all
directory-based.
Directory-less architecture has no directory nodes, as with SDPs by Li-ang Cheng and Ivan Marsic,4
Var-shavsky, Reid, and de Lara,12
Lend-ers, May, and Plattner,14 as well as
group-based distributed service dis-covery (GSD),5 Allia,6 Konark,7
Ser-vice Rings,8 and distributed service
discovery (DSD).15 The registration
and discovery mechanisms approach all of the network’s nodes or a subset. Manets often use the directory-less approach because it’s difficult to host a directory in mobile nodes that have scarce resources, such as memory and power, and whose availability isn’t guaranteed. A directory node should have vast resources and remain avail-able in the network for frequent con-tact with other nodes.
overlay-based vs. overlay-less
The overlay network in multihop ma-net SDPs has the advantage of being able to control the multicast of ser-vice query or advertisement messages. This controlled multicast restricts and greatly reduces the network traffic, as in SDPs by Kozat and Tassiulas,10
Tyan and Mahmoud,13 Allia,6 Service
Rings,8 and Lanes.9
In mobile environments, forming and maintaining overlay networks re-quires resource-constrained nodes to
a directory node should have vast resources
and remain available in the network for frequent
include those by Cheng and Mar-sic,4 Varshavsky, Reid, and de Lara,12
Lenders, May, and Plattner Splendor,11
GSD,5 Konark,7 and DSD.15 Directory and overlay
Rather than looking at SDPs in terms of directory or overlay, let’s look at a SDP in terms of directory and overlay. SDP architectures then fall into the follow-ing four categories:
directory-based with overlay support,8–10,13
directory-based without overlay support,11
directory-less with overlay support,6
and
directory-less without overlay support.4,5,7,12,14,15
Each of these categories suits different environmental conditions.
Protocol Suitability
Different dimensions help us under-stand SPD behavior—for example, network size, node mobility, and SPD behavior in a network with multiple service instances. Figure 3 shows SDP suitability for different network sizes and mobility conditions. Network size and mobility magnitudes are as follows:
Small network: up to 10 nodes. Medium network: 10 to 100 nodes. Large network: greater than 100 nodes.
Low mobility: up to 5 km per hour (such as in a building).
Medium mobility: 5 to 50 km per hour (such as a traffic scenario in a city).
High mobility: greater than 50 km per hour (such as highway traffic speeds).
The shaded region in Figure 3 shows the region in which all SDPs will work • • • • • • • • • •
well. Unshaded regions suit only par-ticular types of protocols.
Small networks and high mobility. Pro-tocols that are directory-less and don’t form overlay networks are suitable for small networks with high mobility. Such protocols use flooding for reg-istration and discovery mechanisms. Flooding has the negative side of gen-erating large overhead packets, making scalability an issue. Thus, SDPs that use flooding aren’t suitable for large net-works. Conversely, such protocols don’t form overlays or have directory nodes, so they don’t have the related overhead of maintaining the overlay structure and selecting directory nodes. These protocols perform well under high mo-bility—for example, the SDP by Cheng and Marsic4 shown in Figure 3. Medium networks and medium mobil-ity. Protocols that use limited flooding are well suited for medium size net-works with medium speeds of nodes. Examples include flooding limited by time-to-live constraints, multicast-ing to a group of nodes as in GSD,5
or flooding on top of an overlay
net-work as in SDP by Kozat and Tassiu-las to form VBNs.10 Limited flooding
improves mobility handling, and using overlay networks improves scalability. Figure 3 shows that SDPs that are direc-tory-based without overlay support or directory-less with overlay support are well suited for medium networks and medium mobility.
Large networks and low mobility. Over-lay networks provide an efficient rout-ing mechanism for searchrout-ing. Low mobility has no overlay maintenance issues, so SDPs that form overlay net-works, such as Service Rings8 and
Lanes,9 perform well in large
net-works. However, overlay maintenance becomes an issue under high mobility, and such protocols are unsuitable in high mobility scenarios. Figure 3 shows that the SDPs that are directory-based with overlay support are exclusively suited for this region.
Multiple service instances. If a network has many instances of the same service, SDPs that integrate search and selec-tion with routing protocols perform better than those with separate search,
Small Medium Large
Network size Mobility High Medium Low Directory-based with overlay support Cheng and Marsic’s SDP
(Flooding-based)
GSD Kozart SDP (Limited flooding) Directory-based without overlay support or
directory-less with overlay support
Lanes Service rings Any SDP can work
in this region
Figure 3. SDP suitability. SDP suitability varies based on network size, node mobility, and whether it has a directory or overlay network.
Service DiScovery
selection, and routing mechanisms. In such cases, the search success increases with the increase of service instances. Other advantages include reduced mes-sage overhead and less latency in search-ing the suitable services. Lenders, May, and Plattner’s field theoretic SDP, for example, is well suited for an environ-ment with multiple service instances.14
S
ervice discovery in mobile and pervasive environments is an important and active research field. (Table 1 summarizes our analysis.) Still, many challenges remain to be resolved before SDPs for multi-hop manets can be practical, for exam-ple, determining which type of overlaysuits manet environments under high mobility.
Often, developers build existing SDPs as standard applications with-out taking advantage of cross-layering optimizations. These SDPs don’t ex-ploit the wireless medium’s broadcast nature. We must look into new search techniques that exploit broadcast to become aware of network services by simply listening (eavesdropping) to the traffic other nodes generate.
Another ongoing challenge in ma-net SDPs is limiting ma-network traf-fic. Typical methods include limited flooding, multicasting, or overlays. A less explored approach is replicat-ing services. We must further explore this approach and tackle issues such as
service consistency, as well as number and placement of replications in the network.
Additionally, some peer-to-peer net-works use random walk for searching. Little research has gone into this ap-proach for search and discovery in manet SDPs. One critical aspect is reducing the number of hops, which random walk addresses with biasing mechanisms. Still an open question is finding an efficient biasing mechanism for wireless mobile environments.
Finally, different researchers often define their own metrics to measure performance of their proposed SDPs. It becomes impossible to realistically compare SDPs. We need standard per-formance metrics in this field.
TABLE 1
Service Discovery Protocol features.
Feature Cheng and Marsic SDP4 GSD SDP5 Allia SDP6 Konark SDP7 Service Rings8 Lanes9
Kozat and Tassiulas SDP10 Splendor SDP11 Varshavsky, Reid, and de Lara SDP12 Tyan and Mahmoud SDP13 Lenders, May, and Plattner SDP14 Distributed service discovery SDP15 Service discovery
architecture Directory-less with-out overlay support Directory-less with-out overlay support Directory-less with overlay support Directory-less without overlay support Directory-based with overlay support Directory-based with overlay support Directory-based with overlay support Directory-based without overlay support Directory-less without overlay support Directory-based with overlay support Directory-less without overlay support Directory-less without overlay support management of
service information Stores information of local services and multicast ser-vice advertisements multicast service advertisements to n hops Broadcast service advertisements to 1 hop (immediate neighbors) multicast service
advertisements Service information stored in service rings’ service access point nodes nodes in a lane have replicated directory Service informa-tion stored in virtual back-bone nodes Service infor-mation stored in preassigned directory nodes Service infor-mation is stored on each node Gateway node keeps track of services in a group multicast service advertisements to n hops Broadcast service advertisements to 1 hop with selec-tive forwarding Search methods multicast query
request to a multi-cast group
Query request selec-tively forwarded based on semantic information
Query request first multicast to alliance member, then to other alliances
multicast query
request Service access points anycast query request to lanes Query request flooded only to virtual back-bone nodes
Query directory
nodes multicasting query request Query only gateway nodes Query routed to neighbors with higher potential Query selectively forwarded based on ontology descriptions Service selection
methods not specified not specified not specified not specified not specified not specified not specified Selection done at client side (no further detail given) Selection based on lowest hop count Selection done by mobile agents using context infor-mation Distributed selection based on network dis-tance and capac-ity of service
not specified
mobility support
methods multicast service advertisements adjust service adver-tisement diameter and rate
adjust advertise-ment rate and alli-ance diameter Specify lifespan of service adver-tisements and periodical adver-tisements
repair service rings damaged due to mobility
Lane structure
maintenance maintenance of virtual backbones’ dominating set feature Specify lifes-pan of service advertisements and periodical advertisements rediscover and reselect from available service providers Elect new gateway node and periodical advertisements Periodical
adver-tisements adjust advertise-ment diameter and rate
Service description
methods not specified DarPa agent mark-up Language (DamL) Independent of description language
Extensible mark-up Language (XmL)
any language that describes and sum-marizes functions
Independent of description language
not specified not specified Independent of description language
XmL not specified Web Ontology Language (OWL)
AcKnowLEDgMEnTS
The Italian ministry of Education, university, and research (under the IS-manet project) and the resilience for Survivability in IST network of Excellence program (European commission con-tract no. 026764) supported this project.
REFEREncES
1. C. Cho and D. Lee, “Survey of Service Discovery Architectures for Mobile Ad hoc Networks,” term paper, Mobile Computing, CEN 5531, Dept. Com-puter and Information Science and Eng., Univ. Florida, Fall, 2005; http://folk. uio.no/paalee/referencing_publications/ ref-sd-cho-cice05.pdf.
2. F. Zhu, M.W. Mutka, and L.M. Ni, “Ser-vice Discovery in Pervasive Computing Environments,” IEEE Pervasive Com-puting, vol. 4, no. 4, 2005, pp. 81–90.
3. R. Marin-Perianu, P. Hartel, and H. Scholten, A Classification of Service Dis-covery Protocols, internal report, Dept. Electrical Eng., Mathematics, and Com-puter Science, Univ. of Twente, Nether-lands, June 2005; http://eprints.eemcs. utwente.nl/735/01/0000012d.pdf. 4. L. Cheng and I. Marsic, “Service
Dis-covery and Invocation for Mobile Ad Hoc Networked Appliances,” Proc. 2nd Int’l Workshop Networked Appliances (IWNA 00), Dec. 2000; www.cse.lehigh. edu/~cheng/papers/IWNA-MANET. pdf.
5. D. Chakraborty et al., “GSD: A Novel Group-Based Service Discovery Proto-col for Manets,” Proc. 4th IEEE Conf. Mobile and Wireless Communications Networks (MWCN 02), IEEE Press, 2002, pp. 140–144.
6. O. Ratsimor et al., “Allia: Alliance-Based Service Discovery for Ad Hoc
Environ-ments,” Proc. 2nd Int’l Workshop Mobile Commerce (WMC 02), ACM Press, 2002, pp. 1–9.
7. S. Helal et al., “Konark: A Service Dis-covery and Delivery Protocol for Ad Hoc Networks,” Wireless Comm. and Net-working, vol. 3, 2003, pp. 2107–2113. 8. M. Klein, B. Konig-Ries, and P. Obreiter,
“Service Rings: A Semantic Overlay for Service Discovery in Ad Hoc Networks,” Proc. 14th Int’l Conf. Database and Expert Systems Applications (DEXA 03), IEEE CS Press, 2003, pp. 180–185. 9. M. Klein, B. Konig-Ries, and P. Obreiter,
“Lanes: A Lightweight Overlay for Service Discovery in Mobile Ad Hoc Networks,” 3rd Workshop Applications and Services in Wireless Networks (ASWN 03), July 2003; http://hnsp.inf-bb.uni-jena.de/ DIANE/docs/ASWN2003.pdf.
10. U. Kozat and L. Tassiulas, “Network
Feature Cheng and Marsic SDP4 GSD SDP5 Allia SDP6 Konark SDP7 Service Rings8 Lanes9
Kozat and Tassiulas SDP10 Splendor SDP11 Varshavsky, Reid, and de Lara SDP12 Tyan and Mahmoud SDP13 May, and Plattner SDP14 service discovery SDP15 Service discovery
architecture Directory-less with-out overlay support Directory-less with-out overlay support Directory-less with overlay support Directory-less without overlay support Directory-based with overlay support Directory-based with overlay support Directory-based with overlay support Directory-based without overlay support Directory-less without overlay support Directory-based with overlay support Directory-less without overlay support Directory-less without overlay support management of
service information Stores information of local services and multicast ser-vice advertisements multicast service advertisements to n hops Broadcast service advertisements to 1 hop (immediate neighbors) multicast service
advertisements Service information stored in service rings’ service access point nodes nodes in a lane have replicated directory Service informa-tion stored in virtual back-bone nodes Service infor-mation stored in preassigned directory nodes Service infor-mation is stored on each node Gateway node keeps track of services in a group multicast service advertisements to n hops Broadcast service advertisements to 1 hop with selec-tive forwarding Search methods multicast query
request to a multi-cast group
Query request selec-tively forwarded based on semantic information
Query request first multicast to alliance member, then to other alliances
multicast query
request Service access points anycast query request to lanes Query request flooded only to virtual back-bone nodes
Query directory
nodes multicasting query request Query only gateway nodes Query routed to neighbors with higher potential Query selectively forwarded based on ontology descriptions Service selection
methods not specified not specified not specified not specified not specified not specified not specified Selection done at client side (no further detail given) Selection based on lowest hop count Selection done by mobile agents using context infor-mation Distributed selection based on network dis-tance and capac-ity of service
not specified
mobility support
methods multicast service advertisements adjust service adver-tisement diameter and rate
adjust advertise-ment rate and alli-ance diameter Specify lifespan of service adver-tisements and periodical adver-tisements
repair service rings damaged due to mobility
Lane structure
maintenance maintenance of virtual backbones’ dominating set feature Specify lifes-pan of service advertisements and periodical advertisements rediscover and reselect from available service providers Elect new gateway node and periodical advertisements Periodical
adver-tisements adjust advertise-ment diameter and rate
Service description
methods not specified DarPa agent mark-up Language (DamL) Independent of description language
Extensible mark-up Language (XmL)
any language that describes and sum-marizes functions
Independent of description language
not specified not specified Independent of description language
XmL not specified Web Ontology Language (OWL)
Service DiScovery
Layer Support for Service Discovery in Mobile Ad Hoc Networks,” Proc. IEEE Conf. Computer Comm. (INFOCOM 03), IEEE Press, 2003, pp. 1965–1975. 11. F. Zhu, M. Mutka, and L. Splendor, “A
Secure, Private and Location-Aware Service Discovery Protocol Supporting Mobile Services,” Proc. 1st Int’l Conf. Pervasive Computing and Comm. (Per-Com 03), ACM Press, 2003, pp. 235– 242.
12. A. Varshavsky, B. Reid, and E. de Lara, “A Cross Layer Approach to Service Discov-ery and Selection in Manets,” Proc. 2nd Int’l Conf. Mobile Ad-Hoc and Sensor Systems (MASS 05), IEEE Press, 2005, doi:10.1109/MAHSS.2005.1542832. 13. J. Tyan and Q. Mahmoud, “A Network
Layer Based Architecture for Service Dis-covery in Mobile Ad Hoc Networks,” Proc. 17th Ann. IEEE Canadian Conf. Electrical and Computer Eng. (CCECE 04), IEEE Press, vol. 3, May 2004, pp. 1379–1384.
14. V. Lenders, M. May, and B. Plattner, “Service Discovery in Mobile Ad Hoc Networks: A Field Theoretic Approach,” Proc. 6th IEEE Int’l Symp. World of Wireless Mobile and Multimedia Net-works (WoWMoM 05), IEEE Press, vol. 1, 2005, pp. 120–130.
15. D. Chakraborty et al., “Toward Dis-tributed Service Discovery in Pervasive Computing Environments,” IEEE Trans. Mobile Computing, vol. 5, no. 2, 2006, pp. 97–112.
For more information on this or any other com-puting topic, please visit our Digital Library at www.computer.org/csdl.
the
AuThoRS
Adnan Noor Mian is a PhD candidate in the computer Science and Systems Department at the university of rome La Sapienza. his research interests in-clude pervasive computing, ad hoc and sensor networks, and distributed algo-rithms. he has a master’s degree in physics from Government college Lahore Pakistan and a master’s degree in computer science from Punjab university Pakistan. contact him at adnan@dis.uniroma1.it.
Roberto Baldoni is professor of distributed systems at the university of rome La Sapienza, project coordinator of Sm4aLL (an Eu project on networked em-bedded systems for Domotics), and technical codirector of comiFin (an Eu project on financial infrastructure protection). his research interests include distributed, pervasive, peer-to-peer computing, and middleware platforms. he has a PhD in computer science from university of rome La Sapienza. con-tact him at roberto.baldoni@dis.uniroma1.it
Roberto Beraldi is an assistant professor in the computer Science and Sys-tems Department at the university of rome La Sapienza. his research interests include distributed systems and dynamic networks. he has a PhD in computer science from the university of calabria, Italy. contact him at roberto.beraldi@ dis.uniroma1.it.
Next Board Meeting: 6 Feb. 2009, Los Angeles, CA, USA
EXECUTIVE COMMITTEE
President: Susan K. (Kathy) Land, CSDP* President-Elect: James D. Isaak;* Past President:
Rangachar Kasturi;* Secretary: David A. Grier;* VP, Chapters Activities: Sattupathu V. Sankaran;† VP, Educational Activities: Alan Clements (2nd VP);* VP, Publications: Sorel Reisman;† VP, Standards Activities: John Harauz;† VP, Technical & Conference Activities: John W. Walz (1st VP);* Treasurer: Donald F. Shafer;† 2008–2009 IEEE Division V Director: Deborah M. Cooper;† 2009–2010 IEEE Division VIII Director: Stephen L. Diamond;† 2009 IEEE Division V Director-Elect: Michael R. Williams;†Computer
Editor in Chief: Carl K. Chang†
*voting member, †nonvoting member of the Board of Governors
BOARD OF GOVERNORS
Term Expiring 2009: Van L. Eden; Robert Dupuis; Frank E. Ferrante; Roger U. Fujii; Ann Q. Gates, CSDP; Juan E. Gilbert; Don F. Shafer
Term Expiring 2010: André Ivanov; Phillip A. Laplante; Itaru Mimura; Jon G. Rokne; Christina M. Schober; Ann E.K. Sobel; Jeffrey M. Voas
Term Expiring 2011: Elisa Bertino, George V. Cybenko, Ann DeMarle, David S. Ebert, David A. Grier, Hironori Kasahara, Steven L. Tanimoto
EXECUTIVE STAFF
Executive Director: Angela R. Burgess; Director, Business & Product Development: Ann Vu; Director, Finance & Accounting: John Miller;
Director, Governance, & Associate Executive Director: Anne Marie Kelly; Director, Membership Development: Violet S. Doan; Director, Products & Services: Evan Butterfield; Director, Sales & Marketing: Dick Price
COMPUTER SOCIETY OFFICES
Washington, D.C.: 2001 L St., Ste. 700, Washington, D.C. 20036; Phone: +1 202 371 0101; Fax: +1 202 728 9614;Email: hq.ofc@computer.org
Los Alamitos: 10662 Los Vaqueros Circle, Los Alamitos, CA 90720-1314; Phone: +1 714 821 8380; Email: help@computer.org
Membership & Publication Orders:
Phone: +1 800 272 6657; Fax: +1 714 821 4641;Email: help@computer.org
Asia/Pacific: Watanabe Building, 1-4-2 Minami-Aoyama, Minato-ku, Tokyo 107-0062, Japan Phone: +81 3 3408 3118; Fax: +81 3 3408 3553 Email: tokyo.ofc@computer.org
IEEE OFFICERS
President: John R. Vig; President-Elect: Pedro A. Ray; Past President: Lewis M. Terman; Secretary: Barry L. Shoop; Treasurer: Peter W. Staecker; VP, Educational Activities: Teofilo Ramos; VP, Publication Services & Products: Jon G. Rokne; VP, Membership & Geographic Activities: Joseph V. Lillie; President, Standards Association Board of Governors: W. Charlton Adams; VP, Technical Activities: Harold L. Flescher; IEEE Division V Director: Deborah M. Cooper; IEEE Division VIII Director: Stephen L. Diamond; President, IEEE-USA: Gordon W. Day
revised 15 Dec. 2008
PURPOSE: The IEEE Computer Society is the world’s largest association of computing professionals and is the leading provider of technical information in the field. Visit our Web site at www.computer.org
