A cluster-based trust-aware routing protocol for mobile ad hoc networks

Wireless Netw (2010) 16:969–984 DOI 10.1007/s11276-009-0182-1

A cluster-based trust-aware routing protocol for mobile ad hoc networks Haidar Safa Æ Hassan Artail Æ Diana Tabet

Published online: 20 May 2009  Springer Science+Business Media, LLC 2009

Abstract Routing protocols are the binding force in mobile ad hoc network (MANETs) since they facilitate communication beyond the wireless transmission range of the nodes. However, the infrastructure-less, pervasive, and distributed nature of MANETs renders them vulnerable to security threats. In this paper, we propose a novel clusterbased trust-aware routing protocol (CBTRP) for MANETs to protect forwarded packets from intermediary malicious nodes. The proposed protocol organizes the network into one-hop disjoint clusters then elects the most qualified and trustworthy nodes to play the role of cluster-heads that are responsible for handling all the routing activities. The proposed CBTRP continuously ensures the trustworthiness of cluster-heads by replacing them as soon as they become malicious and can dynamically update the packet path to avoid malicious routes. We have implemented and simulated the proposed protocol then evaluated its performance compared to the clustered based routing protocol (CBRP) as well as the 2ACK approach. Comparisons and analysis have shown the effectiveness of our proposed scheme. Keywords Clustering

MANET  Routing protocols  Trust 

H. Safa (&)  D. Tabet Department of Computer Science, American University of Beirut, Beirut, Lebanon e-mail: [email protected] D. Tabet e-mail: [email protected] H. Artail Department of Computer and Communication Engineering, American University of Beirut, Beirut, Lebanon e-mail: [email protected]

1 Introduction Mobile ad-hoc networks (MANETs) are formed arbitrarily by a set of mobile devices falling within the transmission range of each other [6]. They lack any sort of centralized administration or fixed infrastructure and are known by their dynamic topology, as nodes are capable of moving actively while remaining active and reachable. Routing protocols act as the binding force in MANETs and facilitate communication beyond the physical wireless range of the nodes. To provide connectivity, every node cooperates with other hosts to deliver packets to their destination by acting as a router. These protocols could operate in either a flat or hierarchical network architecture. In the flat architecture, all nodes participate in the routing process. In the hierarchical architecture nodes are divided into a number of clusters each of which is managed by a cluster-head that makes control decisions for cluster members. In this architecture only cluster heads and gateway nodes (intermediate nodes between two cluster-heads) participate in the routing. Traditional MANET routing protocols assume that all nodes in the network work in a benevolent manner and no predefined trust exists between communication partners. This may render the network vulnerable to malicious attacks in case of the presence of selfish and malicious nodes. Selfish nodes are those which, in order to save their own batteries, do not propagate packets from other nodes as per the protocol, while malicious nodes may perform impersonation, fabrication or modification attacks against the network traffic [19]. Since the communication safety of a host solely depends on a proper choice of the path used to reach the destination, it is important for a host to know the reliability of the nodes forming the route [3]. In this paper, we propose a novel cluster based trustaware routing protocol (CBTRP) that protects routed

123

970

packets in MANETs from intermediary malicious nodes by attempting to only route them through trusted nodes. In CBTRP: (1) two unfamiliar nodes develop a trust level between them that increases and decreases with time and frequency of interactions, (2) the network is organized into one-hop disjoint clusters, whereby every node elects the most qualified and trustworthy node of its 1-hop neighbors to be its cluster-head, (3) cluster members forward packets only through the trusted cluster-heads thus ensuring a safe path, (4) as soon as a cluster-head becomes malicious, the member node re-elects another trustworthy neighbor to be its cluster-head to maintain safe routing along the network, (5) routing requests from malicious nodes are not processed and no packet will be forwarded to them. The rest of the paper is organized as follows. In Sect. 2, we survey recent related work. In Sect. 3 we present our trust-aware routing protocol. Section 4 evaluates, through simulations, the performance of the proposed protocol using metrics such as packet delivery ration and routing overhead. The performance of the proposed CBTRP is compared to that of the cluster based routing protocol (CBRP) [9] and the 2ACK trust based routing scheme proposed in [12]. Conclusion and future work are drawn in Sect. 5.

2 Related work Several routing protocols have been proposed for use in MANETs [9, 10, 13, 17, 18]. These protocols can be divided into two categories: proactive and reactive [22]. In proactive routing, each node maintains an up-to-date routing table that contains a consistent view about the current network topology. In reactive routing, routes are discovered and maintained only when needed by the source node and are deleted when they become inactive. The destination-sequenced distance-vector (DSDV) [17] is a routing protocol that operates in a flat architecture. It is a table driven and proactive protocol in which every mobile node maintains a routing table that includes an entry about every possible destination in the MANet along with the number of hops to reach the destination. The dynamic source routing (DSR) [10] is another routing protocol that operates in a flat architecture. However, DSR is a reactive routing protocol but not table-driven and is based on the concept of source routing in which the source node includes the complete path to the destination in each data packet header. The ad-hoc on demand distance vector (AODV) [18] is table driven (like DSDV) but reactive protocol (like DSR) that aims at minimizing the number of maintained routes in the routing tables. In AODV, routes are discovered only when needed (on demand basis) and maintained only when they are used (rather than maintaining a complete list of routes to all destinations).

123

Wireless Netw (2010) 16:969–984

The cluster-head gateway switch routing (CGSR) protocol [13] and the cluster based routing protocol (CBRP) [9] operate in a hierarchical architecture. CGSR is based on DSDV to route the traffic from the source node to a destination (i.e. source, cluster-head, gateway, cluster-head, destination). On the other hand, CBRP is a source routing protocol based on DSR. In CBRP, the nodes are divided into a number of overlapping or disjoint 2-hop-diameter clusters. In each cluster, the node with the lowest node ID is elected as cluster-head. Each node having a bi-directional link to the cluster-head regards itself as a member of that cluster. All the nodes broadcast HELLO messages periodically which contain tables carrying information about the neighboring nodes and adjacent clusters and cluster-heads. Routing in CBRP consists of 2 phases: route discovery and the actual data packet routing. When a source node S wants to send data to destination node D, the routing can be summarized as follows: 1. 2.

3.

4.

5.

6.

7.

