A Middleware Architecture for Inter ad-hoc networks Communication

(1)

A Middleware Architecture for Inter ad-hoc networks Communication

^∗

Mauro Patini, Roberto Beraldi, Carlo Marchetti, Roberto Baldoni Dipartimento di Informatica e Sistemistica

Universit`a di Roma “La Sapienza”

Via Salaria 113, 00198 Roma, Italia.

{patini,beraldi,marchet,baldoni}@dis.uniroma1.it

Abstract

Complex and decentralized Information Systems need advanced communication services at the middleware level in order to leverage context-aware distributed applications working, for example, despite node mobility and in a setting where such services can be billed. In this paper we present a middleware architecture offering a communication service which, in its more general case, is able to provide connectiv- ity between two nodes belonging to distinct mobile ad-hoc networks by taking user profiling into account. The pro- posed architecture is based on a resource awareness ser- vice enabling dynamic resource discovery and composition despite the assumed heterogeneity of the ad-hoc networks building the system.

1 Introduction

Accessing information in a context aware way by mobile users is one of the big challenges when building complex information systems. This passes through the design of a flexible and adaptable communication service which is capable to exploit (possibly in an optimal way) all possible resources a node is connected to. As an example, let assume an ad-hoc meeting where a few notebooks are equipped with a GPRS modem. If Mark wants to browse the Internet without having an internal GPRS connection, it could use one of the available modems within the ad- hoc network. These modems could be connected to distinct telco providers each one with its own fare per Megabit.

Therefore Mark could choose, for example, the modem with either the lowest fare or the highest bandwidth or the one connected to his own telco provider, tailoring thus resource usage in an optimal way according to his preferences. Let us remark that such interprocess communication can not be

∗This research has been partially supported by the Italian Ministry of University and Research under the projects CNR IS-MANET and FIRB MAIS.

achieved only by using classical internetworking techniques (although they are welcome to simplify the overall problem) as the establishing of such communications is based on the existence of a collection of resource description that are at a higher abstraction level than, for example, IP routing or TCP connections. Therefore, a solution to such problem encompasses high level resource sharing (including the as- sociated user resource sharing policies), user preferences, orchestration of such resources as well as internetworking issues.

In this paper we propose a middleware architecture based on resource awareness services. In this architecture, nodes exports descriptions of the resources they intend to share along with policies regulating shared resource usage. Re- source awareness services are then used to build a communication service which is able to support computations in which a node n wants to send a message m to a node nlocated in a distinct ad-hoc network. A Mobile Ad-hoc NET- work (MANET), and a peer-to-peer network are examples of ad-hoc networks. The former includes a dynamic set of mobile nodes while the latter is formed by a dynamic set of nodes connected through TCP wired connections and sharing a common interest over the Internet. We assume distinct ad-hoc network to implement heterogeneous resource awareness services. Therefore, to cope with such an heterogeneity, we propose the building of repositories containing (and allowing the lookup of) all the software and hardware resources shared at a given time, for example, in a MANET (e.g. processors, battery level alarms, GPRS, GSM, WiFi, storage capability, printers, software applications). The basic idea is that, exploiting resource awareness, the communication service composes resources local to the ad-hoc net- work of n and finds resources crossing intermediate ad-hoc networks, enabling in this way the communication between n and n. Let us note that each node is free to decide which internal resources to export and when and how they can be used (user resource sharing policy). This could include also billing policies. For example, on one hand, Mark cannot be happy if his GPRS is used by someone else. In this case

(2)

Mark does not export its GPRS. On the other hand, Mark could charge Mary for using his GPRS to communicate outside the MANET.

This paper first presents (Section 2) the eXtended ad-hoc (X-hoc) model, consisting of a collection of ad-hoc networks. Each ad-hoc network is formed by a set of nodes where each pair of these nodes is able to communicate and there could be gateways in each network able to reach other networks. Section 3 introduces the proposed middleware architecture that enables two nodes in two distinct ad-hoc networks to communicate exploiting resource awareness services. Related work is discussed in Section 4, while Section 5 presents some concluding remarks.

2 X-hoc network model

The basic building block of the X-hoc network model are ad-hoc networks. Broadly speaking, an ad-hoc network is composed by a set of nodes that interconnect to purse some common objectives. Cooperation is achieved through message exchange over communication channels. Examples of ad-hoc networks are Mobile ad-hoc Networks (MANETs)¹ as well as peer-to-peer systems². The idea underlying the X-hoc network model is to consider a set of heterogeneous ad-hoc networks, in which some nodes need to communicate with other nodes located out of the boundaries of the ad-hoc network they are located in. Therefore, we consider a set of ad-hoc networks, each having a unique identifier AN_i³. The set of ad-hoc networks is heterogeneous as each ad-hoc network may adopt an underlying communication infrastructure that differ from those of other networks, e.g.

IP, overlay networks. Further, we assume each ad-hoc network to adopt a possibly distinct service discovery mecha- nism, e.g. Jini [17], UPnP [22], Salutation [4], Service Lo- cation Protocol [8], Chord [10], Multi-layer Clusters [12].

Figure 1 illustrates an X-hoc network formed by five ad- hoc networks AN₁, AN₂, AN₃, AN₄ plus an ad-hoc network formed by the group of the gateways which enables inter ad-hoc communication. The set of ad-hoc networks is dynamic, i.e. novel ad-hoc networks can spontaneously

1A Mobile Ad hoc Network (MANET) is a set of wireless nodes which are able to communicate and move at the same time, without the support of any centralized administration or wired infrastructure. Direct communication between two nodes of a MANET can only take place when the Euclidian distance between the nodes is lower than the transmission radius R, e.g. 250 m. Typically, such a distance is lower than the total network diameter and thus nodes have to cooperate in order to forward messages towards an arbitrary destination. Cooperation is accomplished by a routing protocol [11].

2Peer refers to a class of systems and applications that employ distributed resources to perform a function in a decentralized manner. A peer- to-peer network allows the sharing of computer resources and services by direct exchange between systems [18].

3Several standards enable unique identification and addressing of nodes and possibly of networks, i.e. [19, 9, 20] etc.

AN₁ {UPnP}

AN₄ {Chord}

AN₃ {SLP}

AN₂ {Jini}

g_1,1=n_1,5 g_1,2=n_1,9 g_2,1

g_3,1

g_4,1

n_1,7 n_1,4

n_1,8

n_1,3

n_1,6 n_1,1

n_1,2

Figure 1. An X-Hoc network including five ad- hoc networks

appear and “old” networks can disappear, with no possible control. This is the typical case of MANETs where due to mobility a node can disappear from a MANET and either join another MANET or create a new MANET which includes only itself. Therefore, nodes are not tightly bound to networks: a single node can spawn multiple ad-hoc networks at a given time and it is also allowed to move across several networks during the time. The first case is, for example, the one of a laptop that uses WiFi to connect to neighbor wireless devices while exploiting a cellular network channel (e.g., GPRS, UMTS) to establish an Inter- net connection. An example for the second case is a wireless Bluetooth device that traverses distinct environments (e.g. rooms) each served by a distinct piconet or scatter- net⁴. However, each node belongs to at least one ad-hoc network (possibly composed by the only node itself) at any given time.

In this paper we concentrate on inter-ad-hoc communication, therefore, in an X-hoc network, nodes can be either normal nodes or gateway nodes. A normal node is only able to communicate with members of the ad-hoc network it belongs to (e.g. a laptop equipped with a PCMCIA card for wireless communications based on 802.11b). A gateway node is a node extended with resources enabling communications with nodes located outside of its ad-hoc network.

Examples of such technologies are: a Smartphone embed- ding both a Bluetooth interface and a GPRS modem and a laptop equipped with WiFi plus a satellite transmitter.

Clearly, simply considering a compound of ad-hoc net-

4Piconets and scatternets are different models of small-scale wireless networks. Indeed, the main and common characteristic of these network models is that they are restricted in terms of both the physical area they cover (e.g., a room) and the number of device (usually, less of ten).

(3)

works is not sufficient to characterize and implement the X- hoc model objectives, i.e., enabling communications across distinct ad-hoc nets. Indeed, most ad-hoc networks are usually designed considering only the internal communication objectives of nodes and thus no additional services enabling communications among nodes belonging to distinct nets are considered. Further, services designed for a given ad- hoc are commonly non-interoperable with services implementing analogous functionalities but designed for running within different environments/infrastructures, i.e. within different ad-hoc networks. As an example, Jini and UPnP do not interoperate.

However, given both the current and expected widespread of wireless technologies and ad-hoc networks, it is fairly easy to devise cases in which two nodes, say n₁ belonging to AN₁ and n₂belonging to AN₂ want to communicate. Furthermore, an increasing number of devices (e.g. PDAs, SmartPhones etc) is released equipped with distinct wireless technologies, e.g. 802.11b, Blue- tooth, GSM/GPRS, which can be mapped into gateway nodes according to the X-hoc models. Therefore in the next section we devise a novel middleware architecture, based on resource awareness⁵, for implementing the X-hoc model, described below.

3 A Middeleware Architecture for imple- menting X-hoc

In this section we first give an overview of the services deemed necessary to support the X-hoc network model.

Then we outline the functional middleware architecture implementing these services within a generic X-hoc node. Fi- nally, we describe the dynamic behavior of the proposed architecture upon the sending of a message between two nodes belonging to distinct ad-hoc networks.

3.1 Overview of the X-hoc support services: Re- source Repository and X-hoc Repository The objective of the middleware architecture presented throughout this section is to exploit resource awareness in order to implement the abstraction depicted in Figure 2, starting from the initial model of Figure 1. In this figure, each ad-hoc network AN_i is augmented with a Resource Repository RR_ithat contains a set of records, one for each resource exported by a user (i.e., a resource a user wants to share with the other members of its ad-hoc network). Each record contains (i) the identifier of the resource, (ii) the type of the resource (e.g., printer, modem, battery etc.) and (iii) a set of attributes detailing the technical aspects of the resource (e.g. bps in the case of modem, resolution and pages

5Resource awareness encompasses resource discovery and resource sharing.

per minute for printers). Further, the generic RR_icontains for each exported resource the policies for they usage, as defined by users (e.g. cost, admitted users etc).

AN₁

AN₄ AN₃

AN2

RR₃

RR₄

RR₁ RR₂

n XR n'

g g'

Figure 2. Support Services for an X-hoc net- work

Hence, without loss of generality, we assume that each resource repository RR_i can be queried by any node be- longing to AN_i and is updated each time a new node joins the network. In particular, a node n joining the network AN_i registers within RR_i the resources it intends to share with other nodes and the policies regulating their usage.

Then n can query RR_i according to a set of standard resource types, obtaining as result all the resources of that type whose policies match the local user preferences.

To establish an X-hoc communication between n and n requires in the general case two basic steps:

1. locate a gateway (if any) within the n’s ad-hoc network matching n’s user preferences;

2. locate a gateway (if any) within the n’s ad-hoc net- work matching n’s user preferences.

While step 1 can be addressed through querying RR of n, step 2 requires the cooperation between RR of n and a new service, denoted X-hoc repository (XR), which con- tains a set of records, one for each gateway. Each record contains (i) the identifier of the gateway, say g, (ii) g’s poli- cies and (iii) a set nodes seen by g in its ad-hoc network (this set can be retrieved by g using its local RR). XR can be queried and accessed by gateways.

More specifically, when a node n belonging to AN_i wants to send a message m to nbelonging to AN_j(i= j), n first retrieves the set of records corresponding to the avail- able gateways at AN_iby querying RR_i (with an approxi- mation that depends on RR_i implementation). Then n se- lects a gateway (if any) g local to AN_i, by matching n’s user preferences (e.g. cost, urgency) against the sharing policy of each available gateway which is described in the record.

Once g has been selected, the latter queries XR to know the

(4)

list of gateways connected to nmatching the n preferences (if any). In this list n selects one gateway gand the mes- sage can start to be transferred from n to n. Figure 2 shows the logical path between n and npassing through g and g. Let us conclude this section by noting that the proposed support services to implement an X-Hoc are based on repos- itories RRs (resp. XR) that nodes (resp. gateways) can lookup. Due to the dynamic nature of the ad-hoc networks building the X-Hoc, these repositories need to be updated.

The update policy (e.g. proactive vs. reactive, update fre- quency etc.) of these services mainly depends on the implementation strategy of the repositories (e.g. centralized vs. distributed), which in turn depends on the technology of the ad-hoc network (e.g. wired overlay vs. MANET), which is out of the scope of this paper. However, we remark that tracking the exact composition of a dynamic network in terms of available resource can be a very difficult task [3], and thus these services have to be considered as abstractions whose implementation and precision⁶has to be evaluated on a case-by-case basis (see also Section 4).

3.2 Node Architecture

In order to implement the services on which an X-hoc network is based on, i.e. RR and XR, we propose the node’s functional architecture illustrated in Figure 3. The figure illustrates a gateway node. A normal node does not include the gateway service. The architecture lays on top of the basic communication infrastructure composed by a service discovery protocol and by a network infrastructure.

The service discovery protocol and the communication protocol may vary from ad-hoc network to ad-hoc network.

Therefore the architecture introduces two additional layers.

The first layer is used to abstract out the specific peculiari- ties of the heterogeneous service discovery protocols. It is composed by the Resource Awareness (RA) Services and by the Profile Information enabling the implementation of RR.

Further services in the X-hoc layer enable communications among nodes located in distinct ad-hoc networks.

The remainder of this section outlines the functionality embedded within layers in each node n of an X-hoc, while the following section describes how the middleware acts upon an application invoking its functionality.

Profile Information. Each node n stores (i) the policies defining access rules for the use by external users of each shared local resource, and (ii) their preferences, i.e. criteria for the exploiting of resources shared by other nodes.

In particular, the policy database stores a record for each resource contained in the local resources database (see be-

6In general, due to the dynamic and distributed nature of the ad-hoc networks, it is likely that the repositories at timet will store an approximation of the resources available at that time within the ad-hoc network.

X R

X-hoc services

R A services

local resources nodes

lookup

find

resources preferences

policies Profile Information Application

Comm

Gateway

matching

send deliver

export check node / gateways

Inter Ad-hoc middleware

R R

N E T W O R K Jini UPnP SLP Chord Service

Discovery

Figure 3. The proposed architecture

low), that describes (at least) the set of nodes allowed to use the resource (possibly all) and the costs for the resource use.

Costs can be expressed both has a fixed fare for accessing the resource once, always, as well as an amount of money to be paid for a given unit of usage (time, Kb).

The preferences database can contain information de- scribing preferred resources in terms of costs and perfor- mance. Users and applications can store there maximum costs and minimum performances for a resource type they are looking for (e.g. maximum 1$ per minute for a 50KBps modem, 2$ per page for a printer with a 600x600dpi resolution).

Resource Awareness services. The previous databases mainly express rules that regulate the sharing and the use of resources, while RA services basically enable resource sharing and discovery (i.e. resource awareness). At the functional level, the main primitive provided by this mod- ule is find resources, which given as input a resource type (if any) returns all the resources of the selected type avail- able within the same ad-hoc of node n that match user pref- erences according to their policies and technical attributes.

To implement this primitive, each node exports a descrip- tion of each resource it is going to share within the local resource database. Therefore the information logically con- tained within the RR of an ad-hoc network AN_ican be ob- tained from the union of the records of all the local resource and policies databases maintained by each node of AN_i. At a high level of abstraction, the find resource primitive thus queries all the local resource databases of the n’s ad-hoc

(5)

network by selecting the resources whose type, policies and technical attributes match the requested type and the user preferences. The primitive nodes lookup is a specialization of the former, returning the list of nodes of the ad-hoc (both normal nodes and gateways).

X-hoc services. This layer contains a communication (Comm) service and the actual gateway service implemen- tation. The gateway service enables communications out of the boundaries of the ad-hoc in which n resides. Basically, exploiting the underlying enabling gateway technologies, it acts as a forwarder (i) of messages coming from gateways of other ad-hoc networks and addressed to nodes within the ad-hoc network in which the gateway is located, as well as (ii) of messages coming from nodes within its network and addressed to nodes external to the latter. Moreover, the gateway uses the nodes lookup service of the underlying layer to notify the nodes it is able to reach to an implemen- tation of XR⁷. The Comm service exports API towards the application and controls the sequence of operations necessary to establish X-hoc communications as detailed in the following section. Let us remark that a normal node imple- ments all components but the gateway module.

3.3 Behavior Detail

The sequence diagram of figure 4 shows the main steps carries out to transmit a message m from n∈ ANito n ∈ AN_j exploiting the architecture described in the previous section. In this figure, dotted lines represent gateway-to- gateway communications, while normal lines intra ad-hoc communications. In the following, we describe the main phases of this interaction:

• destination node and local gateway lookup: when the application invokes the send m to nprimitive of the Comm service, the latter first checks (check node) if n∈ AN_jis located in AN_iby querying RA services. In this scenario, we assume that n and nare located in distinct ad-hoc networks (i.e. i = j) as in Figure2. In this case the Comm service further queries RA services (Check local gateways) to locate a reachable gateway within its ad-hoc network. This operation returns a list of gateways that match user preferences (Local gateways list).

• remote gateway lookup: provided that the list of gate- ways matching user preferences is not empty, the Comm service selects a local gateway g and contacts the latter to search a remote gateway to n(i.e. a gate- way node belonging to AN_j). In particular, n passes to the g the destination node identifier and the source

7Details on theXR implementations are out of the scope of this paper.

node preferences (Search n,pref erences). Then g first retrieves from XR a list of remote gateways (Search n), and then selects those elements that matches user preferences, returning them to n.

• inter ad-hoc communication: if multiple remote gate- ways are returned to n, the Comm service selects a remote gateway⁸. Then m is relayed to g, which is in charge of message transmission to g. However, before sending the message to g, the local gateway g checks if the information about the location of n retrieved from XR is still correct (Search n). This step has been inserted as the information contained in XR could be obsolete when the gateway-to-gateway communication is established, due to the dynamic char- acteristics of the networks building the X-hoc, other than to the way in which the XR abstraction is im- plemented. Thus, upon receiving m from n, g first checks for nin AN_j(check node n) by invoking directly g. Assuming that n is still in AN_j (n is here), the local gateway sends the message to the re- mote gateway g (send m) that relays m to the n Comm service. This service waits for the arrival of the entire message and then (i) delivers the message to the application layer (deliver), and (ii) generates an ACK message that travels back to n.

The proposed scenario is based on several assumptions ensuring the successful completion of the send operation.

However, several events could hinder the primitive to com- plete successfully. As examples, the matching operation re- quired for checking local gateways fails if no local gateways are available or user preferences are too stringent with re- spect to the policies of the current available gateways (point 1 in Figure 4). Similar considerations hold for the matching operation invoked to retrieve remote gateways (point 2). Fi- nally, message sending can not take place if the destination node does no longer belong to the ad-hoc network returned by XR to the local gateway (point 3), e.g. the node moved away from the previous network and XR is not yet updated.

In this cases, specific actions must be put in place by the infrastructure, e.g. notifying users about the temporary un- reachability of some destination node.

4 Related Work

First of all we remark that, at a high level of abstraction, several existing systems and research proposals already embed or are based on ideas of the X-hoc model and of the presented architecture. Relevant examples are the Internet, the cellular phone architecture and publish/subscribe systems,

8In the case of multiple gateways matching user preferences, we let the selection of both the local and remote gateways to occur onn in order to allow querying the user by the Comm service.

(6)

SEND(m) to n' Application

Check node n'

Node n' not in ANi

Check local gateways

Local gateways list Select a

local gateway

g Search n', preferences

Comm R A

services

g Search n'

X R

Remote gateways Remote gateways list list

Select a remote gateway

g' send (m, g')

gateway

Search n'

n' is here

send (m)

Comm

ACK ACK ACK

Message successfully

delivered

Application

DELIVER(m) from n

node n AN_i node n' AN_j

matching

2

3 matching

R A services

ACK Check node n' g' AN_j 1

send (m)

gateway to gateway communication

intra ad-hoc communication

Figure 4. Sequence diagram of asendprimitive.

in which information is hierarchically routed from source to destination according to an infrastructure maintaining a state information sufficient to attain communications. How- ever, these systems are also captured by the model in the sense that they are ad-hoc networks and could thus be composed to build an X-hoc. Furthermore, in this work we de- vised a restricted set of middleware services enabling au- tonomous service composition obtained through resource awareness, which is independent from the specific purpose and technologies of each single ad-hoc.

Strictly pertaining the related work, the X-hoc model and the architecture presented in this paper encompass several current research issues, i.e., internetworking among wireless networks, resource/service modelling, discovery and awareness, middleware for mobile devices, just to name a few among the more significant.

In particular, concerning internetworking among wireless networks, some current proposals e.g. [23] focus on the integration of wireless local area networks (WLANs) and MANETs with cellular networks (GSM, GPRS, UMTS), and on the extension of cellular networks to implement a multi-hop routing protocol [15]. These proposals mainly address technical issues raising from the coexistence of networks with different bandwidths and access interfaces. We believe that our proposals complements these works, en-

abling the discovery of network integration facilities, the orchestration among available network platforms and allowing to adapt the orchestrated communication service to the user needs.

Resource and service modelling, i.e. the way in which resources and services can be represented and described in a uniform way, understandable across several heterogeneous domains, has been the focus of other research and standardization efforts, e.g. [6, 14, 5]. Modelling resources and services is the basis of service discovery, as it enables to express query on a set of resources and services using a common language. Several service discovery infrastructures have been proposed in the literature, including Jini [17], UPnP [22], Salutation [4], the Universal Description Discovery and Integration for Web Services [21]. These approaches mainly focus on standardized interfaces for service representation and are usually based on a centralized repository, which demonstrated to be a viable solution for wired networks with non-stringent scalability requirements.

However, in a mobile setting, like a MANET, layering and the corresponding separation on concerns are still not well defined. For example routing protocols could be modified in order to embed the discovery process, see for example [13]. On the other hand, if all nodes announce the list of the routing protocols they support, then a node can select

(7)

the most appropriate for a specific setting (e.g., an energy efficient one).

Furthermore, high dynamism and limited resources of wireless mobile networks motivated a huge amount of pro- posal on middleware for mobile and mobile ad-hoc networks, each focusing on different aspects e.g. reflection, location awareness, energy saving etc. Good surveys are [16, 7]. Several among the proposed middleware services (e.g. [1, 2]) are the basis for implementing the proposed middleware architecture in the case that underlying ad-hoc network is composed by (or comprehends) mobile devices.

The contributions mentioned above represent fundamen- tal building blocks of our infrastructure, whose effective implementation depends on the effectiveness of the components discovering and managing access to resources.

5 Concluding remarks

In this paper we presented a network model, namely the X-hoc network model, and a middleware architecture enabling the model implementation. The objective of the model is to explicitly deal with the coexistence of ad-hoc networks built by distinct devices supporting distinct technologies and aiming to exchange messages. Basing on this model, and assumed that in the general case nodes are not able to directly communicate one with each other, we devised a set of resource awareness services necessary to achieve communications among nodes through gateways.

The proposed set of services takes also into account policies for sharing resources as well as user preferences, allowing thus to tailor services according to user needs. Re- source awareness services are layered under a set of communication services in a middleware architecture enabling communications among nodes belonging to distinct ad-hoc networks.

From the current stage, this work can be improved in several directions. In particular, the solutions proposed for implementing resource awareness and X-hoc communications needs to be further refined.

Concerning resource awareness, ways to implement XR in an efficient way need to be devised, as if it is fairly rea- sonable to assume to discover the resources available within an ad-hoc network, gathering the whole set of gateways spawning the entire X-hoc could represent a really difficult task. X-hoc communications should be further refined in terms of standard means to let heterogeneous gateways communicate among them. This is a mainly technologi- cal issue. Furthermore, framing all the useful contributions mentioned in the previous Section within the middleware architecture would result in efficient reuse of concepts and services, possibly raising novel research challenges.

At the moment of this writing, for what it concerns future extensions, it is possible to devise several lines along which

this work could proceed. As example, considering energy as a limited resources would take to consider energy aware X-hoc protocols in which gateway selection occurs in a way that enables energy saving during inter ad-hoc communications. Another example is the use of location and mobility awareness, which could be used to perform optimized implementation of resource awareness services within mobile ad-hoc networks.

References

[1] A. Baggio and I. Piumarta. Mobile host tracking and re- source discovery. In Proceedings of the seventh workshop on ACM SIGOPS European workshop, pages 157–164. ACM Press, 1996.

[2] L. Capra, G. S. Blair, C. Mascolo, W. Emmerich, and P. Grace. Exploiting reflection in mobile computing mid- dleware. ACM SIGMOBILE Mobile Computing and Com- munications Review, 6(4), October 2002.

[3] T. D. Chandra, V. Hadzilacos, S. Toueg, and B. Charron- Bost. On the impossibility of group membership. In Pro- ceedings of the fifteenth annual ACM symposium on Princi- ples of distributed computing, pages 322–330. ACM Press, 1996.

[4] T. S. Consortium. Salutation architecture specification version 2.0c. part 1, june 1, 1999. http://www.salutation.org.

[5] DARPA. Agent markup language and ontology inference layer. http://www.daml.org/2001/03/daml+oil-index.html.

[6] DMTF. Distributed managemnt task force, desktop manage- ment interface. http://www.dmtf.org/standards/dmi.

[7] A. Gaddah and T. Kunz. A survey of middleware paradigms for mobile computing. Technical report sce-03-16, Depart- ment of Systems and Computer Engineering, Carleton Uni- versity, Ottawa, Canada, July 2003.

[8] N. W. Group. Service location protocol - rfc 2165. June 1997, http://www.ietf.org/rfc/rfc2165.txt.

[9] R. M. Hinden. Ip version 6 addressing architecture.

http://www.ietf.org/rfc/rfc2373.txt.

[10] D. K. M. K. H. B. I. Stoica, R. Morris. Chord: A scal- able peer-to-peer lookup service for internet applications.

In A. Press, editor, Proceedings of the 2001 conference on applications, technologies, architectures, and protocols for computer communications, pages 149–160, 2001.

[11] M. Iiyas. The Handbook of Ad hoc Wireless Networks. CRC Press, December 2002.

[12] M. Klein and B. K¨onig-Ries. Multi-layer clusters in ad-hoc networks: an approach to service discovery. In S. Verlag, ed- itor, Web Engineering and Peer-to-Peer Computing, volume 2376 of Lecture Notes in Computer Science, pages 187–201, 2002.

[13] R. Koodli and C. Perkins. Service discovery in on-demand ad hoc networks. draft-koodli-manetservicediscovery- 00.txt, work in progress, IETF, September 2002.

[14] O. Lassila and R. Swick. Resource description framework (rdf) model and syntax specification. W3C Working Draft WD-rdf-syntax-19990105,

http://www.w3.org/TR/1999/PR-rdf-syntax-19990105/.

[15] H. Li, M. Lott, M. Weckerle, W. Zirwas, and E. Schulz. Mul- tihop communications in future mobile radio networks. In

(8)

in Proc. of the 13th IEEE International Symposium on Per- onal, Indoor, and Mobile Radio Communications, pages 54–

58. IEEE Press, September 2002.

[16] C. Mascolo, L. Capra, and W. Emmerich. In Networking 2002 Tutorial Papers, volume 2497 of LNCS., chapter Mid- dleware for Mobile Computing (A Survey). Springer, 2002.

[17] S. Microsystem. Jini community resources: Jini technology architectural overview. january 1999.

http://wwws.sun.com/software/jini/whitepapers/architecture.html.

[18] D. S. Milojicic, V. Kalogeraki, R. Lukose, K. Nagaraja, J. Pruyne, B. Richard, S. Rollins, and Z. Xu. Peer-to-peer computing. Hpl-2002-57, HP Laboratories Palo Alto, Rut- gers University, University of California at Santa Barbara, March 2002. http://www.hpl.hp.com/techreports/2002/HPL- 2002-57.pdf.

[19] L. M. T. Berners-Lee, R. Fielding. Uniform resource identi- fiers (uri). http://www.ietf.org/rfc/rfc2396.txt.

[20] B. Traversat, A. Arora, M. Abdelaziz, M. Duigou, C. Haywood, J. Hugly, E. Pouyoul, and B. Yea- ger. The project jxta addressing model.

http://www.jxta.org/project/www/docs/JXTA2.0protocols1.pdf.

[21] UDDI. Universal description, discovery and integration of web services. http://www.uddi.org/.

[22] UPnP. Universal plug and play, microsoft corporation.

http://www.upnp.org/resources/UpnPbkgnd.htm.

[23] H. Wu, C. Qiao, S. De, and O. Tonguz. Integrated cellular and ad hoc relaying systems: icar. IEEE Journal on Selected Areas in Communication, 19(10):2105–2215, October 2001.