Middleware Supporting Adaptive Services in On-Demand Ad Hoc Networks

Transcription

1 Middleware Supporting Adaptive s in On-Demand Ad Hoc Networks Paal E. Engelstad, Geir Egeland, Sigrid Steinholt Bygdås, Rene Geers, Tore Urnes Telenor R&D, Snarøyveien 30, 1331 Fornebu, Norway Phone: Fax: {Paal.Engelstad, Geir.Egeland, Sigrid-Steinholt.Bygdas, Rene.Geers, Tore.Urnes}@telenor.com Abstract Dynamic resource discovery and service access in an ad hoc multi-mode 4G-system can be a complex task. Since every adaptive client application will have to perform such tasks, it makes sense to implement this functionality in the middleware. This will make service access ubiquitous, and application development simpler and less expensive. This paper presents a middleware architecture for adaptive applications in ad hoc networks. We propose an inter-node coordination mechanism, which constitutes the core of the middleware, based on publish/subscribe Event Notifications. Our paper demonstrates that the middleware functionality, such as the Event Notification mechanism, must be optimized with respect to functionality in the underlying layers and in the routing protocol in particular. We also show explicitly how Event Notifications can be streamlined with an underlying reactive routing protocol, such as AODV. Introduction As more and more devices communicate by using wireless technology, the traditional definitions of fixed, mobile or ad hoc networks will be rendered obsolete as we move towards a future of ubiquitous computing. Terminals will have to manage the characteristics of the different networks, as well as the roaming between networks of different types and degrees of infrastructure. A possible architecture for such a scenario is the ideas of multi-mode networking (MMN) [1], also known as heterogeneous multiple network access. The main concept is to accommodate the combination of wireless networks connected to the global Internet and autonomous mobile wireless ad hoc networks. The mobile terminals support multiple protocols to be able to communicate in different modes, i.e. between themselves and with a fixed network. Multi-mode networking is different from traditional networking in at least two aspects. First, multi-mode terminals can be connected (as IP hosts) through some access network via an access router, as in a traditional network. In addition, terminals also have functionality equivalent to routers. This allows terminals to communicate directly with each other and to form ad hoc networks. Second, in a MMN scenario, a terminal can have more than one network interface and be connected simultaneously to several independent networks, which may have different capabilities and functionalities. In some cases it may be of interest for the application to have an active role when the network is selected. Thus, information should be made available for applications (e.g. by means of the middleware), allowing the applications to participate in making intelligent decisions about the use of network resources. The main focus of this paper is to address one of the most challenging issues of multi-mode networking (MMN), namely the dynamics of ad hoc networks. While residing in an ad hoc network, an MMN node might need to discover resources, such as available ad hoc networks, services in the ad hoc networks, available external inter-connected networks and services provided there. Resource discovery and service access are particularly challenging in ad hoc networks, due to the lack of central services and centralized control. s, networks and other resources should be available despite dynamic changes in the networks. This will require that the applications are adaptive. By introducing middleware (Figure 1) with functionality for adapting to network and resource changes, application development becomes simpler and hence development and maintenance costs are reduced. Adaptive Applications Multi mode Network GPRS Multi Mode Middleware Ad hoc network 3G IP zone Figure 1. Middleware simplifies development of adaptive applications by hiding network complexity from developers. The main contributions of this paperare i) the emphasis on the need for cross-layer optimizations between middleware and routing and ii) an explicit solution to run Event Notifications with AODV [2] as an underlying reactive routing protocol. After having presented related works in the next section, we move on to outline the functional requirements of middleware for adaptive applications. As an example of an adaptive application, we also present the 4G Browser, which helped to guide our middleware design. In the subsequent section, we describe the architectural design and implementation of

