FESCIM: Fair, Efficient, and Secure Cooperation Incentive Mechanism for Multi-hop Cellular Networks ABSTRACT In Mobile Ad Hoc

Networks (MANETs), nodes depend on each other for routing and forwarding packets. However, to save power and other resources, nodes belonging to independent authorities may behave selfishly, and may not be willing to help other nodes. Such selfish behavior poses a real threat to the proper functioning of MANETs. One way to foster node cooperation is to introduce punishment for selfish nodes. Another effective way to solve the selfish-node problem is to reward nodes for their service according to their cost. To force nodes to show their true cost, truthful protocols are needed. A low overhead truthful routing protocol to find optimal routes is proposed here. Multi-hop cellular network is a promising architecture aiming to improve the performance of current cellular network. However, there are many security challenges due to the participation of the mobile nodes in the routing process. Our protocol uses dynamic identities to enable the mobile nodes to send their packets anonymously without identifying the sender and receiver, and to authenticate themselves without revealing their real identities. Routing and data forwarding are two basic functions of networks. Data communication therefore usually involves multi-hops between nodes.

In such a system, without the forwarding help of nodes, communication beyond a nodes radio range is impossible. Thus a selfish node is not willing to forward data to other nodes freely, although it may expect service from other nodes. A selfish node is distinct from a malicious node, which intends to destroy the network or harm other nodes. When a minority of nodes engages in selfish behavior, network performance will be degraded, but when the majority of nodes exhibit selfish behavior, the collapse of the network may result. Thus selfish nodes pose a real threat to the correct functioning of ad hoc networks. A simple way is to reimburse each node equally for packet forwarding. So, depending on the number of the successful forwarding acknowledgement, a node will be rewarded accordingly.

INTRODUCTION Wireless communication technology has made great gains in popularity over the past decade and will be playing a more important role in access networks, as evidenced by the widespread adoption of cellular networks, Wireless Local Area Networks (WLANs) and Worldwide Interoperability for Microwave Access (WiMAX) [Tane04]. A common feature of these wireless technologies is the presence of a base station (BS) and central control. Users of these wireless access networks expect high quality, reliability, and easy access to high-speed services anytime, anywhere, and in any form. Cellular and Multi-hop Cellular Networks Mobile communications are facilitated by cellular networks. These networks basically consist of mobile terminals, BSs, the radio network controller (RNC) and the core network. A region that is being served is divided into sub-regions, called cells. Each cell is covered by a BS and is allocated a number of channels for mobile terminals to communicate with the BS. A mobile terminal communicates with another mobile terminal, a landline phone of the Public Switched Telephone Network (PSTN), or the Internet through the BS and the RNC. RNC and the core network are developed for third generation (3G) cellular systems to facilitate both voice and data services and to provide better radio resource management, handoff, and security. In first generation (1G) and second generation (2G) cellular systems, the mobile switching centre (MSC) is used instead of the RNC. Figure 1 illustrates the system architecture of a 3G cellular system.

In 3G networks, the wideband code division multiple access (WCDMA) technology is used. The technology allows higher frequency reuse and higher data-rates than that of 1G frequency division multiple access (FDMA) and 2G time division multiple access (TDMA) technologies. In 3G networks, frequency division duplex (FDD) and time division duplex (TDD) modes are available.

Figure 1: System architecture of a 3G cellular system Limitations and problems of cellular networks Cellular networks have inherent limitations on cell capacity and coverage. They also suffer from the dead spot problem. Limited capacity also raises the hot spot problem and the issue of radio resource utilization. We discuss these limitations, problems, and issues as follows.

Limited capacity In a cellular network, the capacity of a cell is limited by the number of channels allocated to the cell. The larger the number of channels, the greater the number of users that can be served. The number of channels is limited by the available frequency spectrums and by the frequency reuse factor [Rapp02]. A smaller cell size allows higher frequency reuse and, thus, a higher capacity can be achieved. In a 3G system, the cell capacity is not only limited by the available frequency spectrums, but also by the interference among mobile nodes and the BSs. The higher the interference, the lower the cell capacity is. The hot spot problem - Due to the limited capacity, in dense areas known as hot spots, such as downtown areas and amusement parks, mobile users tend to experience higher call blocking, i.e., call requests are denied. This is because, in hot spots, there are more mobile users than the number of available channels. Radio resource utilization - The hot spot problem in turn raises the issue of radio resource utilization. While there are not enough channels or capacity in a hot spot for serving mobile users, the cells neighboring the hot spot may still have available channels. In other words, the radio resources of neighboring cells are under-utilized. Limited coverage the coverage of cells is limited by the communication range or transmission power of the BS. Mobile users, which are outside the coverage of the BSs, are not able to access the networks. The dead spot problem - Even though mobile users are within the communication range of the BS, there are still some areas where coverage is not available. These areas are often referred to as dead spots such as indoor environments and underground areas.

A possible solution to extend cell coverage and alleviate the hot spot and dead spot problems is to install extra BSs or repeaters in the out-ofcoverage region, congested areas and dead spots. However, such a solution is expensive and may not be flexible to adapt the dynamic traffic load conditions in the networks. A multi-hop cellular network (MCN) [Chan03, De02, Kwon02, Lin00, Safw03, Zhou02] can be an alternative complementary solution in cellular systems. Benefits of multi-hop cellular networks The idea of MCNs is based on multi-hop relaying. The source node signals are relayed through other intermediate nodes to the BS. The intermediate nodes can be fixed, mobile or ad hoc relays. In this way, the capacity can be enhanced, the coverage can be extended, the hot spot and dead spot problems can be alleviated and the radio resource can be better utilized. Figure 1 illustrates general network architecture of a MCN which consists of source nodes, relaying nodes and the BSs. The use of MCNs Enhances capacity - By using the concept of MCN or multi-hop relaying, the cell size can be smaller, which allows higher system capacity in terms of higher frequency reuse [Rapp02]. A higher transmission rate (cell capacity) due to a shorter transmission range can also be achieved. Alleviates the hot spot problem - With multi-hop relaying, congestions in hot spots can be alleviated by relaying the traffic from the hot spots to their neighboring less-congested or non-congested cell through other mobile terminals or relaying devices. The radio resource or available channels in the neighboring cells can also be utilized.

Extends cell coverage Mobile users, in areas where BS coverage cannot be attained, can relay their messages via one or more mobile terminals and/or special stationary devices that have a direct or indirect link to the BS. Alleviates the dead spot problem By using multi-hop relaying, mobile users in dead spots are still able to reach the BS through other intermediate nodes. Is economically desirable In MCNs, the number or the transmission power of the BSs can be reduced. In other words, a simpler infrastructure or cheaper devices can be used. Therefore, MCNs can be more economically

desirable. A study of the economic issues of MCNs can be found in [Li08].

Figure 2: Network architecture of a MCN

Figure 3: Reduction of number of BSs and cell size of a cellular system Multihop routing The relaying technology has been studied intensively for applications in MCNs and is included in most third- and fourth-generation wireless system developments and standardizations. The relay channel was introduced by assuming that there is a source that wants to transmit information to a single destination and a relay terminal that is able to help the destination (relay assisted transmission). The relaying concept is the basis of multihop routing and cooperative transmission too. A routing algorithm in MCN introduces extra signaling overhead when broadcasting route information which adds extra interference. The effect of the interference is normally ignored in MANETs but cannot be neglected in cellular networks. This is mainly because the transmission power of nodes in MCNs can be several orders of magnitude higher than that of nodes in MANETs. In both MANETs and MCNs, the amount of signaling