S sends route requests (RREQ) to all the neighboring cluster-heads (CHs) only. When a CH receives the RREQ, it checks if the node D is in its cluster. If it is, the cluster-head sends the request directly to the destination. Otherwise, the route request is forwarded to all the adjacent cluster-heads. Every CH appends its address to the packet header, so that when a CH receives a route request it checks if its address is in the packet header. If it is, it discards this packet. When the RREQ packet arrives at the destination, D responds by a route reply packet (RREP) using the route that had been recorded in the request packet. Intermediate cluster heads forward the RREP packet not necessarly to the next node in the route, but to the farthest node in the route recorded in the header of the RREP packet to optimize the route. If the source S does not receive RREP from the destination within a time period, it tries to send an RREQ again. When S receives the RREP, it uses source routing to send the packet to the destination, using the optimized route found in the RREP packet it has received.

These routing protocols only perform very basic security functions which are not sufficient to protect the network. Several routing protocols were recently proposed to address security concerns of MANETs [4, 7, 8, 11, 12, 19, 20, 23]. In [23], an authenticated routing for ad hoc networks (ARAN) was proposed. ARAN is a reactive protocol in which each node keeps track of whether routes are active. It is cryptography-based protocol that introduces authentication, message integrity, and non-repudiation to an ad hoc environment as part of a minimal security policy. It uses cryptographic certificates from a trusted server to provide authentication and non-repudiation. Ariadne is

Wireless Netw (2010) 16:969–984

another secure reactive routing protocol that was proposed in [8]. It is based on the DSR protocol and uses symmetric cryptography to provide authentication. It authenticates routing messages using one of the three schemes: shared secrets between each pair of nodes, shared secrets between communicating nodes combined with broadcast authentication, or digital signatures. Moreover, Ariadne requires a key distribution center to share secret keys with each node or to broadcast the public keys of nodes to encrypt the data. Another secure routing scheme that incorporates the distributed public key infrastructure (PKI) mechanism and the CBRP routing protocol was proposed in [7]. This scheme can provide the basic security functions like confidentiality, data integrity, authentication and non-repudiation. It guarantees that the system security will not be compromised as long as a number of collaborative adversaries that successfully intrude to the system are less than the predefined threshold. The problem with this scheme is that the number of malicious nodes should be less than a certain threshold for it to function properly. In addition, it does not protect the network from selfish nodes that intentionally drop packets and might risk the network connectivity. The main drawback of the solutions/proposals presented in [7, 8, 23] is their reliance on several assumptions including pre-configuration of nodes with secret keys, cryptography, or the presence of an omnipresent central trust authority. We believe that trust and security are two highly interdependent concepts that are used interchangeably when defining a secure system. To interact with an entity in a network, it is important to investigate its trustworthiness and reliability to judge the correctness of its responses. In wired networks, trust can be and is usually achieved using a trusted third party. However, the reliance on a trusted third party is hard to achieve in spontaneous, infrastructure-less, dynamic ad-hoc networks [15, 21, 24]. Several reputation and trust-based routing schemes were recently proposed [4, 11, 12, 19]. These schemes rely on the reputation and trust value of a node rather than cryptography in order to secure routing. A protocol named CONFIDANT that focuses on the cooperation, robustness, and fairness in MANET was proposed in [4]. CONFIDANT monitors the behaviors of the nodes to evaluate their reputation and punish selfish ones. Nodes learn not only from their own experience, but also from observing the neighborhood and from the experience of their ‘‘friends’’. CONFIDANT was implemented using dynamic source routing (DSR) as the base protocol. Its main disadvantage is that it only deals with selfish nodes and operates in a flat architecture that is inconvenient for huge networks. In [11], Trusted AODV (TAODV) extended the AODV routing protocol by employing a trust model to protect routing behaviors in MANETs. In the TAODV, trust among nodes is dynamic and represented by

971

opinion, which is derived from subjective logic; if a node performs normal communications, its opinion is increased; if it behaves maliciously, it will be ultimately denied by the whole network. Moreover, a trust recommendation mechanism is designed to exchange trust information among nodes. Another trust based routing scheme that extends the DSR routing protocol was proposed in [19]. In this approach, each node in the network autonomously executes a trust model, maintains its own evaluation regarding other nodes through personal experience and shares these trust levels with other nodes. Each sending node uses this trust information to compute the most trustworthy path to a particular destination. However, the routes computed in this manner are neither protected in terms of security nor minimal in terms of hops, but are more trustworthy compared to others and are hence more dependable on an unfamiliar situation. The approaches proposed in [4, 11, 19] are designed to operate in a flat architecture only. A model named 2ACK was proposed in [12] to serve as an add-on technique for the DSR routing protocol to detect misbehaving links and mitigate their effects. Its main idea is to send two-hop acknowledgment packets (2ACK) in the opposite direction of the routing path. To reduce additional routing overhead in the scheme, only a fraction of the received data packets are acknowledged. Indeed, a 2ACK packet is assigned a fixed route of two hops (three nodes) in the opposite direction of the data traffic route as shown in Fig. 1. The triplet N1, N2, and N3 in the figure are three consecutive nodes along a route from a source node, S, to a destination node, D. In DSR, when N1 sends a data packet to N2, N2 will forward it to N3 and N1 will not know whether N3 received the data packet successfully or not. Even though such an ambiguity exists when there are no misbehaving nodes, the problem becomes more severe in the presence of misbehaving nodes. The 2ACK scheme requires an explicit acknowledgment to be sent by N3 to notify N1 of its successful reception of a data packet. Hence, when node N3 receives the data packet successfully, it sends out a 2ACK packet over two hops to N1 (i.e., the opposite direction of the routing path as shown in Fig. 1). The node N1 in the triplet [N1 ? N2 ? N3] monitors the link N2 ? N3. N1 is termed as the 2ACK packet receiver or the observing node and N3 is termed as the 2ACK packet sender. A 2ACK transmission takes place for every set of triplets along the route. To detect misbehavior, the 2ACK

Fig. 1 The 2ACK scheme

123

972

packet sender maintains a list of IDs of data packets that have been sent out but have not been acknowledged. In the example shown in Fig. 1, when the node N1 sends a data packet on a particular path, it adds the packet ID to its list of IDs and increments a counter of the forwarded data packets, Cpkts. At N1, each ID will stay in the list of IDs for s s, the timeout for 2ACK reception. If a 2ACK packet corresponding to this ID arrives before the timer expiration, the ID will be removed from the list. Otherwise, the ID will be removed at the end of its timeout interval and a counter called Cmis will be incremented. When N3 receives a data packet, it determines whether it needs to send a 2ACK packet to N1. Only a fraction of the data packets will be acknowledged via 2ACK packets in order to reduce the additional routing overhead caused by the 2ACK scheme, termed the acknowledgment ratio, Rack. By varying Rack, the algorithm can dynamically tune the overhead of 2ACK packet transmissions. Node N1 observes the behavior of link N2 ? N3 for a period of time termed Tobs, after which N1 calculates the ratio of missing 2ACK packets as Cmis/Cpkts and compares it with a threshold Rmis. If the ratio is greater than Rmis, link N2 ? N3 is declared as misbehaving link and N1 broadcasts a misbehavior report. Each node receiving or overhearing the misbehavior report, marks the link N2 ? N3 as misbehaving link and avoids using it when sending its own data.