2 the middleware. We then explain how the middleware is streamlined with the underlying on-demand (reactive) routing protocol, AODV. Finally, we conclude and outline directions for future work. resources in the next level in a service/resource hierarchy. Network 1 (Ad Hoc) Network 2 (UMTS) Related Work A great amount of work related to middleware and ad hoc networks has been published over the last years. Different techniques are proposed to enable middleware to deal with aspects like mobility, adaptability, scarce resources and service availability. Examples are the combination of reflection and mobile code [3], coordination veneers [4], tuple spaces and mobile agents [5]. None of these publications focus on the relationship between middleware and lower layers as in this paper, even though they recognize the need to propagate network information through middleware for applications to make appropriate actions. Meddour et al. [6] address mobility related to different types of ad hoc networks, including multi hop ad hoc networks. They propose a framework for mobile ad hoc terminals based on active network technologies, where suitable network protocols can be downloaded when needed. However, middleware is not a topic in [6]. Adaptive applications and Middleware The Need for Adaptive Client Applications In multi-mode networking users will experience great variations in available resources and services. A key objective is therefore to always utilize available resources in the best possible way. Users should experience continuity when running applications in a multi mode network. This implies that applications should be adaptive, so that services can be maintained despite changes in the network. Adaptations can be made without notifying the user and can be performed by rules set by the user. Implementation of adaptive applications involves the discovery and the monitoring of available networks and resources and the handling of sessions migrating between network connections. To ease development of adaptive applications, we propose to introduce adaptation support in middleware. Implementation of the 4G Browser The 4G Browser is an example of an adaptive service-oriented application that we implemented. It lets users browse available resources without the help from fixed infrastructures. While the user moves in a heterogeneous mix of networks, resources will appear (represented by an icon in the browser) or disappear. Resources include available persons, terminals, services, networks, files, and activities (e.g. ongoing chat sessions or games). Figure 2 shows how the resources of each type of network are arranged in a hierarchy by using suitable icons. Clicking on an icon will display the available My web My movies Figure 2. Illustration of the hierarchy of resources. Figure 3 shows the 4G Browser screen after the user has selected a network type and specified an interest in music files. Nodes advertising music resources are rendered; clicking on a node brings up a list of files. Joe Sara Figure 3. 4G Browser screen showing available music resources. The browser has the following functionality: The ability to render available resources. Changes in resource availability are automatically detected and rendered. The ability to search for resources and to monitor the status of those resources. This can be done explicitly by requests from the user, or automatically at fixed intervals. The ability to advertise local resources by broadcasting the corresponding top level resource hierarchy. Since the task of the browser is to continuously visualize all services available in 4G networks, we believe that the 4G Browser can be considered to represent a superset of functionalities required by other adaptive applications. This allows us to use a single, concrete application as a guide to the design of our middleware, but still argue that our design is suitable for adaptive MMN applications in general. Functional Requirements to Multi-Mode Middleware Multi-mode middleware should simplify development of applications running in multi-mode

3 networks by performing general complex tasks on behalf of applications, providing developers with a programmable interface to these tasks. First, multi-mode middleware must be able to adapt timely to changes in networks and network modes. Second, the middleware should accommodate applications that have to be aware both of mobility and network modes. This means that in addition to being able to decide what network interface to use as their mobile host moves, the multi-mode applications must be able to handle different network modes. Our middleware must perform the following general tasks on behalf of the applications: Discovery and monitoring of resources Session control, including session migration. Here, resources include users, devices, networks and services. The discovery of resources assumes that resources are able to advertise themselves to other devices on the network. Monitoring means the detection of state changes and the handling of events. Asynchronous resource discovery may complement traditional synchronous service discovery mechanism, where the user takes the initiative and sends out an explicit request for a particular service with desired service attributes. Some service discovery mechanisms for on-demand ad hoc networks have been presented in [7] and [8]. Design of Adaptive Middleware for Ad Hoc Networks Choosing an Event-Based Architecture Our main focus is on asynchronous resource discovery in ad hoc networks and migration of sessions from an ad hoc network to a fixed infrastructure network. This focus has lead to a middleware that supports automatic discovery of services in and via an ad hoc network, and migration of a session to another network connection. We chose to base our middleware architecture on an asynchronous event-based paradigm. The loose coupling characteristics of event-based architectures are believed to be well suited for the high level of dynamism present in ad hoc networks. Also, events offer a simple programming model (API) where applications can subscribe to be notified when events of interest occur. The design and implementation of the middleware described in this paper have been influenced by the development of our 4G Browser presented above. Figure 4 shows how the 4G Browser interacts with the middleware through a message interface. Basically, the 4G Browser subscribes to notifications from the middleware about whether changes have occurred with respect to currently available services. There are also messages that allow the 4G Browser to inquire about the currently available services. Adaptive Application Subscribe Notify HTTP GET Search (P2P) Middleware Figure 4. Outline of relationship between 4G browser and middleware Middleware Architecture Figure 5 shows the main components and connections of our proposed MMN middleware architecture. The middleware layer comprises a Manager component, a Session Manager component, and a Announcer component. A Network Manager at the network layer is also part of the architecture (but is omitted in figure 5). The architecture is essentially peer-to-peer, with each device (such as the Remote in Figure 5) running the same middleware components. Middleware Announcer Viewer Manager Meta Data G Browser 5 Remote 2 3 Network 5 Dispatcher 6 7 Session Manager Figure 5. Middleware architecture. Client Figure 5 also shows how our 4G Browser application can be decomposed into a Viewer component and a Dispatcher component. This decomposition of the 4G Browser application allows us to illustrate in Figure 5 how legacy client applications can utilize the functionality provided by our middleware. Note that the numbers assigned to interaction arrows in Figure 5 do not illustrate a sequence of actions, but show different types of 11