overhead mainly depends on the chosen routing algorithm. The routing algorithms can generally be classified into two categories: a) proactive routing and b) reactive routing. Proactive routing mechanisms discover and calculate routes all the time. Each node periodically exchanges its routing information with its neighbors by continuously broadcasting hello/topology messages, and thus, its signaling overhead depends on the broadcasting interval and the number of nodes in the network. In MCNs, the radio resources are centrally controlled, and thus, a mobile terminal has to establish a connection with the BS before data is transmitted. In such an environment, reactive routing offers several advantages over proactive routing. Challenges of MCNs Although the MCN concept has many benefits, MCNs raise a number of issues, linked to architectural design, the computation of the cell size, maximizing capacity, higher packet delay, channel assignment, routing, load balancing, power control, assuring quality of service (QoS), and providing security. In particular, the cell size is inversely related to the cell capacity and directly related to the coverage. The combined effect of cell size and cell capacity affects the reachability of source nodes and the demands that can be served, which in turn affect the radio resource utilization and system throughput. The demand can be expressed in terms of the number of calls or the amount of data-rates. Although the cell size is an important design factor, little work has been done in this area. Another important issue in MCNs is channel assignment which determines the packet delay and, thus, affects QoS provisioning in these networks.

Cell size In a cellular network, the cell coverage is basically the cell size or the communication range of the BS. The cell size is inversely related to system or cell capacity. A large cell size decreases frequency reuse in the systems because fewer BSs which reuse the frequency can be installed. In order to avoid signal interference, neighboring cells cannot use the same frequencies or channels. It also requires high transmission power of mobile nodes and BSs and high interference margins to compensate the interference level. In both cases, the cell capacity would be reduced. On the other hand, a small cell size allows high system or cell capacity because the frequency reuse can be increased and the transmission power as well as the interference level decreases. In a MCN, the coverage (or network reachability) not only depends on the cell size, but also the node density and network topology. Although a small cell size has high cell capacity, if the node density is low, most distant mobile nodes do not have relaying paths to reach the BS to use the available and abundant capacity. The utilization of the radio resources and the system throughput are low. Thus, some MCN architectures assume a small cell size with high node density. However, in practice, high node density may not always be the case. In addition, the node density may vary during a day. Thus, the assumption may not be applicable all the time. Some MCN proposals assume a large cell size. But, the benefit of capacity gain of using small cell size cannot be achieved. Thus, finding a cell size to provide an optimal balance among the coverage, capacity and demand to maximize the system throughput and the radio resource utilization is important.

Channel assignment In communications, a channel refers to the medium used to convey information from a sender (or transmitter) to a receiver. In a cellular network, a physical channel is the transmission medium to convey electromagnetic signals from a transmitter to a receiver. In 1G wireless systems, FDMA [Rapp02] is used. A channel is a frequency. As cellular technology evolves, a channel could be referred as a frequency, a time-slot, a code, or a time-slot code pair, depending on which cellular technology is used. The objective of channel assignment in different contexts is different. In a cellular network, channel assignment involves assigning channels to the mobile nodes for communicating with the BS. It may also involve assigning channels to different cells in order to increase the channel reuse. In a MCN, channel assignment involves assigning channels to the source node and relaying nodes on a relaying path to the BS. In a TDD W-CDMA MCN, a channel is presented by a time-slot and a code pair. When a packet arrives at a relaying node, it has to wait for the time-slot allocated for transmission to the next hop node or the destination node. Improper channel assignment causes the collisions of transmission signals, packet losses, and high packet delay which greatly affect the QoS provisioning in MCNs. Routing in SCNs is fairly simple and clearly does not extend to MCNs. The plethora of routing protocols proposed for adhoc networks also fail to provide good solutions for MCNs because they fail to exploit the presence of the highly reliable BSs and the wired backbone. They do not scale very well to a large number of nodes. Ad-hoc routing protocols are mostly aimed at providing stability against path vulnerability, and often trade-off throughput against stability. Paths are much less vulnerable in

MCNs and stability of paths is not of major concern. The division of routing functions between the mobile nodes and the BS plays a crucial role in the performance of the routing protocol. The driving principle behind the routing protocol would be to increase the spatial reuse of the channel and thereby increase the throughput. The current methods for topology discovery used in adhoc networks are typically based on the use of hello beacons which are transmitted periodically. But this method does not scale very well, especially when the density of nodes1 is very high. When a large number of stations fall within the capture area of a given station, the possibility of the hello beacons themselves colliding and getting lost becomes very high. This can have serious consequences because routing cannot be made robust or efcient without up-to-date information about the location of nodes. Thus, there is a trade-off between the frequency at which neighbors can be notied of the nodes presence and the bandwidth that is taken up by these hello packets. The interaction between the mobile nodes and the BS is signicantly different in MCNs. Therefore, some of the solutions used for registration with the BS, maintenance of location databases etc., do not directly apply to MCNs. The assignment of channels coupled with a good hand-off scheme is perhaps the greatest of the challenges in the design of MCNs. The hand-offs will not only happen between two BSs, but more often between an MS and a BS or from one MS to another. These problems are greatly simplied in the case of packet radio services. We have decided to stick with connection-less service for two reasons. Firstly, there are a large number of applications for IP services even in the wireless domain.

More importantly, considering recent advances in time-bounded services with QoS in ad-hoc networks, we feel that it is realistic to assume that soon it will be possible to support real-time multimedia trafc on this architecture. It is an accepted fact that in cellular systems of the future, the radius of the cells is not bounded by the maximum transmission range of a typical mobile device, but rather by the amount of trafc a cell can support. Therefore, it is reasonable to assume that the transmitters on the mobile devices are capable of transmitting data with range. So, we have chosen to provide a separate control channel using which nodes exchange control packets with the BS over a single hop. However, the limit on transmission power for the data channel can be placed dynamically by the BS by broadcasting messages on the control channel. This provides a lot of exibility wherein the MCN can operate as an SCN when the BS thinks it more appropriate to do so. The trafc due to RReq and RRep on the control channel can be greatly reduced by the use of Route Cache (RC) as in other ad-hoc routing protocols. When a node receives a RRep, it adds the route to its RC. Whenever an IP packet is received, the recorded source route is reversed and this reversed route to the source of the packet is added to the RC.These entries in the RC time-out after time and the RReq has to be sent again. Broken routes in the RC can cause serious problems such as dropped packets, out-of-order delivery and wastage of bandwidth. The protocol must also support detection and updation of stale routes in the RC. We have used the following mechanism for this. When a route is broken, it has to be removed from the RC of the originating node. Consider the case when the link on a route is broken. When receives a packet whose next hop , it detects that the link is no longer available either because of a timeout of the hello beacon or because of the maximum

retransmission limit of the RTS. Now,

send an RReq to the BS. The

