Mobility and Network Management in Ad Hoc networks

Transcription

1 Mobility and Network Management in Ad Hoc networks Jose Costa-Requena * Helsinki University of Technology Networking Laboratory P.O. Box 127 FIN Finland Abstract--The Ad Hoc network area is still under development and there are many proposals to decide the right technology (routing protocols, addressing, interoperability, etc). To provide the appropriate mobility management in Ad Hoc network, it is necessary to support the idea of link state protocols (ZRP, OLSR, FSR, etc). It is proposed to classify the Ad Hoc nodes into smart and dummy nodes. The smart nodes will have the functionality to maintain the link state information and taking care of the mobility management. The proposed architecture relies on these smart nodes that keep the topology information and provide the required services to enable network mobility. These nodes will implement a generic routing component that maintains the routing functionality and performs the replication/synchronization mechanism among the existing smart nodes in the Ad Hoc network. The main requirement for the synchronization module is that the selected protocol should be independent of the underneath technology. There are plenty of possible solutions but the target of this approach is to utilize a synchronization protocol that can accommodate above it different routing protocols. The possible solutions for data synchronization when implementing routing in Ad Hoc networks are evaluated. Therefore, a generic replication mechanism that works independently of the data content is proposed to support mobility management. The features to self-adaptation to the changing parameters of the communications channels are described. Index terms Ad Hoc, Mobility Management, Link state, Routing, service discovery A. INTRODUCTION Ad Hoc networks are considered as the technical evolution from 4G towards the Private Area Networks. Due to the uncertainty when selecting the suitable routing protocols for the Ad Hoc infrastructure, we study and propose to split the problem in different building blocks. The selected philosophy for this approach is based on a link state protocol. The routing problem is divided in two parts, one consists of the routing algorithm itself and the other contains a mechanism for replicating and synchronizing the routing tables. In the Ad Hoc research area there are multiple alternatives for selecting the appropriate routing protocols, either reactive (on demand routing protocols, AODV [1], DSR [2], TORA [3], etc.) or proactive (link * Jose@tct.hut.fi state routing protocols, ZRP [4], OLSR [5], FSR [6], etc). The dilemma is why to choose proactive protocol that store/replicate the routing information among nodes within the Ad Hoc infrastructure. Reactive protocols are very suitable for Ad Hoc networks, where the topology is extremely dynamic and the nodes do not need to store link state information. Moreover, the battery and bandwidth consumption required for keeping up to date the routing tables in the link state routing protocols generate a significant drawback. The purpose of our study is to present the benefits of the link state protocol for certain aspects of the Ad Hoc infrastructure. To accomplish it, a modular design for implementing an appropriate link state protocol is presented. The reason for proposing the link state mechanism is that it is necessary to keep some persistent data in the nodes to provide interoperability and mobility management, specially when the Ad Hoc network is part of another infrastructure (3G, 4G). The routing data and the information about the network elements are essential for the proper functioning of the networks. The routing topology and also the information about locating the services available in the network are crucial. The service location is very challenging in Ad Hoc networks since nodes are frequently moving and changing their location or point of attachment. The location of the network elements provisioning any service (DHCP [7] servers, DNS [8] servers, NAT [9], SIP Registrars [10], etc.) is also significant. The best mechanism for locating network services in Ad Hoc networks is a big open issue. There are different proposals that advocate to provide a service discovery mechanism at the session or application layer like JINI [11], UPnP [12], Salutation [13], OSGi [14], SLP [15], among others. On the other hand, there are alternatives that implement the service discovery mechanism at the link state layer such as Bluetooth and SDP [16]). Our study complements the latter alternative but promoting a more generic mechanism that can be used for any layer above the link state. The aim of this paper is to analyze a modular design where the routing problem is split into different modules (routing algorithm enhanced with mobility management and replication protocol) that helps in having a suitable