4 interactions between the components involved. We now give a brief description of each component. Announcer In ad hoc networks, nodes will arrive and disappear. The services a node provides can at any time become unavailable to its service users. Our middleware solution prescribes that all nodes broadcast a still alive (heartbeat) message at a given time interval. If several time intervals pass without receiving a message from a given node, this node has probably left the network, and its services are no longer available. The Manager keeps track of available services. In addition to the heartbeat message, the Announcer broadcasts a message telling what type of services its node provides. This message is not sent as often as the heartbeat message. By sending this service announcement, new nodes in the network will soon be updated on available services. It is crucial to minimize traffic in ad hoc networks. A service announcement message can be large (several packages, each of size 255 bytes). An alternative option is to set a bit in the heartbeat message to indicate state changes. However, every Manager that receives this heartbeat will have to send a unicast message in return to ask what the change actually is. With a high density of active Managers (i.e. MMN-enabled nodes) on the ad hoc network, sending service announcements is a better solution to minimize the traffic. This strategy also ensures that new nodes quickly become updated on services available in the network. Manager The Manager receives metadata from remote nodes describing available services. This information is kept in a metadata database. Metadata concerning services provided by a particular node are kept in the database as long as the Manager receives heartbeats from this node. Through the subscription call applications inform the Manager of the types of services they are looking for. The Manager will continually match incoming service announcements with the applications service requests, notifying each application when a requested service arrives, disappears or changes its state. Dispatcher When a user of our 4G Browser becomes aware of a service on the network and decides to initiate a session, the Dispatcher launches an appropriate client application for the service. Prior to launching the client application, however, the Session Manager is given information about the new session, including network connection details (service metadata). Session Manager The Session Manager starts a new session each time the Dispatcher issues a request. The Session Manager immediately tells the Network Manager to associate a new session with the supplied connection details. Next, the Session Manager subscribes to events related to the service in question from the Manager in order to detect the need for session migration. When a session migration becomes necessary, the Session Manager informs the Network Manager to initiate a new session. When applications are ready, the Session Manager informs the Network Manager to perform a session migration, that is to move the communication session from one network connection to another. The Network Manager at the network layer provides IP address virtualization in order to create the illusion of an unchanging IP address to local clients, allowing the actual connection addresses to be changed when session migration is called for. Interactions between Middleware Components The numbers in Figure 5 illustrate different types of interactions between the components of the middleware. The numbers refer the to following types of interactions: 1. User communicates with local applications (the 4G Browser and service clients). 2. Components subscribe and unsubscribe to the middleware through calls to the Manager. 3. The Viewer and Session Manager components receive notifications from the Manager. 4. Communication between 4G Browser and Manager (e.g., requests for information). 5. Explicit search for information 6. The Dispatcher of the 4G Browser requests initiation of a session with a remote service and passes on the connection details. 7. The Dispatcher launches a local client application in a separate thread, e.g., a music player client streaming music from a music service on a remote node. 8. The sending and receiving of announcements (heartbeats). 9. The Session Manager tells the Network Manager to start a new session 10. The Network Manager is told to migrate a session to a new connection. 11. Communication between local client application and a remote service. Implementation We have implemented the Announcer and Manager on Linux Mandrake using a patched kernel with AODV. The middleware is implemented in Java [9]. The 4G Browser has been implemented in