network layer of rather than dropping the packet, buffers it. The BS responds with a new route . Thus, the RC is updated. No packets are dropped can now empty its buffer and send all the mis-routed packets to it received in the time it takes for the RC to be updated. Research on another kind of wireless network, commonly referred to as ad-hoc or packet radio networks has proceeded independently. Here, Mobile Stations (MSs) can forward packets from other stations to reach the destination in multiple hops. They are particularly attractive because of their low cost of deployment. But such networks do not scale very well and hence their application is limited to very specialized areas like rescue operations, battle elds and traveling groups. As of now, it is very difcult to provide uninterrupted high bandwidth connectivity to a large number of users with these networks and hence they cannot be easily used for Personal Communication Systems (PCS) and the like. Though the limited bandwidth and QoS issues are being addressed in systems such as WAMIS (Wireless Adaptive Mobile Information System), there is still a long way to go before one can even suggest them as a replacement for cellular networks. Initially, service providers could use MCNs for data services and continue with GSM/AMPS for voice calls. Thus, MCNs t very well into the current state of technology, and allow seamless and easy migration. The architecture, Multihop Cellular Network (MCN) originally dened by Lin and Hsu recently comes from a combination of ideas from the two separate directions of research mentioned above. In MCNs, MSs are allowed to communicate without the involvement of the Base Station (BS). The MSs also serve as packet forwarding agents in communication as in adhoc networks

LITERATURE SURVEY Title: Multi-hop cellular: A new architecture for wireless communications Existing System Mobile Information System, have began to address the limited bandwidth and QoS (Quality of Service) issue. An advantage of these networks is their low cost because no infrastructure is required, and, therefore, can be deployed immediately. However, these ad-hoc networks appear to be limited to specialized applications. such as battlefields and traveling groups, due to the vulnerability of paths through possibly many mobile stations. However, this vulnerability can be significantly reduced if the number of wireless hops can be reduced and the station mobility is low. Proposed System: This work presents a new architecture, Multi-hop Cellular Network (MCN). and derives the throughput of MCN and its counterpart. Single-hop Cellular Network (SCN), based on the RTS/CTS access method. The throughput is analyzed by modeling the packet departure process as a renewal process, in which the renewal point is defined as the time point when all stations in a sub-cell simultaneously sense that the channel is idle. Furthermore, mean hop count is analyzed because it significantly influences the throughput of MCN, as confirmed by the numerical results. Analysis and simulation results for the throughput of SCN and MCN lead to three important observations. First, the throughput of MCN is superior to that of the corresponding SCN. Second, the throughput of MCN increases as the transmission range decreases.

Title: Optimal and fair transmission rate allocation problem in multihop cellular networks Existing System We are interested in Pareto-optimal solutions that are solutions where the utility of an individual cannot be improved without decreasing the utility of one or more other nodes. The fairness is a key issue in wireless networks, since the medium is shared among the nodes. In our problem, it implies that each flow going through a bottleneck receives a fair share of the available bandwidth. Our work admits the generalized fairness criterion as defined in that can assume several criteria, for example, the proportional fairness one. Proposed System We have considered in this paper the transmission rate allocation problem for multi-hop cellular networks in a way to reach an optimal and fair solution. We show that it can be reduced to a single-hop problem by only changing the utility functions. We confirm the validity of our proof experimentally. Reducing multi-hop problems into problems with an unique cell (single-hop) has many advantages for the optimization problem. First we can reuse techniques that were designed basically for the one-cell case. Second, we can identify bottlenecks, and in particular see if congestion is due to the particular situation of a relay node, or to the specific utility function of the terminals it relays.

Title: Integrated cellular and ad hoc relaying systems: iCAR Existing System The presence of unbalanced traffic will exacerbate the problem of limited capacity in existing wireless systems. Ina cellular system, an MH can use only the data channels of the base transceiver station (BTS) located in the same cell, which is a subset of the data channels available in the system. No access to data channels in other cells by the MH limits the channel efficiency and consequently the system capacity. Specifically, some cells may be heavily congested (called hotspots), while the other cells may still have enough available DCHs. Proposed System: We have proposed a novel architecture for next-generation wireless systems called iCAR which integrates the traditional cellular and modern relaying technologies. We have also evaluated the performance improvement of iCAR over conventional cellular systems under Erlang-B traffic model. The basic idea of the iCAR is to place a number of ARSs in a cellular system to divert excess traffic from one (possibly congested) cell to another. We have compared the performance of the iCAR system with the conventional cellular system via analysis and simulations in terms of the call blocking/dropping probability, throughput, and signaling overhead in both the hot cells and overall subsystem.

Title: Preventing selfishness in open mobile ad hoc networks Existing System In this scenario, open MANETs will likely resemble social environments. A group of persons can provide benefits to each of its members as long as everyone provides his contribution. For our particular case, each member of a MANET will be called to forward messages and to participate on routing protocols. A selfish behavior threatens the entire community. Optimal paths may not be available. As a response, other nodes may also start to behave in the same way. In the extreme, this can take to the complete decoupling of the network. This kind of problems was already noticed on peer-to-peer file distributed systems. It was observed in Gnutella that the number of sites providing valuable content to the network was a small part of the number of users retrieving information. The protocol should apply some kind of penalty to the users that intentionally present selfish behavior and be tolerant to malicious attacks and to communication failures that could penalize well-behaved hosts. Proposed System This paper proposes a selfishness prevention protocol for Open MANETs. The protocol shows some novelties: its decentralization avoids the usage of complex payment systems and it introduces the concept of justified selfishness that makes the whole system more fair, not penalizing users by their network topological location. The drawback of this is it work only on early stages of development and lacks theoretical and experimental validation.

Title: MAC performance of a3GPP-LTE multi-hop cellular network Existing System With OFDM the use of radio resources can be handled efficiently. OFDMA scheduling for multiple access is performed in the BS and decides the parameters to use for each resource unit, e.g. the best subcarrier for a user terminal, the PhyMode and the RF power per subcarrier, all adaptively. In the literature relaying appeared first for TDD systems, back to very early systems. FDD and LTE Multi-hop has been treated in, and there is also an extension for half-duplex FDD. Proposed System This paper treats the properties and MAC performance of a multihop FDD mode cellular system. Two basic scenarios, the Coverage Extension Scenario and the Capacity Extension Scenario, are analyzed for relaying under various parameters. Multi-hop communication can provide an remarkable increase in link and network capacity, especially if we utilized possible antenna gains, directional antennas, and possible parallel transmissions of remote relays (SDM). The most important fact is that no fiber line access is required for relays and relay devices can be cheaply installed anywhere. If the association decision is done the right way by minimizing used resources, there will be always an advantage of having relays instead of base stations only. As result, the total spectral efficiency rises and not only area coverage but also the average system capacity is increased over the area.

Title: Nuglets: A virtual currency to stimulate cooperation in selforganized Mobile Ad hoc networks Existing System In this existing, we present two conceptual models for charging for the packet forwarding service. In the first one, called Packet Purse Model, the source of the packet is charged, whereas in the second one, called Packet Trade Model, the destination is charged. The two models can also be combined to provide a hybrid solution. Proposed System In this paper, they investigated how the cooperation of nodes in selforganized mobile ad hoc networks notably the willingness to forward packets for the benefit of others can be stimulated by introducing a virtual currency (nuglets) in the system. Besides stimulating cooperation, nuglets are a way to encourage the user to make a moderate usage of the network, and to keep her device turned on (so that it can be used as a relay) even if she is not expecting any packet to be sent to her at that time. We believe that introducing a kind of virtual currency can serve several other purposes in mobile ad hoc networks. First, it can be used to remunerate not only communication services, as described in this paper, but also information services. Second, it can be used as a way to pay for the usage of backbones or satellite links, when a node has to communicate with a very distant party. In this case, the virtual currency will have to be converted in some way into hard" currency.