2 link state solution. The approach facilitates to adopt different routing algorithms depending on the environment and the bandwidth requirements. A new API between the routing layer and the replication layer deploys an optimal link state solution. The API will determine the frequency of updates and the information required for nodes discovery. It will also provide the possibility to decrease the update frequency as well as adapting the rate of refreshments, and keeping messages alive depending on the environment conditions. Figure 1, shows the routing module and its components embedded in the Ad Hoc node architecture. Application and services Directory Services IP Layer (IPv4/IPv6) User Services (Messaging Gaming) Services and session management (SIP,HTTP) Context-Sensitive Roaming Layer Routing Module Routing Algorithm Module API API Synchronisation Replication module (SCSP) Link Layer Protocol Communication Module Physical Layer Future Services Routing Information Figure 1. Routing module within Ad Hoc node Ad Hoc networks have a very dynamic topology, thus the API has to provide the Attach-Detach procedure implementation. This procedure allows the nodes to inform that they cannot continue contributing to maintain the link state information in the network. The proposal is to consider the virtual community concept where some of the nodes with enough battery and resources (smart nodes) will benefit the rest of nodes with poor resources (dummy nodes). The capable or smart nodes will perform a link state protocol among them while keeping a proactive behavior with the rest of the community. Furthermore, any of the high level Ad Hoc nodes can become a lower level node in case that it runs out of battery or resources. Thus a procedure is performed among the higher level nodes to advertise either that they are able to participate as link state node (Attach) or that are becoming a lower level node (Detach). The lower level (dummy) nodes see all the rest of nodes in the network as normal nodes that perform a proactive routing protocol. The smart nodes have the responsibility of keeping the topology information and implementing the mobility mechanism. Therefore, within the semantics of smart nodes are included all the nodes that provide any service to the network in terms of service provisioning (WEB servers, Content servers, Messaging, etc.) and mobility management (DHCP, DNS, NAT, etc). Section B presents Ad Hoc networks requirements and relevant features in terms of addressing, routing and interoperability. Section C analyses different solutions that could be used for implementing the synchronization/replication module as part of the generic routing infrastructure. A modular solution to implement the synchronization/replication mechanism for link statebased protocols in Ad Hoc infrastructures is presented. Finally conclusions and some guidelines for implementing the routing/mobility module within Ad Hoc environments are discussed. B. AD HOC NETWORKS This section identifies the different level of requirements needed to provide a robust Ad Hoc infrastructure. These requirements are a set of conditions that any routing mechanism should be compliant with to perform an optimal procedure. 1st. Routing The routing algorithm has to be flexible and support different technologies. Routing tables contain different address information such as MAC, IP or logical addresses [18] that are used by the link state protocol. Furthermore, the tables are extensible for adding new attributes if required by either the physical or the network layer. The drawback of the proactive protocol is that it requires a routing table where the content of the entry can be extended. Thus, our proposal using a modular structure in the implementation allows changing the routing algorithm without affecting the rest of modules. To provide modularity, the routing mechanism as a whole should be split in different layers. The routing mechanism should support backward compatibility with existing and forthcoming routing proposals. Furthermore, any proposal should make use of the existing protocols whenever possible and impose minimum changes or extensions on the existing ones. Any new approach has to minimize infrastructure installation costs and complexity. A routing mechanism should provide the means for the Ad hoc network to move between heterogeneous networks in a wide area scope. This requirement will ensure a robust, permanent and uninterrupted worldwide adopted mechanism. It could be used to attach the device