3 Proposed cluster based trust-aware routing protocol (CBTRP) In this section, we present our cluster-based trust aware routing protocol (CBTRP) which is a reactive on-demand source routing protocol. To ensure safe routing path, the proposed CBTRP establishes first the basis for a trusted environment by providing a mechanism to distinguish trusted nodes from malicious ones. Then, it organizes the network into one-hop disjoint clusters, whereby every node elects the most qualified and trustworthy node of its 1-hop neighbors to be its cluster-head. Cluster members in CBTRP forward packets only through the trusted clusterheads. However, packets from malicious nodes are not processed and no packet will be forwarded to them. 3.1 Trust in CBTRP Trust in entities is based on the fact that the trusted entity will not act maliciously. In a pure ad-hoc network, nodes that have never met before, can communicate with each other based on mutual trust levels developed over a period of time. In this context, trust has the following characteristics: it is subjective (different nodes may have different perceptions of the same node’s trustworthiness), asymmetric, (two nodes need not have similar trust in each other) and time dependent

123

Wireless Netw (2010) 16:969–984

(it grows and decays over a period of time and is based on previous similar experiences with the same party). In our model, we compute the trust value based upon the information that one node can gather about the other nodes. Vital information regarding other nodes can be gathered by analyzing the received, forwarded, and overheard packets, given that appropriate taps are applied at different protocol layers. A node can get information about the successful transmission of any packet through the following methods [21]: (1) link-layer acknowledgements method in which the underlying MAC protocol provides feedback of the successful delivery of the transmitted data frames, (2) passive acknowledgements method in which the sender node places itself in promiscuous mode after the transmission of any packet to analyze the behavior of the next hop. Analyzing the node’s behavior can show whether the node is selfish, acting like a black hole (i.e., the packet is dumped and not retransmitted), carrying out a modification attack (i.e., if the contents have been fallaciously modified), carrying out a fabrication attack (i.e., if a self generated fallacious packet is transmitted), inducing latency delays by delaying the retransmission of the packet, etc. In CBTRP, the trust between two entities is represented by a 3-dimensional metric opinion [11]: wab ¼ ðbab ; dba ; uab Þ such that bab þ dba þ uab ¼ 1

ð1Þ

where wab denotes node A’s opinion about any node B’s trustworthiness; bab denotes the belief that A holds for B (i.e., the probability that a node B can be trusted by a node A); dab denotes the disbelief that A holds for B (i.e., the probability that a node B cannot be trusted by A); uab denotes the uncertainty that A holds for B (i.e., uncertainty fills the void in the absence of both belief and disbelief). In CBTRP, a node monitors other nodes’ behavior to collect and record all positive (p) and negative (n) events about their trustworthiness. As such, the opinion metrics of wab can be expressed as a function of p and n as follows: p pþnþ2 n a db ¼ pþnþ2 2 uab ¼ pþnþ2 bab ¼

ð2Þ

To calculate the trustworthiness of a node, each of the belief, disbelief and uncertainty values may range between 0 and 1 inclusive. At system initiation, each node holds an opinion value of (0,0,1) for each of its immediate neighbors, with p = n = 0. Every node monitors its immediate neighbors on a regular basis and records the number of positive and negative events. A positive event increases the value p by 1. Positive events correspond to timely forwarding of packets, generation of successful replies, generation of successful

Wireless Netw (2010) 16:969–984

973

Table 1 Criteria for judging trustworthiness Belief

Disbelief

Uncertainty

Action