Title: Mitigating Routing Misbehavior in Mobile Ad Hoc Networks Existing System In existing, several algorithms are proposed to detect the black hole attack like DSR, AODV, TORA, DSDV, STAR etc. Proposed two solutions first, isolate the misbehaving nodes from the actual routing protocol for the network. But it adds complexity to protocol. Second, it detects only if the receivers network interface is accepting packets, but they otherwise assume that routing nodes do not misbehave. Although trusting all nodes to be well behaved increases the number of nodes available of routing, it also admits misbehaving nodes to the network. Proposed System In this system, they proposed a technique to detect and mitigate routing misbehavior. They made only minimal changes to the underlying routing algorithm. They introduce two extensions to the Dynamic Source Routing algorithm to mitigate the effects of routing misbehavior: the watchdog and pathrater. The watchdog identifies misbehaving nodes, while the pathrater avoids routing packets through these nodes. When a node forwards a packet, the nodes watchdog verifies that the next node in the path also forwards the packet. The watchdog does this by listening The pathrater uses this promiscuously to the next nodes transmissions. If the next node does not forward the packet, then it is misbehaving. likely to deliver packets. knowledge of misbehaving nodes to choose the network path that is most

Title: A secure incentive protocol for mobile ad hoc networks Existing System The former are intended to enforce the cooperation by first detecting the selfish nodes, avoiding routing through them, and then punishing them via spreading their bad reputations and thus isolating them. The major concern, however, is that it seems difficult (if not impossible) to prevent the propagation of incorrect reputations, either bad or good, in the presence of node collusion. As for the latter, most of the proposals are concerned with providing some kinds of incentives for selfish nodes. In addition to incentive-based preventive approaches, it uses game theory to model the rational yet non-cooperative behavior of nodes and to analyze the optimal trade-off between throughput and lifetime of energy-constrained nodes. The drawback is that it requires each node to keep track of the individual behavior of all the other nodes, which may be unrealistic in most cases. Proposed System In this paper, we propose a Secure Incentive Protocol (SIP) to motivate packet forwarding in totally self organizing MANETs without relying on any centralized infrastructure. The basic idea of SIP is simple: each node imprints a non-forged stamp on each packet forwarded as the proof of forwarding, based on which packet relays are remunerated, while packet sources and destinations are charged with appropriate credits. It is, however, by no means an easy task to implement SIP in a secure, efficient manner. For example, the introduction of credits may serve not only as an incentive for cooperation, but also as a stimulus for cheating.

Title: Stimulating cooperation in self-organizing mobile ad hoc networks Existing System The authors consider the case in which some malicious nodes agree to forward packets but fail to do so. In order to cope with this problem, they propose two mechanisms: a watchdog, in charge of identifying the misbehaving nodes, and a path rater, in charge of defining the best route avoiding these nodes. The paper shows that these two mechanisms make it possible to maintain the total throughput of the network at an acceptable level, even in the presence of high amount ofmisbehaving nodes. However, the problem is that the selfishness of the nodes does not seem to be castigated; on the contrary, by the combination of the watchdog and the path rater, the misbehaving nodes will not be bothered by the transit traffic while still enjoying the possibility to send and to receive packets. Proposed System In this paper, we addressed the problem of stimulating cooperation in self-organizing, mobile ad hoc networks for civilian applications, where the nodes are assumed to be selfish, meaning that they try to maximize the benefits that they get from the network, while minimizing their contribution to it. We focused on a particular instance of this problem, namely, stimulating packet forwarding. Our approach is based on a counter, called nuglet counter, in each node, which is decreased when the node sends an own packet, increased when the node forwards a packet, and required to remain always positive. Besides stimulating packet forwarding, the proposed mechanism encourages the users to keep their nodes turned on and to refrain from sending a large amount of packets to distant destinations.

Title: Cooperation and accounting strategy for multi-hop cellular networks Existing System With the Sprite scheme rewards have been introduced as incentive for cooperation in mobile adhoc networks. Nodes report their forwarding activities to a central authority reachable via an overlay network. In conjunction with the missing security mechanisms this scheme seems highly vulnerable to attacks and transmission errors. In the authors suggest the usage of rewards in multi-hop cellular networks and let a central authority collect and analyze reports to decide about rewards and punishments. However, the authors assume a single-hop down-link (from the base station to the node), which might not be available easily. Proposed System We propose a highly decentralized accounting and security architecture which provides a solid foundation for a cooperation scheme based on rewards and which is applicable to multi-hop cellular networks. In contrast to previous work we allow selfish nodes, but encourage them to participate in packet forwarding via rewards. Additionally, we allow initiator as well as receiver based payment which - to the best of our knowledge - is not possible in the available schemes. Last, we do not charge nor reward for traffic within the same multi-hop cellular network (adhoc only traffic), while other schemes do not allow that.