5 Python using a game module [10] to quickly implement a dynamic GUI. Running the Middleware over an Ad Hoc Routing Protocol When designing the event mechanism of the middleware, we distinguished between subscribed and gratuitous event notifications. When dealing with subscribed events, one Event-Consuming Node (ECN) registers to receive event notifications from another Event-Producing Node (EPN). The ECN may initially flood the network with a registration to subscribe to a type of resource event on any node and unicast a registration to any newly arrived node in response to the first heartbeat. The EPN sends a (or Resource) Announcement related to the registration, both immediately and upon later events that correspond to the registration. To reduce the traffic, it is normally sent by unicast (along the return routes established by heartbeats) to a few nodes, or flooded if there are enough nodes subscribing to the event. When it comes to gratuitous events, a node floods (or multicasts) an unsolicited event notification to nodes that have not explicitly registered to receive the event. The event may be a heartbeat or a more detailed Announcement (e.g. related to changes in top-level services). Gratuitous event notifications are useful for common networking tasks related to presence of nodes, because it is hard to register for presence events to nodes that are not yet present on the network. For example, when a node enters (or graciously leaves) a network it broadcasts a notification of this event. Furthermore, nodes periodically send out heartbeat messages to inform surrounding nodes about their continuous presence on the network. By means of gratuitous events, the top-level hierarchy on a specific network (i.e. the users of the 4Gbrowser depicted in Figure 2) was implemented. The lower layers of the hierarchy can assume the presence of an Event-Producing Node, and is thus based on subscribed events. In order to conserve resources of the underlying ad hoc network, it is necessary to streamline events with the AODV routing protocol. AODV was chosen, because a reactive (on demand) routing protocol is preferred in a network with a high level of mobility involving only a subset of the nodes and with communication sessions lasting for long times. The event messages were sent as extensions to the RREQ routing messages (Figure 6), which form return routes back to the sending node. Thus, each heartbeat established routes back to the sending node throughout the network. Figure 6 shows the RREQ header with a heartbeat extension. Type J R Reserved Hop Count Broadcast Id Destination IP address Destination Sequence Number Source IP address Source Sequence number Heartbeat RREQ Header RREQ extension Figure 6. AODV REQ with event message piggybacked. The return routes are useful for event notifications of other services, e.g., browsing resources of a certain category. When the node that is browsing for a specific resource category (Figure 7) receives a heartbeat (1) of a newly arrived node, it might send a synchronous service discovery request or an event registration for a service category to that node (2). The request is sent on a RREP message, following the unicast route established by the RREQ message of the heartbeat. The RREP message establishes a unicast route along which a response to the request can be sent (3) (Figure 7). 2 RREP A B Heartbeat from A Category request from C Figure 7. RREQ/RREP exchange 3 1 C RREQ Category response from A The scope of the heartbeats can be limited by a preset configuration parameter. In this case the heartbeats were only flooded a limited number of hops. Hence, nodes in the ad hoc network can only browse resources of the surrounding nodes to which reachability is good. Limiting the scope enhances the scalability of the heartbeat mechanism. Heartbeats were sent by a period less than the ACTIVE_ROUTE_TIMEOUT of the reactive routing protocol. This ensures that a route can be kept open in cases where interaction with the sending node would otherwise trigger route discovery broadcasts by a number of other nodes that are monitoring resources on the node. We experienced, however, that the periodic flooding of heartbeats introduces a proactive element that undermines the efficiency of reactive routing. Thus, in an ad hoc network where every node is participating in a presence service similar to the one presented in this paper, and where the scope of the heartbeats is unlimited, a proactive routing protocol might be preferred. Such networks may include Personal Area Networks of closely co-operating devices, where each