3 anywhere and to enable the Ad Hoc nodes to work via any available access technology (802.11b WLAN, Bluetooth, etc.) The routing module has to be capable of informing about the network entities available in the Ad Hoc network and providing a service discovery enabler to the Ad Hoc nodes. The information and capabilities of the network elements (DNS, DHCP, SLP, SIP Registrar, etc) are communicated as part of the link state layer. The link information provides the awareness of the connectivity within the Ad Hoc networks and also maintains information about network capabilities. The information is kept as part of the routing data in a transparent manner to the application and the user. When a session handover is performed at the network layer, the status is transparent to upper layers despite the migration in the network topology. A change of topological location will not have any impact on layers above the network layer other than a temporary loss of performance. The proposed routing mechanism will be able to handle the handover process during those changes, and perform the service discovery and node configuration transparently to the upper layers. In this section requirements are low latency, minimum delays, minimum signaling load, and minimum bandwidth consumption for transactions exchange. A unified routing/mobility and network capabilities discovery mechanism avoids situations with distinct configuration mechanisms where they are unable to interoperate with each other. Therefore, the addresses to the more relevant servers for the optimal functioning of the Ad Hoc infrastructure are part of the routing information that the nodes exchange. 2nd. Addressing Addressing depends on the technology and requires self-descriptive formats and a flexible structure. This structure should be able to allocate the MAC, IP, Bluetooth, and logical addresses at the link layer. The replication/synchronization mechanism does not consider the content of the routing tables. The replication module just considers the content of the cache entries, and creates the Hash or Cache Key and a time stamp to check the newest entries from the other nodes in the Ad Hoc group. The link layer uses its own addressing mechanisms and that is kept in the lower layers. On top of the link layer, IP layer functionality for providing a common framework to use existing applications and services is required. The link layer keeps the routing and network feature information. It hides the underneath mechanism providing a transport platform while in the upper layer it will be seen as IP transport. Therefore, on top of this layer it can be implemented any IP-based service. The main advantage of this approach is that terminals keep on using IP based addressing and naming, and they can use any IP-based services locally or on the top of any other IP network (Internet, 3G [19]). 3rd. Nodes Discovery Nodes should have an automatic procedure to let the rest of nodes in the Ad Hoc network know about their presence in the group. The proposed routing module provides a node discovery mechanism. IPv6 [20] provides a node discovery mechanism that detects new nodes and resolves IP address collision problems. Nevertheless, the node discovery proposed for the routing module offers additional information about the network elements. This mechanism is part of the link state discovery performed among the nodes that are able to keep the link state information in the network. With this approach the nodes are able to exchange routing information and network capabilities to improve the routing process. 4th.Networks Interoperability The Network Address Translator (NAT) provides IP interoperability among different subnets. NAT permits the nodes to communicate with external IP-based networks. The role of NAT can reside in one of the nodes of the AdHoc network, or it can be requested from the local network provider. If none of those solutions can be implemented the Adhoc network will remain isolated. After the NAT is established the private IP addresses allocated to communicate internally can be used for exchanging information with external entities. Therefore, since the addressing approach taken in the Ad Hoc network is IP based, the interoperability is guaranteed. In the routing tables, the NAT address has to be updated as the outgoing node towards other autonomous systems. The knowledge of the NAT address is communicated as part of the link state information among the smart nodes. When the smart nodes receive a route request from the dummy nodes towards an address outside the Ad Hoc network, the smart node will include the NAT address in the Route Response. Therefore, the dummy node gets the NAT address as default gateway from the smart nodes.