PROJECT DESCRIPTION PROJECT INTRODUCTION Reputation-based mechanisms suffer from essential problems that discourage implementing them in MCN. First, monitoring the nodes transmissions by overhearing the channel is not energy-efficient for transmitters. The full power transmission is used instead of adapting the transmission power according to the distance separating the transmitter and the receiver to enable more neighboring nodes to hear the packet transmission. Second, reputation-based mechanisms do not achieve fairness because the highly-contributing nodes are not compensated. For example, although the nodes at the network center relay more packets than those at the periphery, they are not compensated. The most widely studied mechanisms fall into four categories: (1) payment-based mechanisms that require tokens, scores, credit, or money to be exchanged in return for service; (2) reputationbased mechanisms that punish or reward peers based on their observed behavior; (3) contribution-based mechanisms that require peers to provide a contribution to get service from others; and (4) other mechanisms that use different approaches. Payment-based Mechanisms The payment-based mechanism has been implemented and proven (Zhong et al. . In a payment-based mechanism, when a peer sends a query message, the peer will lose credit to the decentralized virtual marketplace network, since other peers will incur a cost to forward the message. On the

other hand, peers that forward other peers messages will earn credit, which can be used for their own query messages. Peers can obtain credit in three ways. In the first, peers can directly buy more credit by using real money or other equivalent-money format. In the second, peers earn credit by forwarding other peers messages. Lastly, peers can obtain credit by providing and/or selling services. Golle et al. proposed a micro-payment mechanism, where each peer can earn rewards if they upload to other peers. The rewards can be used for future download. Using a game theoretic model, the authors analyze the equilibrium of peer strategies under several payment mechanisms and conclude that equilibrium exists for the micro-payment based system. The objective of this system is to achieve maximum cooperation from the peers. KARMA and the lightweight currency paradigm are examples of payment based mechanisms. KARMA uses a single currency as a way of secure trading, and the lightweight currency paradigm allows the users to trade any resource with their own currencies. Any entity can introduce its own currency, as long as it is acceptable to other users in the system. A score-based system allows a peer to download multiple times from other peers having lower scores than its own. KaZaA, a score-based P2P system as well, provides downloading priority to peers with high scores over peers with low scores. In our incentive mechanism, we use an incentive value to evaluate peer payoff, such as service priority and resource distribution, instead of using other means such as credit, etc. However, an incentive value is a combination of two incentive factors, session time and peer contribution.

Reputation-based Mechanisms Reputation-based mechanisms require the capability to evaluate a peers cooperativeness on the basis of observable behavior and to provide a punishment or reward with the desired incentive. Each peer would like to obtain or maintain reputation. The reputation incentive mechanism has been shown to be successful in eBay, where buyers and sellers use feedback ratings to gain their reputation values. In a reputation-based system, the peers earn their reputation by sharing, and the reputation determines peer quality. Downloading from a peer with a high reputation has a higher probability of leading better service. Contribution-based Mechanisms Buragohain et al. proposed a game theoretic framework to provide incentives in P2P systems. In this model, peer contribution is expressed in terms of disk space shared per unit time. This contribution allows a peer to obtain differential service, i.e., greater contribution to the system will earn a higher probability with which others will serve its request. If the contribution is small, its request is more likely to be rejected. The incentive mechanism eliminates the free-riders and increases the overall availability of the system. In our incentive mechanism, we express peer contribution in terms of the difference between uploading amount and downloading amount, and an

incentive value is a combination of session time and peer contribution. Since incentive values of peers determines peer payoff, the more peer contribution, the more payoff peers earn. Other Mechanisms Bit Torrent provides incentives to users to download files if they allow Simultaneous upload by other users. In this way, the server redistributes the uploading cost to the downloaders, and a file can be served concurrently to a large number of users. Bit Torrent does not need any score, token, or reputation computation, and therefore has the advantage of simplicity.

EXISTING SYSTEM Reputation-based mechanisms suffer from essential problems that discourage implementing them in MCN. MULTI-HOP cellular network (MCN), is a network architecture that incorporates the ad hoc characteristics in to the cellular system. A nodes traffic is usually relayed through other nodes to the destination. However, due to involving autonomous devices in packet relay, the packet routing process suffers from new security challenges that endanger the practical implementation of MCN. A node earns money by providing a forwarding service to others, and has to pay to get service from other nodes. Furthermore, individual nodes level of cooperation in forwarding packets for their neighbors is also valuable information for the network manager. Ad hoc networks function based on the cooperation and collaboration between nodes. In such networks, each node is responsible for forwarding packets originated by any of its peers. Forwarding is the most fundamental service that each node ought to provide in such networks. However, forwarding should not be taken for granted, as some nodes might act selfishly in order to preserve their resources such as battery life or CPU consumption. Therefore there needs to be a method to detect such selfish nodes in the network.

PROPOSED SYSTEM Our incentive mechanism allows each node to uniformly enforce the policies without assuming any prior trust with other nodes. To ensure trusted policy enforcement, we augment each node with a trusted agent, which protects the policy enforcement components from being compromised. When a node joins a trusted tier, its trusted agent helps establish trust by proving the execution of a correct trusted agent, a trustworthy policy enforcing software component (referred to as policy enforcer hereafter), and the right policy. Furthermore, it ensures that the integrity of the agent, the enforcer, and the policy will not be compromised. Nodes supporting the same set of applications and enforcing the same policies construct a trusted multi-tier applicationcentric network. Each tier of the network runs one application and enforces its associated policy. The application of the upper tier depends on the applications of the lower tiers to communicate. Only trusted nodes are allowed to join the network. Moreover, communication between them is regulated by the policies at every tier. All communications are unicast and the nodes can communicate in one of two modes: pure ad hoc or hybrid. For pure ad hoc mode, the source and destination nodes communicate without involving base stations. The source nodes messages may be relayed in several hops by the intermediate nodes to the destination node. For hybrid mode, at least one base station is involved in the communication. The source node transmits its messages to the source base station (BSS),

if necessary in multiple hops. If the destination node resides in a different cell, the messages are forwarded to the destination base station (BSD) that transmits the messages to the destination node possibly in multiple hops. The nodes do not delete the cheques before receiving the ChequesSubmission-Confirmation packet from the AC. The nodes transmit the Cheques-Submission-Request packet to the AC to submit the cheques. This packet contains the identity of the submitter, time stamp, the cheques, and the submitters signature. The signature authenticates the submitter, thwarts Packet- Replay attack, and ensures the packets integrity. The AC replies with the Cheques-Submission-Confirmation packet containing the ACs signature for the cheques to confirm the submission of the cheques.

KEY GENERATION The RSA key generation techniques. The authentication is a key barrier in the network information system security field. RSA is a open network environment technology, using public key cryptogram system theory has implemented and supplied a universal security infrastructure for security services, it has two main application, include encryption and digital signature. Along with the modern times autoimmunization improvements, a great deal of no face-to-face electronic trades are increasing. A veracity, and security, and practicable automatic personal identification are even more highly demanded and required in our life. Developed a suit of simple identity authentication system for encryption and authentication, it supply a base of research and development.

RSA encryption, supplies unique and stability technology advantages, presents a authentication system. With a public key (PKA) or asymmetric key algorithm, a pair of keys is used. One of the keys, the private key, is kept secret and not shared with anyone. The other key, the public key, is not secret and can be shared with anyone. When data is encrypted by one of the keys, it can only be decrypted and recovered by using the other key.

BLOCK DIAGRAM

MODULE DESCRIPTION MODULES LIST Network Formation Route Finding Algorithm Implementation Route Maintenance Analysis

1. NETWORK FORMATION

The simulation work has been done with The Network Simulator ns-2, Version 2.29. In the simulation 300 nodes are randomly distributed within the network field of size 1000m * 1000m. Then vary the node speed from 5m/s to 30m/s. 2. ROUTE FINDING

3. ALGORITHM IMPLEMENTATION From previous phase we get various path suggestion. Among that user needs to chose a path having minimum number of hops. Having two steps: Initializing phase Compute authenticators based on the hash function. Message format is message, coin, authenticator Sending of Packets Source can send off the packets with the help of Intermediates. 4. ROUTE MAINTENANCE Link state changes has to be periodically updated by all nodes to maintain updated information. Any node found link failure, it has to be informed to all of its neighbors through control messages. On receiving, each has to update its route information. Also each entry has some timeout value after it needs to be purged out from the table.

5. ANALYSIS Let us focus on the performance of this routing protocol. We evaluated the performance using ns2. It will reduce Average end to end delay, Throughput and Packet delivery ratio.

FLOW DIAGRAM

IMPLEMENTATION & METHODOLOGY

SOFTWARE SPECIFICATIONS 1. OS 2. Simulator 3. Language 4. Graph 5. Protocol Design HARDWARE SPECIFICATIONS 1. Processor Type : Pentium IV 2. Processor Speed 3. RAM : 2.7GHz : 1GB : Linux (vmware) : NS2 : Tcl/Tk : GNUplot : CC

OVERVIEW OF NS-2 SIMULATION TEST BED NS-2 is n event driven packet level network simulator developed as a part of the VINT project (Virtual Internet Test bed).Version 1 of NS was developed in 1995 and with version 2 in 1996 Ns-2 with C++/OTCL integration feature. Version 2 included a scripting language called Object oriented Tcl (OTcl). It is an open source software package available for both Windows 32 and Linux platforms. NS-2 has many and expanding uses included. To evaluate that performance of existing network protocols To evaluate new network protocols before use.

 To run large scale experiments not possible in real experiments To simulate a variety of ip networks. NS -2 is an object oriented discrete event simulator. Simulator maintains list of events and executes one event after another. Single thread of control: no locking or race conditions Back end is C++ event scheduler. Protocols mostly Fast to run, more control Front end is OTCL Creating scenarios, extensions to C++ protocols fast to write and change

CHARACTERISTICS OF NS-2 NS-2 implementation the following features Multicasting Simulation of wireless networks Terrestrial (cellular, Adhoc, GPRS, WLAN, BLUETOOTH), satellite IEEE 802.11 can be simulated, Mobile IP and Ad hoc protocols Routing such as DSR, TORA, DSDV and AODV

SOFTWARE TOOLS USED WITH NS-2 In the simulation, there are the two tools are used. NAM(Network Animator) xGraph NAM (Network Animator) NAM provides a visual interpretation of the network topology created. The application was developed as part of the VINT project. Its feature is as follows. Provides a visual interpretation of the network created Can be executed directly from a Tcl script Controls include play; stop fast forward, rewind, pause, a display speed controller button and a packet monitor facility. Presented information such as throughput, number packets on each link X Graph X- Graph is an X-Window application that includes: Interactive plotting and graphing Animated and derivatives To use Graph in NS-2 the executable can be called within a TCL script. This will then load a graph displaying the information visually displaying the information of the file produced from the simulation. The output is a graph of size 800 x 400 displaying information on the traffic flow and time.

SIMULATION TOOL NS2 are often growing to include new protocols. LANs need to be updated for new wired/wireless support. ns are an object oriented simulator, written in C++, with an OTcl interpreter as a front-end. The simulator supports a class hierarchy in C++ and a similar class hierarchy within the OTcl interpreter (also called the interpreted hierarchy). The two hierarchies are closely related to each other; from the users perspective, there is a oneto-one correspondence between classes in the interpreted. NS2 uses two languages because simulator has two different kinds of things it needs to do. On one hand, detailed simulations of protocols require a systems programming language which can efficiently manipulate bytes, packet headers, and implement algorithms that run over large data sets. For these tasks run-time speed is important and turn-around time (run simulation, find bug, fix bug, recompile, re-run) is less important. On the other hand, a large part of network research involves slightly varying parameters or configurations, or quickly exploring a number of scenarios. In these cases, iteration time (change the model and re-run) is more important. Since configuration runs once (at the beginning of the simulation), run-time of this part of the task is less important. Ns meets both of these needs with two languages, C++ and OTcl. C++ is fast to run but slower to change, making it suitable for detailed protocol implementation. OTcl runs much slower but can be changed very quickly (and interactively), making it ideal for simulation configuration. NS (via tclcl) provides glue to make objects and variables appear on both languages.

CODINGS
# ============================================= # Procedure to create a common node application # ============================================= proc create_common_app {destination_id disseminating_type disseminating_interval} { set app_ [new Application/SensorBaseApp/CommonNodeApp] $app_ set destination_id_ $destination_id $app_ set disseminating_type_ $disseminating_type $app_ set disseminating_interval_ $disseminating_interval return $app_ } # =================================================== # Procedure to create a cluster head node application # =================================================== proc create_cluster_head_app {destination_id disseminating_type disseminating_interval} { set app_ [new Application/SensorBaseApp/ClusterHeadApp] $app_ set destination_id_ $destination_id $app_ set disseminating_type_ $disseminating_type $app_ set disseminating_interval_ $disseminating_interval return $app_ } # ==================================================== # Procedure to create a access point node application. # ==================================================== proc create_access_point_app {destination_id} { set app_ [new Application/AccessPointApp] $app_ set destination_id_ $destination_id return $app_ } # ================================================ # Procedure to create a Temperature Data Generator # ================================================ proc create_temp_data_generator {sensing_interval sensing_type avg_measure std_deviation} { set temp_gen_ [new DataGenerator/TemperatureDataGenerator] $temp_gen_ set sensing_interval_ $sensing_interval $temp_gen_ set sensing_type_ $sensing_type $temp_gen_ set avg_measure $avg_measure $temp_gen_ set std_deviation $std_deviation return $temp_gen_ } # ==================================================== # Procedure to create a Carbon Monoxide Data Generator # ====================================================

proc create_carbon_data_generator {sensing_interval sensing_type avg_measure std_deviation} { set carbon_gen_ [new DataGenerator/CarbonMonoxideDataGenerator] $carbon_gen_ set sensing_interval_ $sensing_interval $carbon_gen_ set sensing_type_ $sensing_type $carbon_gen_ set avg_measure $avg_measure $carbon_gen_ set std_deviation $std_deviation return $carbon_gen_ } # ================================= # Antenna Settings # ================================= Antenna/OmniAntenna set X_ 0 Antenna/OmniAntenna set Y_ 0 Antenna/OmniAntenna set Z_ 1.5 Antenna/OmniAntenna set Gt_ 1.0 Antenna/OmniAntenna set Gr_ 1.0 # ================================= # Wireless Phy Settings # ================================= Phy/WirelessPhy set CPThresh_ 10.0 Phy/WirelessPhy set CSThresh_ 1.559e-11 Phy/WirelessPhy set RXThresh_ 3.652e-10 Phy/WirelessPhy set Rb_ 2*1e6 Phy/WirelessPhy set Pt_ 0.2818 Phy/WirelessPhy set freq_ 914e+6 Phy/WirelessPhy set L_ 1.0 set contador_nodos 0 # ================================== # Simulation parameters # ================================== set val(pt_common) 8.564879510890936E-4 set val(pt_cluster_head) 0.2817901234567901 set set set set set set set set set set set set set val(chan) Channel/WirelessChannel ; # channel val(prop) Propagation/TwoRayGround ; # propagation val(netif) Phy/WirelessPhy ; # phy val(mac) Mac/802_11 ; # mac val(ifq) Queue/DropTail/PriQueue ; # queue val(ll) LL ; # link layer val(ant) Antenna/OmniAntenna ; # antenna val(ifqlen) 200 ; # queue length val(rp) AODV ; # routing protocol val(en) EnergyModel/Battery ; # energy model val(nn) 50 ; # number of nodes val(n_pas) 1 ; # number os access points val(n_sinks) 1 ; # number of sink

set set set set

val(n_cluster) 3 val(n_common) 45 val(x) 500.0 val(y) 500.0

; # number ; # number ; # x lenght of ; # y lenght of

of cluster heads of common nodes scenario scenario

set val(disseminating_type) 0 ; # common node disseminating type set val(ch_disseminating_type) 0 ; # cluster heard disseminating type set val(disseminating_interval) 5.0 ; # common node disseminating interval set val(cluster_head_disseminating_interval) 7.0 ; # cluster head disseminating interval set val(start) set val(stop) 5.0 50.0 ; # simulation start time ; # simulation stop time

set val(father_addr) 1 ; # sink address set val(port) 2020 ; # default port source /root/ns-allinone-2.34/ns-2.34/aamr/aamrp # ====================================== # Global variables # ======================================= set ns_ [new Simulator] set traceFile [open cluout.tr w] $ns_ trace-all $traceFile set namFile [open cluout.nam w] $ns_ namtrace-all-wireless $namFile 300 300 #$ns_ use-newtrace set topo [new Topography] $topo load_flatgrid $val(x) $val(y) create-god $val(nn) set rng [new RNG] $rng seed 0 # ================================= # Procedure to create a common node # ================================= proc create_common_node {} { global val ns_ node_ topo udp_ app_ gen_ contador_nodos rng aamrp Phy/WirelessPhy set Pt_ $val(pt_common) $ns_ node-config -sensorNode ON \ -adhocRouting $aamrp \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \

-ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -energyModel $val(en) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace OFF \ -rxPower 0.024 \ -txPower 0.036 \ -initialEnergy 10.0 \ -movementTrace OFF set node_($contador_nodos) [$ns_ node] $node_($contador_nodos) random-motion 0 set x [$rng uniform 0.0 $val(x)] set y [$rng uniform 0.0 $val(y)] $node_($contador_nodos) set X_ $x $node_($contador_nodos) set Y_ $y $node_($contador_nodos) set Z_ 0.0 set interval [$rng uniform 0.0 1.0] Node/MobileNode/SensorNode set sensingPower_ 0.015 Node/MobileNode/SensorNode set processingPower 0.024 Node/MobileNode/SensorNode set instructionsPerSecond_ 8000000 Phy/WirelessPhy set bandwidth_ 288000.0 set udp_($contador_nodos) [new Agent/UDP] set distance 10000000 set initial [expr $val(n_pas) + $val(n_sinks)] for {set j $initial} {$j < [expr $initial + $val(n_cluster)]} {incr j} { set x_father [$node_($j) set X_] set y_father [$node_($j) set Y_] set x_son [$node_($contador_nodos) set X_] set y_son [$node_($contador_nodos) set Y_] set x_temp [expr pow([expr $x_father-$x_son],2)] set y_temp [expr pow([expr $y_father-$y_son],2)] set temp_distance [expr sqrt([expr $x_temp + $y_temp])] if {$temp_distance < $distance} { set distance $temp_distance set val(father_addr) [$node_($j) node-addr] } }

set app_($contador_nodos) [create_common_app $val(father_addr) $val(disseminating_type) $val(disseminating_interval)] $node_($contador_nodos) attach $udp_($contador_nodos) $val(port) $node_($contador_nodos) add-app $app_($contador_nodos) set processing_($contador_nodos) [new Processing/AggregateProcessing] $app_($contador_nodos) node $node_($contador_nodos) $app_($contador_nodos) attach-agent $udp_($contador_nodos) $app_($contador_nodos) attach-processing $processing_($contador_nodos) $processing_($contador_nodos) node $node_($contador_nodos) $ns_ at [expr $val(start) + 1 + $interval] "$app_($contador_nodos) start" $ns_ at $val(stop) "$app_($contador_nodos) stop" set gen_($contador_nodos) [create_temp_data_generator 3.0 0 25.0 1.0] $app_($contador_nodos) attach_data_generator $gen_($contador_nodos) incr contador_nodos } #creating the error model set m1_ubstate 27.0 set m1_bstate 12.0 set m2_ubstate 0.4 set m2_bstate 0.4 set durlist "$m1_ubstate $m1_bstate $m2_ubstate $m2_bstate" set errmodel [new ErrorModel/ComplexTwoStateMarkov $durlist time] $errmodel unit packet $errmodel drop-target [new Agent/Null] #wireless_node_config $ns_ $topo $errmodel # ======================================== # Procedure to create a cluster head node # ======================================== proc create_cluster_head_node {} { global val ns_ node_ topo contador_nodos rng Phy/WirelessPhy set Pt_ $val(pt_cluster_head) $ns_ node-config -sensorNode ON \ -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \

-ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -energyModel $val(en) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -rxPower 0.3 \ -txPower 0.6 \ -initialEnergy 100.0 \ -movementTrace OFF set node_($contador_nodos) [$ns_ node] $node_($contador_nodos) random-motion 0 set x [$rng uniform 0.0 $val(x)] set y [$rng uniform 0.0 $val(y)] $node_($contador_nodos) set X_ $x $node_($contador_nodos) set Y_ $y $node_($contador_nodos) set Z_ 0.0 set interval [$rng uniform 0.0 1.0] Node/MobileNode/SensorNode set processingPower 0.36 Node/MobileNode/SensorNode set instructionsPerSecond_ 150000000 Phy/WirelessPhy set bandwidth_ 1000000.0 $ns_ at 0.01 "$node_($contador_nodos) add-mark m2 red circle" $ns_ at 0.01 "$node_($contador_nodos) label \"CH\"" set udp_($contador_nodos) [new Agent/UDP] set app_($contador_nodos) [create_cluster_head_app [$node_(1) node-addr] $val(disseminating_type) $val(cluster_head_disseminating_interval)] $node_($contador_nodos) attach $udp_($contador_nodos) $val(port) $node_($contador_nodos) add-app $app_($contador_nodos) set processing_($contador_nodos) [new Processing/AggregateProcessing] $app_($contador_nodos) node $node_($contador_nodos) $app_($contador_nodos) attach-agent $udp_($contador_nodos) $app_($contador_nodos) attach-processing $processing_($contador_nodos) $processing_($contador_nodos) node $node_($contador_nodos) $ns_ at [expr $val(start) + 1 + $interval] "$app_($contador_nodos) start" $ns_ at $val(stop) "$app_($contador_nodos) stop" incr contador_nodos

} $ns_ at 9.00 "$ns_ trace-annotate \"Trust information check and shared\"" $ns_ at 11.00 "$ns_ trace-annotate \"Update Trusted nodes\"" $ns_ at 11.453 "$ns_ trace-annotate \"CH2 check trust value an contador nodes(12 & 10)\"" $ns_ at 11.887 "$ns_ trace-annotate \"Test Trust values\"" $ns_ at 46.00 "$ns_ trace-annotate \"CH3 receive message from node 6\"" # =================================== # Procedure to create a sink node # =================================== proc create_sink {} { global ns_ val node_ sink_ contador_nodos topo Phy/WirelessPhy set Pt_ 0.2818 $ns_ node-config -sensorNode ON \ -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -energyModel $val(en) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -rxPower 0.5 \ -txPower 0.5 \ -initialEnergy 100.0 \ -movementTrace OFF set node_($contador_nodos) [$ns_ node] $node_($contador_nodos) random-motion 0 $ns_ at 0.01 "$node_($contador_nodos) add-mark m2 blue circle" $ns_ at 0.01 "$node_($contador_nodos) label \"Sink\"" set sink_(0) [new Agent/LossMonitor] $node_($contador_nodos) attach $sink_(0) $val(port) $node_($contador_nodos) set X_ 250 $node_($contador_nodos) set Y_ 250 $node_($contador_nodos) set Z_ 0.0 incr contador_nodos

} # ======================================== # Procedure to create a access point node # ======================================== proc create_access_point {} { global ns_ val node_ app_ udp_ contador_nodos topo Phy/WirelessPhy set Pt_ 0.2818 $ns_ node-config -sensorNode ON \ -adhocRouting $val(rp) \ -llType $val(ll) \ -macType $val(mac) \ -ifqType $val(ifq) \ -ifqLen $val(ifqlen) \ -antType $val(ant) \ -propType $val(prop) \ -energyModel $val(en) \ -phyType $val(netif) \ -channelType $val(chan) \ -topoInstance $topo \ -agentTrace ON \ -routerTrace ON \ -macTrace ON \ -rxPower 0.5 \ -txPower 0.5 \ -initialEnergy 100.0 \ -movementTrace OFF set node_($contador_nodos) [$ns_ node] $node_($contador_nodos) random-motion 0 set udp_($contador_nodos) [new Agent/UDP] set app_($contador_nodos) [create_access_point_app [$node_(0) node-addr]] $ns_ at 0.01 "$node_($contador_nodos) add-mark m2 yellow circle" $ns_ at 0.01 "$node_($contador_nodos) label \"AP\"" $node_($contador_nodos) attach $udp_($contador_nodos) $val(port) $app_($contador_nodos) attach-agent $udp_($contador_nodos) $node_($contador_nodos) set X_ 5.0 $node_($contador_nodos) set Y_ 5.0 $node_($contador_nodos) set Z_ 0.0 $ns_ at [expr $val(stop)+1] "$app_($contador_nodos) stop" incr contador_nodos }