6 node keeps track of all devices and resources in the network [11]. In a mobile ad hoc network, where only a subset of the nodes participate in presence service and continuous resource monitoring, a reactive routing protocol might still be justified. Conclusions and Future Work Based on a testbed implementation, we have outlined a middleware architecture to support development of adaptive applications for multi-mode networks. As a minimum, the following middleware functionality is needed: Resource discovery and resource monitoring. With resources we mean persons, terminals, networks, services and so forth. Event handling Session migration by means of network layer mobility or session mobility. We have also demonstrated that the efficiency of our event-based middleware depends on the underlying routing protocol. Thus, both the middleware and the routing protocol might need to be adjusted to optimize network performance. We used AODV as an example of a routing protocol for our testbed implementation. Here we showed that the messaging between different nodes in the ad hoc network should be designed intelligently, so that transactions utilize the Route Request and Route Response features of AODV in an efficient way. We also illustrated the importance of adapting an Event Notification mechanism to the parameters of the protocol, such as the ACTIVE_ROUTE_TIMEOUT. Finally, we streamlined the middleware messaging, service discovery and event notifications with the underlying routing mechanisms of AODV, based on experiences gained from our test-bed. In an ad hoc network where all nodes must support a presence service, like the one presented in this paper (such as in a Personal Area Network of closely cooperating devices [11]), a proactive routing protocol might be more suitable. By coupling the middleware closely to the routing module, the broadcast of routing messages might be reused as heartbeat messages. Thus, the presence of a node's IP address in the routing table indicates that the node is present on the ad hoc network. Development of middleware that supports adaptive services and that is streamlined with an underlying proactive routing protocol is an issue for future research. Our work also demonstrated how to implement a software layer on top of the network layer to handle multiple accesses to different network technologies. A node with external access to an external network may announce this as a service by means of the middleware. This approach may compliment network layer solutions to network access ([12], [13]). References [1] ACM Mobile Computing and Communications Review (MC2R), vol.2, no.1, January [2] Perkins, C.E., Royer, E.M., and Das, S.R., "Ad-hoc On Demand Distance Vector (AODV) Routing", RFC 3561, Internet Engineering Task Force (IETF), July [3] Capra et al., "Towards a Mobile Computing Middleware: a Synergy of Reflection and Mobile Code Techniques", 8th IEEE Workshop on Future Trends of Distributed Computing Systems, Bobogna, Italy, [4] Handorean, R., Payton, J., Julien, C. and Roman G-C. "Coordination Middleware Supporting Rapid Deployment of Ad Hoc Mobile Systems", In proceedings of the 23rd International Conference on Distributed Computing Systems Workshops, RI, USA, 2003, pp [5] Herrmann, K., "MESHMdl A Middleware for Self- Organization in Ad hoc Networks. Berlin University of Technology", /MDC2003.pdf (Last visited August 11, 2004) [6] Meddour, D.-E., Mathiu, B., Carlinet, Y. and Gourhant, Y., "Requirement and Enabling Architecture for Ad-Hoc Networks Application Scenarios", Workshop on Mobile Ad Hoc Networking and Computing, Sophia-Antipolis, France, [7] Engelstad, P.E., Geir Egeland, Rajeev Koodli and Charles E. Perkins, "Name Resolution in On-Demand MANETs and External IP Networks", Internet-Draft, draftengelstad-manet-name-resolution-01.txt, IETF, Jan [8] Koodli, R., and Perkins, C.E., " Discovery in On Demand Ad Hoc Networks", IETF Internet draft, draftkoodli-manet-servicediscovery-00.txt, October [9] Java for linux. [10] The Python Game module [11] Do, T.V., Engelstad, P.E., Jønvik, T.E., "Establishing IP Network Support for a PAN-Based Virtual Device", Proceedings of 9th International Conference on Intelligence in service delivery Networks (ICIN 2004), Bordeaux, France, October 18-21, [12] Engelstad, P.E. and Egeland, G., "NAT-Based Internet Connectivity for On-Demand Ad Hoc Networks", Proceedings of Wireless On-Demand Ad Hoc Networks (WONS'2004), Madonna di Campiglio, Italy, January 19-23, (Lecture Notes on Computer Science LNCS2928, Springer 2004, pp ) [13] Engelstad, P.E., Egeland, G., Thanh, D.V., "Analysis of NAT-Based Internet Connectivity for On-Demand Ad Hoc Networks", Proceedings of Western Simulation Multi-conferences, Symposium on Computer Networks and Distributed Systems (CNDS'2004), San Diego, California, January 18-22, 2004.