4 5th. Network services discovery When using IP for communication the user is reached through the assigned IP address. The conflict appears when the Ad Hoc network due to its nomadic nature creates its own address space, and it has to be available to the other networks. Afterwards, when the Ad Hoc network requires the access to other external infrastructures a Network Address Translator (NAT) plays its role. One of the nodes that forms the Ad Hoc network takes the role of NAT and replicates the information among all the nodes using the replication protocol to be aware of the access point towards external networks. Furthermore, if nodes in the Ad Hoc network request VoIP services, a Session Initiation Protocol (SIP) proxy or Registrar will be required. Thus, one of the nodes within the Ad Hoc network can implement the functionality of the servers. In that sense, a completely auto-sufficient infrastructure that provides IP accessibility and VoIP services can be easily established. Similarly, in case of locating any other service within the Ad Hoc infrastructure the nodes can share the location of other relevant network entities such as DHCP server or SLP.The actual service discovery mechanisms are the following. IETF offers the Service Location Protocol where directory agents implement the service registry. They store service profiles and the location of the service but no executable code. The discovery of services involves first locating these directory agents. If no directory agent is available, clients may multicast requests for services and servers may multicast advertisements of their services. Microsoft proposed Universal Plug n Play, which uses the Simple Service Discovery Protocol. This protocol also uses centralized directory services, called proxies, for registration and lookup of services. If no such proxy is available, SSDP uses multicast to announce new services or to ask for services. The advertisement contains a Universal Resource Identifier (URI) that eventually leads to an XML description of the service. This description is accessible only after the service has been already discovered through a lookup service. The Salutation project also uses a relatively centralized service registry called Salutation Manager (SLM). There may be several such managers available, but the clients and servers can establish contact only via these SLMs. The advantage of this approach is the fact that these SLMs can have different transport protocols underneath, unlike the above-mentioned models that all assume an IP transport layer. To realize this, Salutation uses transport-dependent modules, called Transport Managers that broadcast internally, helping SLMs from different transport media interact with each other. Grid s Location Service (GLS) is a new distributed location service, which tracks mobile node locations. GLS combined with geographic forwarding allows the construction of ad hoc mobile networks that scale to a larger number of nodes than possible with previous work. GLS is decentralized and runs on the mobile nodes themselves, requiring no fixed infrastructure. Each mobile node periodically updates a small set of other nodes (its location servers) with its current location. A node sends its position updates to its location servers without knowing their actual identities, assisted by a predefined ordering of node identifiers and a predefined geographic hierarchy. Queries for a mobile node s location also use the predefined identifier ordering and spatial hierarchy to find a location server for that node. These service discovery strategies allow one node to advertise services, to lookup services and to access them without explicit knowledge of the network structure and communication details. Services offered by servers may be discovered at runtime. Services are advertised by publishing a profile containing attributes and capabilities useful when searching for a service and proper service invocation. The discovery techniques enable services to publish their capabilities and clients to find and use a needed service. As a result of a successful lookup, a client may receive a piece of code that actually implements the service or facilitates the communication to the server offering the service. These service discovery techniques have certain disadvantages. They assume (more or less) a fairly stable network and they are based on centralized service registries. Therefore, frequent disconnections inherent in ad hoc networks lead to inconsistency of data in centralized service directories. Furthermore, the broadcast implementations need a high frequency of messages in order to preserve consistency. This leads to an increased consumption of bandwidth. The Ad Hoc networks require a higher degree of freedom and a fully decentralized architecture. Thus, the service registry should immediately reflect changes affecting service availability and the services that are no longer reachable should not be available for discovery. The suitable service discovery mechanism should permit

5 users and programs to be as effective as possible in this environment of uncertain connectivity, without changing their manner of operation (i.e., by preserving the interface). Therefore, a lightweight model that supports direct communication and offers a higher degree of decoupling is preferred. The complexity of the ad hoc networking can be hidden behind a simple service registry interface that can offer transparent access to both local andremoteservicesinauniformway. The nature of high mobility in Ad Hoc networks imply that no node should be a bottleneck the work of maintaining the location service should be spread evenly over the nodes. Thus, the failure of a node should not affect the reachability of many other nodes. The queries for the locations of nearby hosts should be satisfied with correspondingly local communication. This would also allow operation in the face of network partitions. Therefore the network configuration and management mechanism in Ad Hoc networks should be able to handle the network information in a robust and scalable manner. Thus, every node that joins the ad-hoc network should be able to automatically obtain the network information. The new terminal should be able to specify its own capabilities and the role it wants to have in the ad-hoc infrastructure. The relevant information must provide enough information for self-organizing the network in terms of routing and topology optimization and services. The information can be categorized in different levels (Routing features {Node mobility, speed, orientation, location information, etc.}, Device features {Processing power, memory, battery, etc.} and Service features {based on service characteristics; network management, application services, etc}). With the appropriate network management and service discovery, the network infrastructure should be able to converge towards an optimal configuration after an initial period of adaptation based on the new node information. The inertia or latency in the auto-configuration procedure should be minimized to handle the re-configuration process in case changes due to mobility. The process should be composed by an Attach and a Detach mechanism. The former will include a neighbor discovery and network capabilities as well as node capability negotiation and role assignment. Based on the negotiation the nodes can be classified depending on its capabilities and willingness to perform any communitary service in the network. Thus, a minimal node classification as following is required. Dummy node only acts as routers and knows the methodology for accessing to the existing services in the network. The service capable node acts as router and provides services as well. In case of duplicity, it keeps the redundant information for other nodes in the network that are provisioning the same service for the community. Any node that has to access the service will query the service itself instead of the specific node. This is the main difference compared to the fixed network, where the hosts have a service discovery procedure and obtain the address of the server that provides a certain service. In ad-hoc networks that is not possible due to the failure probability. There should be a service provisioning and an agreement among the nodes that are providing the same service. The node will request any service and the network itself will assign the server that provides that service based on routing decision and node characteristics such as its location and cost function to reach that node. Figure 2, shows the discovery mechanism implemented when a new node enters in the Ad Hoc infrastructure. The new (smart) node sends a network discovery broadcast to learn about the network capabilities and topology. Only the "dummy" nodes respond to the query but the answer contains the address of the existing "smart" nodes in the network. Afterwards, the service provisioning is negotiated between the "smart" nodes. 3) A) Broadcast TTL=1 (Query: Network capabilities Unicast (Response: Dummy node, Network Capabilities=0) 3) Network configuration negotiation Broadcast (Announcement: service node capabilities) Figure 2. A) Network services and node discovery procedure. 3)