# =================================================================

# Procedures to control common node and cluster head node creation # ================================================================= create_sink create_access_point for {set j 0} {$j < $val(n_cluster)} {incr j} { create_cluster_head_node } for {set i 0} {$i < $val(n_common)} {incr i} { create_common_node } for {set i 0} {$i < $val(nn)} {incr i} { $ns_ initial_node_pos $node_($i) 20; } $ns_ at 0.000000000000 "$node_(0) setdest 185.687072906390 289.449127718205 10.966766999356" $ns_ at 0.000000000000 "$node_(1) setdest 53.018211300435 177.949502182542 3.465502533089" $ns_ at 0.000000000000 "$node_(2) setdest 207.806748110755 92.974664698991 3.236891162180" $ns_ at 0.000000000000 "$node_(3) setdest 1.915233744860 231.788458794355 7.508349765962" source trafficr $ns_ at 0.000000000000 "$node_(4) setdest 20.319524366982 240.509174630490 1.526574578259" $ns_ at 0.000000000000 "$node_(5) setdest 34.402826627667 75.185534972370 1.029199105239" $ns_ at 0.000000000000 "$node_(6) setdest 229.158433076216 7.812285824901 1.611500314249" $ns_ at 0.000000000000 "$node_(7) setdest 33.193445066976 252.329432634758 2.449259405361" $ns_ at 0.000000000000 "$node_(8) setdest 170.061803463114 21.409805294415 9.853855178599" $ns_ at 0.000000000000 "$node_(9) setdest 98.576465412952 97.718372574407 4.409920284120" $ns_ at 0.000000000000 "$node_(10) setdest 61.384165791773 226.918403221999 5.211319922459" $ns_ at 0.000000000000 "$node_(11) setdest 272.232165728763 27.968069286402 1.835082773514" $ns_ at 0.000000000000 "$node_(12) setdest 200.952684157099 151.498903127334 1.702167788067" $ns_ at 0.000000000000 "$node_(13) setdest 61.793407833443 287.138099368830 10.097747926445" $ns_ at 0.000000000000 "$node_(14) setdest 21.674310301490 76.309944775996 2.128504260380" $ns_ at 0.000000000000 "$node_(15) setdest 77.382666383776 202.626307226315 17.387156814460"