[ut

Temporarily trust a node

[dt

Distrust a node

[bt Bbt

Trust a node Bdt

But

Temporarily trust a node

acknowledgments, or any specific event a user would like to measure, provided adequate tools are available. On the other hand, negative events increase the value n by 1 and include: refusing to forward packet either to save energy (selfish nodes) or out of malicious behavior, forwarding route requests or replies abnormally (changing packet path), generating route requests or route replies abnormally, modifying data, or any specific event a user would like to measure (provided that adequate tools are available). Every time the number of positive or negative events changes, the corresponding value of opinion will be recalculated using Eq. 2. In CBTRP, the trustworthiness of a node is decided according to Table 1. A node with a belief value greater than the belief threshold (bt) is considered as a trustworthy node whereas a node with a disbelief value greater than the disbelief threshold (dt) is considered to be malicious and no packets will be forwarded through it. When a node has an uncertainty value greater than the uncertainty threshold (ut), the node is considered to be a relatively new neighbor with little interaction or contribution to the network, and thus its trustworthiness is not yet verified. Therefore, packets will be allowed to be forwarded through this node until a level of trust is established. When all of the opinion metrics (belief, disbelief, uncertainty) are less than their relative thresholds, the node’s trustworthiness is not definite, and therefore, the node will be allowed to participate in the network in order to be able to decide whether it should be trusted or not. The belief, disbelief, and uncertainty thresholds can be adjusted with respect to the current network size and percentage of malicious node.

Fig. 2 Cluster structure

maintains a list of all its members along with their trust values, while a cluster member only knows its cluster-head and monitors continuously its trust value. 3.2.1 Cluster formation in CBTRP CBTRP makes use initially of the weighted clustering algorithm (WCA) [5] to elect cluster-heads taking into consideration the ideal degree (number of neighbors), transmission power, mobility, and battery power of mobile nodes. Unlike WCA, CBTRP takes security into account to form trusted clusters. In CBTRP each node calculates its own weight Wv as follows: Wv ¼ w1 Dv þ w2 Dv þ w3 Mv þ w4 Pv

ð3Þ

where 3.2 Clustering in CBTRP In our proposed CBTRP, each cluster has exactly one cluster-head which is one hop away from all its cluster members as shown in Fig. 2. Each cluster is identified by the ID of its cluster-head and each cluster-member belongs to one cluster only. Since cluster-heads are subjectively elected by nodes, it is possible for two cluster-heads to be 1-hop neighbors. At any time, a node may hold one of two statuses; cluster-head or cluster-member, except at system initiation, where all nodes hold a status of undecided. Nodes that are within the transmission range of two clusterheads are called gateways, and they usually handle intercluster communication. As all other nodes in the network, a gateway may belong to one cluster only. A cluster-head

Dv is the Degree Difference between the number of immediate neighbors and the number of nodes that a cluster-head can ideally handle (d). Dv is the Sum of Distances between a node and all its immediate neighbors. The motivation of Dv is mainly related to energy consumption. It is known that more power is required to communicate to a larger distance. Mv is Mobility/Speed of a node. A node with less mobility is always a better choice for a cluster-head. Pv is the Battery Powerof a node. A cluster-head is supposed to consume more battery power than an ordinary node since it has extra responsibilities to carry out. Note that the weighing factors (w1, w2, w3, and w4) are chosen arbitrarily such that w1 ? w2 ? w3 ? w4 = 1. The

123

974

Wireless Netw (2010) 16:969–984 Table 2 Neighbor table of node A ID

Role

Weight

p

n

bAB

dAB

uAB

Timer

Table 3 Cluster adjacency table (CAT) ID of adjacent CH

Gateway node

Table 4 Two-cluster-away table ID of the two-cluster-away CH

Gateway node

Fig. 3 HELLO packet

contribution of the individual components can be tuned by choosing the appropriate combination of the weighing factors. In CBTRP, each node calculates its weight and broadcasts it periodically in a HELLO packet to all nodes in its transmission range. The HELLO packet is shown in Fig. 3 and contains: 2-bit field S that represents the Role/Status of A (its value can be 0 for Undecided, 1 for Cluster Head, 2 for Cluster Member); 4 byte-field that represents Cluster ID of A (we assume that the node ID is its IP address); 2 bytefield that represents the weight of A; 1 byte-field (1 hope neighbs) that represents the number of A’s 1-hop neighbors included in the packet; 1 byte-field (Adj. CHs) that represents the number of adjacent CHs included in the packet; the IDs of A’s 1-hop neighbors (4 byte field for each) along with their role (1 bit-field for each) from its neighbor table; the IDs of cluster heads that are adjacent to A’s cluster head. In addition, each node A in the network maintains three tables: a neighbor table, a cluster adjacency table (CAT), and a two-cluster-away table. The neighbor table (see Table 2) is a conceptual data structure employed to record the opinion about each 1-hop neighboring node B. This information will be utilized for cluster formation and route discovery. Each entry in the table contains information about a 1-hop neighbor. It contains the ID of the 1-hop neighbor; its role which can be a cluster-head, clustermember, non-member or undecided; its WCA weight; its number of registered positive events (p); its number of registered negative events (n); the belief value (bAB) that node A has on its 1-hop neighbor B, which is dependent on p and n; the disbelief value (dAB) that node A has on its 1-hop neighbor B which is dependent on p and n; the uncertainty value (uAB) that A has on its 1-hop neighbor B, which is dependent on p and n; and finally a timer that is used to clean the table if node A does not hear from its 1-hop neighbor node B for a period of time. The cluster adjacency table (CAT) (Table 3) of a node is used to keep information about its adjacent clusters. The CAT table of a node records the ID of each of its adjacent CHs and the corresponding gateway to reach it. These tables are used during route discovery and data forwarding to avoid malicious nodes.

123

By examining the HELLO packets received from its neighbors, a node can gather information about the twocluster away nodes and stores them in its two-cluster-away table (see Table 4) which includes the ID of each Two-cluster away CH, and the ID of the intermediate gateway node to reach it. The two-cluster-away table is used to modify the source route in case any of its nodes becomes malicious. The cluster formation algorithm of CBTRP is shown in Algorithm 1. It can be described as follows. At system initiation, each node is assumed to hold an undecided status and an opinion of (0,0,1) to each of its 1-hop neighbors. Each node

Wireless Netw (2010) 16:969–984

975

calculates its own weight using Eq. 3 and broadcasts it in a HELLO packet to its 1-hop neighbors. When a node receives the weights of its 1-hop neighbors, it inserts them in the possible CH set, which includes all potential cluster-heads. Each node then finds the node with minimal weight from its possible CH set and checks its opinions values. If its disbelief value is less than dt, this node is elected as cluster-head. Otherwise, if its disbelief value is greater than dt, it is disqualified, and the second node with minimal weight in the possible CH set is examined similarly. A node may elect itself as a cluster-head if none of its 1-hop neighbors are available or qualified; i.e., the node itself has the minimal weight. Upon receiving a HELLO packet a node updates its neighbors, two-cluster-away, and cluster adjacency tables as shown in Algorithm 2. 3.2.2 Cluster maintenance in CBTRP Since we are dealing with a vulnerable network, clusterheads could become malicious, and thus threaten the network connectivity. In CBTRP, a node should change its cluster-head when the latter becomes malicious (i.e. disbelief value [ dt) by invoking an algorithm called local cluster formation algorithm (Algorithm 3) to avoid the overhead caused by reinvoking the cluster formation algorithm (Algorithm 1) by all the nodes in the network. In the local cluster formation algorithm, the node seeking to change its malicious cluster-head, finds the node with minimal weight amongst its 1-hop neighbors. If such node satisfies the trust conditions of Table 1, it will be forced to become a cluster-head to avoid the creation of multiple cluster-heads with no members. This happens because whenever a cluster-head becomes malicious, most of its former members whose 1-hop neighbors are cluster-members, would become cluster-heads. This would contradict the purpose of using a hierarchical model to reduce traffic and dedicate routing to the few special nodes. As a result of the local cluster formation algorithm, the new formed cluster will include a cluster-head with one member, but will eventually grow to include several other nodes. Since MANETs have a dynamic topology, CBTRP handles the mobility of the cluster-members and cluster-heads. Indeed, when a cluster member does not hear its cluster-head within its transmission range, it seeks to join a new cluster. If it is 1-hop away from a trusted cluster-head, it will attempt to join it, however, if no adjacent cluster-heads are present, it invokes the local cluster formation algorithm (Algorithm 3). A node in a free zone with no adjacent neighbors elects itself as a cluster-head. A gateway node that is within the transmission range of two cluster-heads is allowed to join the cluster with the highest trust value. At anytime, if a

123

976

Wireless Netw (2010) 16:969–984

cluster-head has no members anymore, it tries to merge with another trusted cluster within its transmission range to minimize the presence of clusters with no members. If it fails, then it remains as a cluster-head. 3.3 Routing in CBTRP Our proposed CBTRP forwards packets through trusted cluster-heads only, identifies malicious nodes, and forms new routes to detour from them. CBTRP is a source routing based protocol. Source routing allows packet routing to be trivially loop-free, avoids the need for up-to-date routing information in the intermediate nodes through which packets are forwarded, and allows nodes forwarding or overhearing packets to cache the routing information for their own future use, since the source route will be included in the header of each data packet. 3.3.1 Route discovery Route discovery is the mechanism whereby a source node S wishing to send a packet to a destination node D, obtains a source route to D which includes all intermediary nodes in the source header. However, in order to isolate malicious nodes from participating in the network, their 1-hop neighbors will ignore all packets received from them, and will attempt to find a route that does not include intermediary misbehaving nodes. The route discovery in CBTRP is done through flooding cluster-heads only with route request packets (RREQ). The RREQ packet is shown in Fig. 4 and includes the following fields: the packet type PT (10 value means route request); the number of Gateway Node Address and Adjacent Cluster Address pairs Num1; the number of Cluster Addresses Num2; the identification field to match the route request with the correspondent route reply; the destination address; the addresses of gateway nodes that will forward this RREQ; the addresses of the corresponding cluster-

Fig. 4 Route request (RREQ) packet

123

Fig. 5 Flooding cluster-heads with (RREQ) packets

heads to which the gateway nodes will forward the RREQ; and finally the addresses of the CHs that form the route to the destination (each CH appends its address to the RREQ packet using a Cluster Address[] field). To perform route discovery to destination D, the source node S sends out an RREQ, with the Target Address field set to D, and then fills the packet entries depending on its current role. If the node S is a cluster-head, it would first record its address in the Cluster Address[1] list, then use its CAT table to record, in the Neighboring Cluster Head[i] and Gateway Node Address[i] fields, the addresses of its adjacent cluster-heads and their corresponding gateways respectively. On the other hand, if the node S is a member node like the case in Fig. 5, it will record its cluster-head ID in both Gateway Node Address[1] and Neighboring Cluster Head[1] and then include, in the Neighboring Cluster Head[i] and Gateway Node Address[i], the addresses of its adjacent clusters’ CHs and their corresponding gateways respectively. If the sender node is also a gateway (i.e., has several neighboring cluster-heads), it would include their addresses in the Gateway Node Address[i] and Neighboring Cluster Head[i] fields. Before recording any node in the RREQ packet, each node checks that the recorded entry does not have a disbelief value greater than dt. Upon the receipt of a RREQ packet from a trusted node, a gateway node either unicasts it to the destination node, if it is its neighbor, or forwards it to the next corresponding cluster-head indicated in the packet. If a cluster-head receives a RREQ packet that it has previously received, it drops it, otherwise, it adds its address to the request using

Wireless Netw (2010) 16:969–984

977

the Cluster Address[i] list, as shown in Algorithm 4. In this algorithm, each cluster-head node forwards an RREQ packet only once and never forwards it to a node that has already appeared in the recorded route.

Fig. 6 Route reply (RREP) packet

Fig. 7 RREP packet from the destination node to the source node

Since RREQ packets are broadcasted, it is difficult to prevent malicious nodes from receiving such packets. Therefore to solve this problem, any RREQ packet received from a malicious node (i.e. dAB [ dt) will be dropped by its 1-hop neighbors, thus isolating such nodes from the network. This will limit the establishment of routes with intermediary malicious nodes. When the destination node D receives the RREQ, it sends out a routing reply packet (RREP) to the sender S through the cluster-head addresses appended to the RREQ as shown in Fig. 7. The RREP packet format is shown in Fig. 6. It includes the packet type (01 for Route Reply), the number of Cluster Addresses Num1, a G flag to indicate whether the route was repaired from malicious intermediary nodes, the number of addresses Num2 in Calculated Route, the identification number copied from the corresponding RREQ, the Cluster Addresses copied from the corresponding RREQ which represents the sequence of

clusterheads the RREP will traverse to reach the RREQ source node; and finally the Calculated Source Route addresses which is a sequence of addresses calculated by the clusterhead and will be used by the source node to send data to the destination. D copies the list of Cluster Addresses from the RREQ packet into the RREP packet. D also copies the identification field in RREQ to RREP and puts its own address in Calculated Route[1]. The recorded Cluster Addresses give the complete information about the sequence of clusters that RREP should traverse in order to reach S. Whenever a gateway node receives a RREP packet, it records its address in the Calculated Route[i] and either forwards the packet directly to S (if it is 1-hop away from it) or it sends it to the next neighboring Cluster Address mentioned in the packet. On the other hand, if a cluster-head receives a RREP, it first records its id in the Calculated Route[i] and checks if S is one of its member. If so, it forwards the packet directly to S; otherwise, it tries to find a route to

123

978

Wireless Netw (2010) 16:969–984

reach the farthest recorded node in the Cluster Addresses list to minimize the route to S. If it succeeds, it sends the packet to that node; otherwise, it sends it to the gateway that reaches the next Cluster Address mentioned in the RREP packet. This process continues till the RREP packet reaches S. Similar to RREQ packets, any RREP packet initiated or received from a malicious node (i.e. dBA [ dt) will be dropped by its 1-hop neighbors, so that the source node will not eventually receive a route with intermediary malicious nodes present in it. If a source node does not receive any RREP after sending out the RREQ for a certain period of time, it resends the RREQ. As usual, all source routes learned by a node are kept in a Route Cache. When a node wishes to send a packet, it always examines its own cache first before performing Route Discovery. 3.3.2 Data forwarding As soon as the source node receives the RREP packet, it enters the packet’s source route into its cache and inserts the route in the data packet shown in Fig. 8. The data packet header contains a packet type (00 for data packet), the number of addresses in the source route Num, a flag N to indicate if no safe route has been found to forward the packet toward the destination, a flag R to indicate if this route has been salvaged from a malicious node, the number of currently visited address, and finally the addresses of the source route from 1 to Num. The actual routing is done using Source Routing such that each node underlined in the packet forwards it to the next specified address until the destination node is reached (see Fig. 6). Since malicious nodes are not allowed to forward neither RREQ nor RREP packets, the source route initially will not include intermediary malicious nodes. However, since the route is stored in the cache, some intermediary nodes might eventually become malicious. In CBTRP the source address includes either a cluster-head, gateway, source node or destination node. Therefore, the source route is limited to these selected nodes, which helps in controlling the safety and maintenance of the route.

3.3.3 Handling intermediary malicious nodes

Fig. 8 Source route packet

123

Handling intermediary malicious nodes is highlighted in Algorithm 5. In this algorithm, if a node A receives a data packet from a malicious node M, it drops it, since that node might have fabricated a data packet or hampered with its

Wireless Netw (2010) 16:969–984

979

data. Otherwise, if A discovers that the next hop in the source route packet is malicious, it tries to find another trustworthy intermediary node to reach next ’next hop’ in the source route by looking at its Two-cluster-away table or by searching its cache for a route to the destination. If it is successful, A modifies the source route and sets the R flag in order to inform the source and destination nodes of the changes in the route. For example, in Fig. 7 the initial source route from source node 2 to destination node 10 is [1–3, 9, 10]. If node 3 becomes malicious, node 1 will try to reach node 9 via another trustworthy intermediary node. This can be accomplished by checking the Two-CHs away table of node 1 which indicates that node 9 is a neighboring CH to one of node 1’s adjacent clusters and can be reached via node 4. Subsequently node 1 modifies the source route to [1, 2, 4, 6, 9, 10] and forwards the packet to the gateway node 4. If A is not able to find any route to the destination that does not include the malicious node, it sends the data packet with the N flag set to the source S that has originally initiated the packet, which in its turn tries to find an alternative route to the destination. If it fails, S waits for a back-off time before doing another route discovery during which the network topology might have changed, possibly introducing new trusted intermediary nodes on the route from the source node to the destination. When a destination node receives a source route data packet with the R flag set, it sends back a gratuitous RREP packet, by setting the G flag in RREP, to S, containing the repaired route to inform S of the new route and avoiding unnecessary route re-discovery. As such, our algorithm ensures that the data packet will eventually traverse through a trusted route until it reaches its destination.

4.1 Simulation environment

4 Performance analysis

Table 5 Simulation parameters

The parameters used in most of the simulation experiments are summarized in Table 5 along with their default values. We have simulated a wireless ad hoc network area with the size of 700 m 9 700 m. The number of mobile nodes in the network is 50 nodes in general, but in some experiments, may reach 150 nodes. The MAC type of the ns-2 nodes is set to MAC/802_11. The node transmission range is 250m. The belief (bt), disbelief (dt), and uncertainty (ut) thresholds were assumed to be 0.5. When the simulation begins, a certain percentage of nodes rm is regarded as malicious. For simplicity, we assume that the malicious nodes are those that are behaving selfishly by intentionally dropping packets. Observation is done through promiscuous mode by inserting a tap on the MAC layer to monitor the behavior of neighboring nodes and register the number of forwarded/dropped packets. During the simulations, the source and the destination nodes were randomly chosen among all nodes in the network. For each data point in the results, 10 simulation runs were performed, then the average value was computed. This number of runs was computed using the central limit theorem [1] and is required to achieve 90% confidence level with the ?/precision values for the PDR and the RO were chosen as 1% and 6% respectively. We have evaluated the performance using two types of traffic: constant bit rate (CBR) and TCP. The experiments in which constant bit rate (CBR) traffic was used, included 10 CBR sessions each while the experiments in which TCP traffic was used, included 10 Telnet sessions each. Each session generated four packets per second. The mobility scenarios were generated by the ‘‘random trip’’ generic mobility model due to Palchaudhuri et al. [15]. As for the

Simulation time

In this section, we evaluate the performance of the proposed CBTRP using the Network Simulator (NS-2) [14] and compare it to that of the CBRP and the 2ACK routing protocols proposed in [9] and [12] respectively. It is worth noting that the 2ACK source code was obtained from the authors of [12]. In this evaluation, we are mainly interested in the packet delivery ratio (PDR) of the network to measure the network performance in the presence of malicious nodes. packet delivery ratio is defined as the ratio of the number of packets received at the destination to the number of packets sent by the source. We also measure the routing overhead (RO) which is defined as the ratio of the amount of routing related traffic to the total amount of packets including the forwarded and transmitted packets.

800 s

Simulation area

700 m 9 700 m

Number of nodes

50, 75, 100, 125, 150

Transmission range

250 m

Movement model Maximum speed

Random waypoint 20 m/s

Pause time

0s

Traffic type

CBR(UDP) and TCP

Payload size

512 bytes

Packet rate

4 pkt/s

MAC type

Mac/802_11

Bandwidth

11 Mbps

Antenna

Omni-antenna

Radio propagation model

Two ray ground

Max # of malicious nodes

40% of nodes

123

980

clustering variables, we borrowed the weighing factors and d from WCA [5] to compute Eq. 3 as follows: w1 = 0.7, w2 = 0.2, w3 = 0.05, w4 = 0.05 and d = 10. 4.2 Measuring PDR in presence of malicious nodes with UDP traffic In this experiment, we evaluate the impact of malicious nodes on the network with UDP traffic by varying the ratio of malicious nodes rm while measuring the packet delivery ratio. The results obtained with CBTRP are compared with those of CBRP and 2ACK. The number of nodes used in this experiment is 50. rm was varied from 0 (all of the nodes are well-behaved) to 0.4 (40% of the nodes are misbehaving). The maximum speed was Vmax = 20m/s. Figure 9 shows that most packets were delivered by CBTRP and CBRP when rm = 0 (no misbehaving nodes), however, the packet delivery ratio decreased as rm increased. Nevertheless, compared to CBRP, the CBTRP scheme maintained a much higher PDR. For example, the CBTRP scheme delivered over 74% of the data packets when rm = 0.4 compared to 59% with CBRP. This is due to the fact that CBRP does not have a mechanism to detect misbehaving nodes. Therefore, it may choose an alternate route which still contains misbehaving nodes. On the other hand, the drop in PDR for CBTRP can be easily justified as follows. When rm increases it becomes harder to find routes free of malicious nodes from the source to the destination. Moreover, CBTRP outperformed the 2ACK in all scenarios, except when rm = 0.4, where their performance was similar. The low performance of the 2ACK scheme was due to the network mobility of Fig. 9 Packet delivery ratio of CBTRP, CBRP, and 2ACK with UDP traffic

123

Wireless Netw (2010) 16:969–984

Vmax = 20m/s which affected negatively its performance. Indeed, the 2ACK scheme detects misbehaving links rather than nodes, however links are continuously changing with network mobility. In addition, the source route chosen in the 2ACK scheme may include some highly mobile nodes while the advantage of CBTRP is that it elects cluster-heads with low mobility to handle packet forwarding. 4.3 Measuring PDR in presence of malicious nodes with TCP traffic This experiment is similar to the above, however, TCP traffic is used instead. Figure 10 shows that the PDR values are relatively close for all schemes with CBTRP outperforming CBRP and 2ACK. The high level of PDR is logical and can be justified as follows. In TCP, the senders slow down or even stop their transmissions when the acknowledgments from the destination are not received. We observe that the proposed CBTRP supports a higher PDR for the TCP traffic than for the UDP traffic. This is due to the additional acknowledgments and reliability of the TCP protocol. 4.4 Measuring scalability In this experiment, we evaluate the scalability of the proposed CBTRP by measuring the packet delivery ratio (PDR) while increasing the number of nodes in the network from 50 to 150 and fixing rm to 0.3 (i.e 30% of nodes are malicious). The maximum speed was set to Vmax = 20 m/s

Wireless Netw (2010) 16:969–984

981

Fig. 10 Packet delivery ratio of CBTRP, CBRP and 2ACK with TCP traffic

Fig. 11 Scalability measure of CBTRP, CBRP, and 2ACK

and the traffic used was UDP. Figure 11 shows that CBTRP outperforms both CBRP and 2ACK in all scenarios. The CBTRP scheme performed best with 150 nodes in the network and delivered over 81% of packets. On the other hand 2ACK performed best with 50 nodes and worst with 100 and 150 nodes, delivering only 71% of packets. This is due to the fact that the 2ACK operates in a flat architecture in which the flooding that occurs during route discovery overloads the network, thus causing some packet loss. These results confirm the theory that the cluster based architecture performs better in large networks, even though when the number of malicious nodes increases. We observe also that CBRP performed best with 75 and 150 node, with around 68% of packet delivery. This is due to the fact that CBRP cannot detect misbehaving nodes, therefore, it may

Fig. 12 Routing overhead of CBTRP, CBRP and 2ACK

choose an alternate route which still contains misbehaving nodes, thus dropping the packet delivery rate. 4.5 Routing and clustering overhead In this experiment, we measure the clustering and routing overhead resulting from CBTRP, CBRP, and 2ACK using UDP traffic while varying rm from 0 (all of the nodes are well-behaved) to 0.4 (40% of the nodes are misbehaving). The number of nodes is set to 50. The speed is set to Vmax = 20 m/s. Figure 12 shows the minimal routing overhead caused by CBTRP and CBRP. With 40% of the nodes malicious, only around 1.4% of the whole network traffic is related to routing information. CBTRP and CBRP, with their cluster based architecture, greatly reduce traffic

123

982

Wireless Netw (2010) 16:969–984

Fig. 13 Clustering overhead of CBTRP Fig. 14 Packet delivery ratio of CBTRP for different Vmax

since the route discovery process involves cluster-heads and gateways. On the other hand, when the number of malicious nodes is 40% the 2ACK scheme caused a routing overhead of approximately 29% of the network traffic. This is due to (1) its flat architecture which floods the network with routing packets during the route discovery process, and (2) the 2ACK packets which are used to discover malicious nodes. Figure 13 shows the traffic overhead caused by the cluster formation and maintenance of CBTRP. It shows that the clustering overhead caused is very minimal and increases from 0.06% when there are no malicious nodes in the network to 0.09% when 40% of the nodes are malicious. 4.6 Impact of velocity on PDR In these experiments, we study the impact of mobility on the performance of the CBTRP. We measure the PDR as the velocity of nodes alters while using UDP traffic. The number of nodes was set to 50. In Fig. 14 we measure the PDR of CBTRP while varying rm from 0 (all of the nodes are wellbehaved) to 0.4 (40% of the nodes are misbehaving) and fixing the speed to Vmax = 0 m/s in one experiment, to Vmax = 10 m/s in a second experiment, and to Vmax = 20 m/s in a third one. The figure shows that CBTRP performs best when Vmax = 10 m/s and worst when Vmax = 0 m/s. This is due to the fact that when the network is static, the node’s neighbors do not change. Therefore, if a certain node is surrounded by malicious nodes, it will not find any trusted route to forward its packets through, thus influencing negatively the packet delivery ratio (This issue is a subject of consideration for our future work). On the other hand, when the network is mobile, the probability of finding a route with no malicious nodes increases, since nodes will continuously have new neighbors, thus the improved performance with Vmax = 10 m/s and Vmax = 20 m/s. In Fig. 15, we measured the PDR of CBTRP and 2ACK while varying the velocity of nodes from 0 to 20 m/s and fixing rm to 0.3. The figure shows that CBTRP performed worst when the network was stable, and best when the

123

Fig. 15 Velocity impact on PDR in CBTRP and 2ACK

nodes were mobile, which complies with our above interpretation. On the other hand, mobility had a negative effect on 2ACK and caused a great loss in packet delivery, as explained previously.

5 Conclusion and future work In this paper we have proposed a cluster-based trust-aware routing protocol that provides improved connectivity in MANETs in the presence of malicious nodes. The proposed protocol ensures the passage of packets through trusted routes only by making nodes monitor the behavior of each other and update their trust tables accordingly. Once a malicious node is discovered, it is isolated from the network such that no packet is forwarded through or from it. The proposed protocol was implemented and integrated with NS2. Its performance was evaluated through intensive simulations which focused on measuring the impact of scalability and mobility in the presence of malicious nodes on the packet delivery ratio and the incurred overhead. CPTRP results were compared with those obtained from the 2ACK scheme [12] and the CBRP protocol [9]. Comparison showed that CBTRP protocol outperformed both the 2ACK and the CBRP schemes in most of the simulation scenarios.

Wireless Netw (2010) 16:969–984

In our future work we will address the fact that when the number of isolated malicious nodes increases, some nodes may find themselves totally surrounded by malicious neighbors and cannot participate effectively in the network. Several mechanisms may be used to solve this issue. One solution can be making the nodes that are totally surrounded by malicious neighbors adjust dynamically their belief and disbelief thresholds. Another solution is to give malicious nodes a chance to repent, by letting them broadcast repent packet to their 1-hop neighbors, which can place them on a probation period before deciding whether to forgive them or not.

References 1. Andel, T. R., & Yasinac, A. (2006). On the credibility of manet simulations (Vol. 39, pp. 48–54). Los Alamitos, CA: IEEE Computer Society Press. 2. Arsenault, A. & Turner, S. (2000, November). Internet x.509 public key infrastructure. Internet Engineering Task Force (IETF). 3. Bhargava, B., Zoltowski, M., & Meunier, P. (2002). Trusted routing and intruder identification in mobile ad hoc networks. Research proposal for cerias 2002. Purdue University. 4. Buchegger, S. & Le Boudec, J.-Y. (2002, June 09–11). Performance analysis of the confidant protocol. In Proceedings of the 3rd ACM international symposium on mobile ad hoc networking & computing (MobiHoc ’02) (pp. 226–236), Lausanne, Switzerland. 5. Chlamtac, I., Conti M., & Liu, J. (2003, July). Mobile ad hoc networking: Imperatives and challenges. Ad Hoc Networks 1(1), 13-64. 6. Chatterjee, M., Das, S. K., & Turgut, D. (2002, April). WCA: A weighted clusrering algorithm for mobile ad hoc networks. Journal of Cluster Computing, 5, 193–204. 7. Hahn, G., Nyang, D., Song, J., Lee, J., & Park, B. (2004, May 12– 15). Secure cluster based routing protocol incorporating the distributed pki mechanisms. In Proceedings of the 12th IEEE mediterranean electrotechnical conference (MELECON 2004) (pp. 787–790), Dubrovnik, Croatia. 8. Hu, Y.-C., Perrig, A., & Johnson, D. (2005, January). Ariadne: A secure on-demand routing protocol for ad hoc networks. Wireless Networks 11, 21–38. 9. Jiang, M., Li, J., & Tay, Y. C. (1999). Cluster based routing protocol(cbrp). Internet Draft, MANET working group. 10. Johnson, D. B., & Maltz, D. A. (1996). Dynamic source routing in ad hoc wireless networks. In T. Imielinski & H. Korth (Eds.). Mobile computing (Vol. 353). Kluwer. 11. Li, X., Lyu, M. R., & Liu, J. (2004, March 6–13). A trust model based routing protocol for secure ad hoc networks. In Proceedings 2004 IEEE aerospace conference (pp. 1286–1295), Big Sky, MT, USA. 12. Liu, K., Deng, J., Varshney, P. K., & Balakrishnan, K. (2007, May). An acknowledgment-based approach for the detection of routing misbehavior in MANETs. IEEE Transactions on Mobile Computing, 6, 536–550. 13. Liu, W., Chiang, C., Wu, H., & Gerla, C. (1997, April). Routing in clustered multihop mobile wireless networks with fading channel. In IEEE Singapore international conference on networks (SICON’97) (pp. 197–211).

983 14. NS-2 Simulator. (2006). http://www.insi.edu/nsnam/ns. 15. Palchaudhuri, S., Le Boudec, J. Y., & Vojnovic, M. (2005, April 4–6). Perfect simulations for random trip mobility models. In Proceedings of the 38th annual simulation symposium (pp. 72– 79), San Diego, CA, USA. 16. Park, C., Lee, Y. H., Yoon, H., Choi, D. S., & Jin, S. H. (2005, February). Cluster-based trust evaluation in ad hoc networks. In 7th international conference on advanced communication technology. LNCS (pp. 503–507). 17. Perkins, C., & Bhagwat, P. (1994, August 31–September 2). Highly dynamic destination-sequenced distance-vector routing (dsdv) for mobile computers. In ACM SIGCOMM’94 conference on communications architectures, protocols and applications (pp. 234–244), London, UK. 18. Perkins, C. E., & Royer, E. M. (1999, February 25–26). Ad-hoc on-demand distance vector routing. In Proceedings of the second IEEE workshop on mobile computer systems and applications (WMCSA ’99) (pp. 90–100), New Orleans, Louisiana. 19. Pirzada, A. A., Datta, A., & Mcdonald, C. S. (2004, November). Trust based routing for ad-hoc wireless networks, In Proceedings of 12th IEEE international conference on networks (ICON’ 04) (pp. 326–330), Piscataway, NJ, USA. 20. Pirzada, A. A., & McDonald, C. (2003, December 8–11). A review of secure routing protocols for ad hoc mobile wireless networks. In Proceedings of 7th international symposium on digital signal processing and communication systems (pp. 118– 123), Brisbane, Australia. 21. Pirzada, A. A., & McDonald, C. (2004, January 18–22). Establishing trust in pure ad-hoc networks. In Proceedings of the 27th Australian conference on computer science (ACSC ’04) (pp. 47– 54), Dunedin, New Zealand. 22. Royer, E., & Toh, C.-K. (1999, September). A review of current routing protocols for ad hoc mobile wireless networks. IEEE Wireless Communications and IEEE Personal Communications, 6, 46–55. 23. Sanzgiri, K., Dahill, B., Levine, B. N., Shields, C., & BeldingRoyer, E. M. (2002, November). A secure routing protocol for ad hoc networks, In Proceedings of the 10th IEEE international conference on network protocols (pp. 78–87), Paris, France. 24. Theodorakopoulos, G., & Baras, J. S. (2004). Trust evaluation in ad-hoc networks. In Proceedings of the 2004 ACM workshop on wireless security (WiSe ’04) (pp. 1–10), New York, NY, USA. 25. Virendra, M., Jadliwala, M., Chandrasekaran, M., & Upadhyaya, S. (2005, April 18–21). Quantifying trust in mobile ad-hoc networks. In Proceedings of the international conference on integration of knowledge intensive multi-agent systems (KIMAS) (pp. 65–70), Weltham , MA, USA.

Author Biographies Haidar Safa received a B.Sc. in Computer Science in 1991 from Lebanese university, Lebanon, M.Sc. in Computer Science in 1996 from University of Quebec at Montreal (UQAM), and a Ph.D. in Electrical and Computer Engineering in 2001 from Ecole Polytechnique de Montreal. He joined ADC Telecommunications and SS8 Networks in 2001 where he worked on designing and developing networking and system software. In 2003, he joined AUB where he is currently teaching and doing

123

984

Wireless Netw (2010) 16:969–984

research in Networking. Dr. Safa is also associated with the Mobile Computing and Networking Research Laboratory (LARIM), Ecole Polytechnique de Montreal, Montreal, Canada. His research interests include mobility management in wireless networks, distributed computing, quality of service, plus routing and network security.

Hassan Artail worked as a system development supervisor at the Scientific Labs of DaimlerChrysler, Michigan before joining AUB in 2001. At DaimlerChrysler, he worked for 11 years in the field of software and system development for vehicle testing applications, covering the areas of instrument control, computer networking, distributed computing, data acquisition, and data processing. He obtained a B.S. and M.S. in Electrical Engineering from the

123

University of Detroit in 1985 and 1986 respectively and a Ph.D. in Electrical and Computer Engineering in from Wayne State University in 1999. His research is in the areas of Internet and Mobile Computing, Distributed Computing and Systems, and computer networking and security.

Diana Tabet finished the Master degree in Computer Science from the American University of Beirut in 2007. She is currently a research associate at the American University of Beirut. Her research interests are in computer networking and application software development.