6 In Figure 3, the new smart node contact directly with one of the smart nodes and the service negotiation is done immediately. Afterwards, the new network capabilities are broadcast to all the dummy nodes to know the server address that is provisioning the new service. 3) B) Broadcast TTL=1 (Query: Network capabilities Unicast (Response: Dummy node, Network capabilities=1, Service node address) Unicast (Announcement: Local service node capabilities, Network service nodes addr/srv) 3) Network configuration negotiation Broadcast (Update: service node capabilities) Figure 3. B) Network services and node discovery procedure. 6th.Network mobility The nodes without additional infrastructure establish the Ad Hoc network dynamically and they keep it according to their communication needs. The Ad Hoc nodes have a variable topology that can change frequently. The Ad Hoc network can work isolated among the Ad Hoc nodes or it can have gateways and interfaces with the fixed network. Therefore, the Ad Hoc node can also be part of the fixed network accessing through NAT or Gateway via different interfaces. Thus, the proposed mechanism will take care of the node mobility and roaming based on context information. In this environment the context sensitive roaming layer will handle the mobility procedure when moving either within the Ad Hoc network or during the handoff to different technology (WLAN, UMTS, etc). The context information can be used for several purposes in Ad Hoc networks. Firstly, during the Ad Hoc network establishment or during the "Attach" procedure to an existing Ad Hoc network. The context sensitive layer will recognize the environment changes and will provide the routing mechanisms to allow the node to attach to the network or even create its own. The context sensitive layer should be able to extract, interpret and use context information and adapt its functionality to the current environment. This module is directly connected to the routing module (Figure, and it should obtain all the required information from there and from the application layer. The context information is used to characterize the situation of the node, whether it is connected to the fixed network or it has to establish its own Ad Hoc network for specific needs. The context information can be composed by multiple pieces of data that identify the environment. (Node identity, spatial information {location, orientation, speed, acceleration, etc.}, temporal information, environmental information {temperature, light, noise level, etc.}, social situation {people that are nearby}, resources {accessible devices, hosts, etc.}, node resources {battery, display, network, bandwidth, etc.}, schedules and agendas, etc. Therefore, the context information such as device location and proximity, node resources (battery, bandwidth) and any other type of context information is used to determine the context environment and decide whether the node should be roam into a new network. The Ad Hoc node can listen to "radio beacons" from surrounding access points of the same technology. The node can listen to broadcast channels of surrounding base stations. The surrounding base stations may or may not belong to the same subnet/operator where phone is currently attached. The context sensitive layer that received the context info from the routing layer and notices the changing context, thus it initiates the roaming process. Therefore, the context-sensitive layer should be able to acquire IP layer connectivity with neighboring access routers without letting go the existing connectivity. It will implement a fast/seamless handoff procedure. The routing module "pick" one among the various beacons thatitmaylistentoatagivenlocation.thechoicewill depend on signal quality from the corresponding access networks (routers).

7 The handoffs procedure is executed at link layer but the context sensitive layer takes the decision after receiving all the context information. In case of real-time flows the Mobile node reports to the network what other base stations are visible, and the network decides where the Mobile node will handoff. In case of not real-time (e.g. cell re-selection of UMTS), the Mobile Node makes the decision based on algorithms and information it has locally. The other assumption is that the fast/seamless handoff is at the network (IP) layer. Therefore, the node can have multiple interfaces (cellular, UMTS or GSM, WLAN, Bluetooth, etc). There Routing Module is directly connected to the Link Layer and it is aware of the active interface that is receiving traffic, while the rest of interfaces are sleeping or in idle state. The context sensitive layer is receiving information constantly from the routing module and it takes care of waking up the appropriate interface at correct time when access opportunity exists due requirements because of context changes. The access opportunity is detected by Link layer/radio that provide explicit trigger from the network over the necessary interface. In any case the Mobile Node would cause the activation of a new interface based on the fact that the signal strength of that interface is at some threshold and there are some context changes that requires activating the new interface. Furthermore, the context sensitive module (CSM) receives the information from the Routing Module directly from the link layer, thus it is aware of the access opportunity exists in the new context. Then the CSM activate the required interface and communicate to the upper network (IP), session and application layers to perform the access authorization. The roaming process requires additional processing at the network layer (IP) since it requires that the network know the area where the new Mobile Node is located and probably at session layer (SIP) to register the node in the Proxy server. After all the process the new interface is active when the node tries to connect to new access point and link layer and IP connection was acquired, including some capability negotiation. The capability negotiation included as part of the node attachment to the network and interface activation includes the selection of the router that will accomplish the node requirements before the handoff process is finalized. Thus the node communicates its beacons and available interfaces as part of the mobility process and the network will communicate the appropriate router and interface to be activated to continue with the handoff process. C. GENERIC ROUTING AND MOBILITY INFRASTRUCTURE In our proposal, the routing and network capabilities information are considered as cache data kept in the mobile nodes. The proposed routing module is split into routing algorithm module and the replication or mirroring module. In Ad Hoc networks all the nodes are not able to keep a big amount of data up to date. For that reason, there are two kind of nodes dummy or lower level nodes, and smart of higher-level nodes. The smart nodes have enough power and resources for replicating caches. Therefore, the information is quickly accessible from different locations in the network and the load of the routing discovery is reduced depending on the amount of smart nodes in the Ad Hoc network. The smart nodes implement the replication mechanism that allows developing scalable schemes to use efficiently the network topology. In Ad Hoc networks the transport layer will depend on the technology used at the physical layer. The physical layer can be changed while keeping the same API to the upper layers and as final result the user can see an IPbased transport layer. The API has to be common to all the Ad Hoc nodes, or at least it has to be able to provide the ports or interfaces that can be used to communicate with the rest of nodes. These parts are components of the Routing module that takes care of routing and replication process. 7th.Routing module The Routing module is composed with two subcomponents; the routing algorithm module and the replication module. The routing algorithm implements the link state routing protocol and it includes additional information for service discovery and network management. The replication module takes care of synchronize/replicate the routing information among the smartnodesthatareactiveintheadhocnetwork.the communication between these two modules is implemented with the specific API. Replication API The purpose of the replication API is to provide a common framework that can be used by the routing algorithm module. The API will provide the necessary primitives to model the replication process according to the routing requirements. Thus, the API accommodates the rate of updates and replications. Furthermore, the API provides the mechanism to initiate a node discovery

8 procedure and Attach-Detach mechanism among the smart Ad Hoc nodes. Replication module The most popular communication protocols are the Internet Cache Protocol (ICP) [21], Cache Digest, CARP (Cisco) [22], WCCP (Microsoft), Flood-d [23], LDUP [24] and SCSP. SCSP uses a request-reply paradigm implemented independently of the transport protocol. SCSP uses the group-based replication and the creation of overlapping caching meshes to forward objects among groups. Another important technique adopted for cacheto-cache communication is the notion of cache digest (as in SQUID [25] and Summary Cache). Digests are used to reduce intercommunication load by exchanging summarized information instead of the whole object. Our proposed mirroring module, within the routing module, considers SCSP [26] as the generic protocol for synchronization purposes that can be used over any transport mechanism. 8th.Context sensitive roaming module This module defines a complete layer that is sitting on top of the routing module and it is directly communicated with the routing module and the network layer. This module receives information from the routing module about the link state information and available interfaces. This module also communicates with the network and session layer to complete the roaming and mobility process in a seamless manner. Therefore, this module collects context information from different layers, convey it and determine the procedure to perform the handoff. D. MODULAR ROUTINGINFRASTRUCTURE There are ongoing research activities to define the suitable routing protocol, whether it is distance based, link state or a hybrid solution. Most current ad-hoc routing algorithms extend existing routing protocols in IP-based wired networks. They take either a proactive strategy such that route state information is exchanged periodically among hosts (e.g. DSDV), or a on-demand approach where message exchange overhead is only incurred when a route is needed (e.g. DSR, AODV, TORA). One of the problems of these protocols is that they are not able to scale to larger networks, since global information is required to make routing decisions. With the presence of node mobility, such approaches would suffer from either out-of-date states or flooding of periodically triggered updates. In order to provide end-to-end communication throughout the network, mobile nodes must cooperate to handle network functions, such as packet routing. Thus, the best practice is to define a routing architecture that inter-operates with distance vector and link state protocols. Therefore, nodes that do not have sufficient resources (dummy nodes) for supporting the link state protocol will implement distance vector protocol. On the other hand, nodes with enough resources (smart nodes) will implement the link state protocol and will help the nodes with limited resources to accelerate the distance vector-based route discovery. This approach enhances distance vector protocols using the nodes with enough capabilities that can support link state protocols and assist to the rest of virtual Ad Hoc community. The routing component implemented in smart nodes, contain a routing algorithm and a cache mirroring modules. SCSP is proposed to implement the mirroring module since it considers a fully mesh mirroring without any topology restrictions. This approach guarantees that the information is updated in the servers that compose the group of smart nodes. As part of previous research project a SCSP prototype was implemented. Hence, SCSP can be tested as the replication protocol for mirroring the routing information among multiple nodes. E. CONCLUSIONS The Ad Hoc networking technology is an area under development that is becoming popular in the recent years. There are many challenges in deployment like Ad Hoc networks related to mobility management, routing, service discovery, etc. Nevertheless, in this paper we have presented a proposal to divide the problem in smaller parts and treat them separately. Reducing the scope of the problem the solution can be solved as a conjunction of building blocks. The first issue we covered is the routing and network capabilities discovery. Thus, an API was created between the routing and the replication layer. The routing is kept as an application on top of the replication process that is used for performing the routing functionality. When analyzing the replication problem, it is selected one possible solution that uses SCSP as the synchronization protocol and can be tested. A prototype can be implemented and from the results it can be deduced whether SCSP is suitable for mirroring small databases using an inline schema. If SCSP does not suit for Ad Hoc purposes, it can be derived the replication protocol tailored for Ad Hoc networks. From the experience acquired with SCSP, additional enhancements are recommended for using a protocol tailored for Ad Hoc networking technology. One of the problems is that

9 commercial Ad Hoc networks do not conform to the collaborative philosophy where every node should forward the traffic from other nodes despite it is depleting its own battery and resources. Therefore, the proposed solution is based on the concept where certain nodes with enough resources are providing their resources in benefit of the rest of the Ad Hoc nodes. Those nodes collaborate because they are part of the same community where they are sharing resources towards a common benefit (chatting, messaging, group discussions or gaming, commercial announcements, etc). The last part of the proposed architecture is the context sensitive layer that via an API with the Routing module collects context data that is processed to decide and perform the roaming and mobility procedure. As a final conclusion, reducing the scope and focusing in a modular solution for different parts, a suitable architecture can be designed to solve the network management problem in Ad Hoc networks. [20] T. Narten, E. Nordmark, W. Simpson, " Neighbor Discovery for IP Version 6 (IPv6)", RFC 2426, IETF, Dec [21] D. Wessels, K. Claffy "Internet Cache Protocol (ICP) version 2", RFC 2186, IETF, Sep [22] V. Valloppillil, K. Ross, "Cache Array Routing Protocol v1.0", IETF draft, Aug [23] Obraczka, K., Danzig, P., Evaluating the Performance of Flood-d: A Tool for Efficiently Replicating Internet Informationn Services. IEEE Journal on Selected Areas in Communications, VOL. 16, NO. 3, April pages. [24] Stokes, E., Good, G. The LDUP Replication Update Protocol. Internet draft, July 15, [25] SQUID " Squid Web Proxy Cache", [26] Jose Costa-Requena, "An Implementation of the Server Cache Synchronization Protocol. Helsinki University of Technology, Laboratory of Telecommunications Technology, REFERENCES [1] C.E.PerkinsandE.M.Royer,"Ad-hocOnDemandDistanceVector Routing", Second IEEE Workshop on Mobile Computing Systems and Applications, pp , February [2] D.b. Johnson and D. A. Maltz, "Dynamic Source Routing in Ad Hoc Wireless Networks", in Mobile Computing, edited by T. Imielinski and H. Korth, chapter 5, pp , Kluwer Academic Publishers, [3] V. Park and M.S. Corson, IETF MANET Internet Draft "draft-ietf- MANET-tora-spe03.txt", Novemmer [4] M.R. Pearlman and Z.J. Haas, "Determining the Optimal Configuration for the Zone Routing Protocol", IEEE Journal on Selected Areas in Communications, Special Issue on Wireless Ad Hoc Networks, vol 17, No 8, pp , August [5] P. Jacquet, P. Muhlethaler, A. Qayyum, A. Lanouiti, L. Viennot and T. Clausen, IETF MANET Internet Draft "draft-ietf-manet-olsr-02.txt", July [6] A. Iwata, C.-C. Chiang, G. Pei, M. gerla and T.-W. Chen, "Scalable Routing Strategies for Ad Hoc Wireless Networks", IEEE Journal on Selected Areas in Communications, Special Issue on Wireless Ad Hoc Networks, vol. 17, No 8, pp , August [7] R. Droms, "DHCP: Dynamic Host Configuration Protocol", RFC 2131, Network Working Group, IETF, 1997 [8] P. Mockapetris, "Domain Names: implementation and specification", RFC 1035, Network Working Group, IETF, [9] P. Srisuresh, M. Holdrege," IP Network Address Translator (NAT) Terminology and Considerations ", RFC 2663, IETF, Aug [10] M. Handley, H. Schulzrinne, E Schrooler, J. Rosenberg. "Session Initiation Protocol", RFC 2543, IETF. [11] Sun Microsystems, Inc, "JiniTM Architecture Specification", Version 1.2, December [12] Universal Plug and Play Forum," Universal Plug and Play Technology UPnP", [13] Salutation Consortium, "The Application Programmer's Interface of the Salutation Architecture ", [14] Open Services Gateway Initiative (OSGi), " OSGi - The Managed Services Specification", [15] E. Guttman, C. Perkins, J. Veizades, M. Day," Service Location Protocol, Version 2", RFC 2608, IETF, Jun [16] Bluetooth SIG, "Specification of the Bluetooth System Profiles, Version 1.0B volume 1, Part K:2", [17] J. Luciani, G. Armitage, J. Halpern,N. Doraswamy, "Server Cache Synchronization Protocol (SCSP). RFC April [18] T. Berners-Lee, R. Fielding and M. McCahill, "Uniform resource locators (URL)", RFC 1738, IETF, Dec [19] 3 rd Generation Partnership Project, 3GPP.