$ns_ at 0.000000000000 "$node_(16) 90.795576871717 2.096825740100" $ns_ at 0.000000000000 "$node_(17) 169.403486032022 7.762147057458" $ns_ at 0.000000000000 "$node_(18) 138.453480018844 6.459906916754" $ns_ at 0.000000000000 "$node_(19) 144.537597536999 1.272137913062" $ns_ at 0.000000000000 "$node_(20) 290.822683039847 8.344283661947" $ns_ at 0.000000000000 "$node_(21) 152.316590650438 3.820480134259" $ns_ at 0.000000000000 "$node_(22) 99.899603933822 1.259888561223" $ns_ at 0.000000000000 "$node_(23) 211.528928251475 1.237994067488" $ns_ at 0.000000000000 "$node_(24) 95.163686199590 2.912361880478" $ns_ at 0.000000000000 "$node_(25) 124.626040254304 5.758279896277" $ns_ at 0.000000000000 "$node_(26) 118.385276273856 1.667259711956" $ns_ at 0.000000000000 "$node_(27) 147.907680940069 12.496712741516" $ns_ at 0.000000000000 "$node_(28) 26.424051820348 3.374178118731" $ns_ at 0.000000000000 "$node_(29) 238.379789675352 4.922601995734" $ns_ at 0.000000000000 "$node_(30) 48.708330777318 3.739000639811" $ns_ at 0.000000000000 "$node_(31) 270.165863678441 15.766683199785" $ns_ at 0.000000000000 "$node_(32) 70.131278896543 13.666930164844" $ns_ at 0.000000000000 "$node_(33) 253.642811057555 7.442469992683" $ns_ at 0.000000000000 "$node_(34) 98.214473628581 7.363821723423" $ns_ at 0.000000000000 "$node_(35) 218.547093532466 9.350287909820" $ns_ at 0.000000000000 "$node_(36) 105.070464023076 13.551278264882" $ns_ at 0.000000000000 "$node_(37) 4.158106810620 1.128421891181" $ns_ at 0.000000000000 "$node_(38) 93.331416676039 1.515314335512" $ns_ at 0.000000000000 "$node_(39) 178.539438507567 12.989197249700" $ns_ at 0.000000000000 "$node_(40) 271.888400952515 9.584000702592" $ns_ at 0.000000000000 "$node_(41) 130.895942316008 1.141247312394"

setdest 252.238949776092 setdest 182.218812266717 setdest 105.469737606520 setdest 98.409044013610 setdest 128.702300221212 setdest 17.535482777138 setdest 55.258436103760 setdest 129.735593703809 setdest 128.390251450514 setdest 229.376702036325 setdest 121.940202024663 setdest 251.492296580784 setdest 63.924246140812 setdest 115.233165460755 setdest 115.267944912364 setdest 262.230238002699 setdest 56.108073068429 setdest 74.417464965683 setdest 142.123898342664 setdest 229.808591911613 setdest 279.264547486563 setdest 26.831958904175 setdest 151.868362838547 setdest 265.151204553305 setdest 157.264236246925 setdest 122.863369168616

$ns_ at 0.000000000000 "$node_(42) setdest 5.263052297457 59.237533114247 9.108856019248" $ns_ at 0.000000000000 "$node_(43) setdest 221.883524361014 240.239277405145 3.906168711717" $ns_ at 0.000000000000 "$node_(44) setdest 15.639637353142 55.350552106489 6.484637877858" $ns_ at 0.000000000000 "$node_(45) setdest 34.777921352956 231.679750603947 2.315191130983" $ns_ at 0.000000000000 "$node_(46) setdest 89.606990813802 295.146263435116 4.455240192285" $ns_ at 0.000000000000 "$node_(47) setdest 262.995298556756 152.919971478953 1.595520510540" $ns_ at 0.000000000000 "$node_(48) setdest 224.627647833561 127.031614380557 2.132865114518" $ns_ at 0.000000000000 "$node_(49) setdest 237.230232973557 200.018208218689 16.212983255577" $ns_ at 11.5 "$node_(12) add-mark m2 white circle" $ns_ at 11.5 "$node_(10) add-mark m2 white circle" $ns_ at 40 "$node_(10) delete-mark m2" $ns_ at 46.5 "$node_(6) add-mark m2 white circle" Node instproc join { group } { $self instvar ragent_ set group [expr $group] $ragent_ join $group } Node instproc leave { group } { $self instvar ragent_ set group [expr $group] ; } # ========================= # Simulation # ========================= $ns_ at [expr $val(stop)+2.0] "finish" $ns_ at [expr $val(stop)+2.0] "puts \"NS EXITING...\" ; $ns_ halt" $ns_ at [expr $val(stop)+2.0] "$ns_ nam-end-wireless $val(stop)" proc finish {} { global ns_ traceFile $ns_ flush-trace close $traceFile } puts "Starting Simulation..." $ragent_ leave $group

$ns_ run

SCREEN SHOTS

CONCLUSION We propose a method that provides an efficient incentive mechanism for forwarding packets. We have implemented the trust model for transmitting the data. Through the trust nodes we transmit the data which provides the secure data transmission. Instead of generating two signatures per packet (one from the source and the other from the destination), we have replaced the destination nodes signature with hashing operations to reduce the number of public-key-cryptography operations nearly by half. The source node attaches a signature in each data packet to ensure the payment non-repudiation and to verify the message integrity at each intermediate node to thwart Free-Riding attacks. In our future work, we will focus on reducing the number of public-key-cryptography operations due to the source nodes signatures. And we analyze the parameters such as Packet Delivery ratio Throughput, End to end delay.