Energy-Efficient Protocol for Cooperative Networks

ABSTRACT
In cooperative networks, transmitting and receiving nodes recruit neighboring nodes to assist in communication. We model a cooperative transmission link in wireless networks as a transmitter cluster and a receiver cluster. We then propose a cooperative communication protocol for establishment of these clusters and for cooperative transmission of data. We derive the upper bound of the capacity of the protocol, and we analyze the end-to-end robustness of the protocol to data-packet loss, along with the tradeoff between energy consumption and error rate. The analysis results are used to compare the energy savings and the end-to-end robustness of our protocol with two non-cooperative schemes, as well as to another cooperative protocol published in the technical literature. The comparison results show that, when nodes are positioned on a grid, there is a reduction in the probability of packet delivery failure by two orders of magnitude for the values of parameters considered. Up to 80% in energy savings can be achieved for a grid topology, while for random node placement our cooperative protocol can save up to 40% in energy consumption relative to the other protocols. The reduction in error rate and the energy savings translate into increased lifetime of cooperative sensor networks.

LIST OF CONTENTS

Page N0 List of Figures List of Tables 1. Introduction 1.1 Purpose 1.2 Scope 1.3 Motivation 1.3.1 Definitions 1.3.2 Abbreviations 1.3.3 Model Diagrams 13 1.4 Overview 2. Literature Survey 2.1 Introduction 2.2 History 2.3 Purpose 2.4 Requirements 2.5 Technology Used 3. System Analysis 3.1 Existing System 15 16 17 21 24 26 29 41 43 6 7 8 9 10 11 12 12

3.1.1 Drawbacks 3.2 Problem statement 3.3 Proposed System 3.3.1 Advantages 3.4 Feasibility Study 3.4.1 Economic Feasibility 3.4.2 Operational Feasibility 3.4.3 Technical Feasibility 3.5 Algorithm 3.6 Data Dictionary 45

45

46 47 47 49 50 51 53 53

4. System Requirements Specification 4.1 Introduction

54 55

4.2 Purpose 4.3 Functional Requirements 4.4 Non Functional Requirements 4.5 Hardware Requirements 4.6 Software Requirements 5. System Design 5.1 System Specifications 5.2 System Components 5.3 UML Diagrams 5.4DFD Diagrams 5.5 ER Diagram 6. Implementation 6.1 Sample Code

56 57 58 59 60 61 62 63 64 80 82 83 85

7. System Testing 7.1 Testing Methodologies 7.2 Test cases 7.3 Results and Discussions 8. Conclusion and Future Enhancements 8.1 8.2 9. References Conclusion Scope for Future Enhancement

96 101 102 110 111 111 111 112

LIST OF FIGURES
Figure No.
1 2 3 3 4 5 6 7 8 9

Figure Name

Page No

Fig V Model class diagram use case diagram sequence diagram

Collaboration diagram

State chart Diagram Activity Diagram Deployment Diagram

10 11 12 11 12 14 15 16 17 18

Component Diagram DFD Diagram

SOFTWARE TESTING LIFE CYCLE

Fig Login Form Fig Login validation Form Fig Registration Form Fig Registration validation Form

LIST OF TABLES
Table No. Table Name Page No

1 2 3 4

Positive Test case Negative Test Case

1 INTRODUCTION
In Wireless sensor networks, nodes have limited energy resources and, consequently, protocols designed for sensor networks should be energy-efficient. One recent technology that allows energy saving is cooperative transmission. In cooperative transmission, multiple nodes simultaneously receive, decode, and retransmit data packets. In this paper, as opposed to previous works, we use a cooperative communication model with multiple nodes on both ends of a hop and with each data packet being transmitted only once per hop. In our model of cooperative transmission, every node on the path from the source node to the destination node becomes a cluster head, with the task of recruiting other nodes in its neighborhood and coordinating their transmissions. Consequently, the classical route from a source node to a sink node is replaced with a multi hop cooperative path, and the classical pointto-point communication is replaced with many-to-many cooperative communication. The path can then be described as having a width, where the width of a path at a particular hop is determined by the number of nodes on each end of a hop. For the example in, the width of each intermediate hop is 3. Of course, this width does not need to be uniform along a path. Each hop on this path represents communication from many geographically close nodes, called a sending cluster, to another cluster of nodes, termed a receiving cluster. The nodes in each cluster cooperate in transmission of packets, which propagate along the path from one cluster to the next. Our model of cooperative transmission for a single hop is further depicted in Fig. 2(a). Every node in the receiving cluster receives from every node in the sending cluster. Sending

nodes are synchronized, and the power level of the received signal at a receiving node is the sum of all the signal powers coming from all the sender nodes. This reduces the likelihood of a packet being received in error. We assume that some mechanism for error detection is incorporated into the packet format, so a node that does not receive a packet correctly will not transmit on the next hop in the path. Our cooperative transmission protocol consists of two phases. In the routing phase, the initial path between the source and the sink nodes is discovered as an underlying one-node-thick path. Then, the path undergoes a thickening process in the recruiting-andtransmitting phase. In this phase, the nodes on the initial path become cluster heads, which recruit additional adjacent nodes from their neighborhood. Due to the fact that the cluster heads recruit nodes from their immediate neighborhood, the inter-clusters distances are significantly larger than the distances between nodes in the same cluster [not shown in. Recruiting is done dynamically and per packet as the packet traverses the path. When a packet is received by a cluster head of the receiving cluster, the cluster head initiates the recruiting by the next node on the one-node-thick path. Once this recruiting is completed and the receiving cluster is established, the packet is transmitted from the sending cluster to the newly established receiving cluster.

1.1 Purpose:
The routing phase of the protocol, which is responsible for finding a one-nodethick route from the source node to the sink node, could be implemented using one of the many previously published routing protocols. For the purpose of performance evaluation, we chose to implement this phase using the Ad hoc On-demand Distance-Vector routing protocol (AODV) with some modifications and with the links transmissions energy used as the links cost.

1.3 Scope:
The main novelty of our paper the recruiting-andtransmitting Phase is done dynamically per hop, starting from the source node and progressing, hop by hop, as the packet moves along the path to the sink node. Once a data packet is received at a receiving cluster of the previous hop along the path, the receiving cluster now becomes the sending

cluster, and the new receiving cluster will start forming. The next node on the one-node-thick-path becomes the cluster head of the receiving cluster. The receiving cluster is formed by the cluster head recruiting neighbor nodes through exchange of short control packets. Then, the sending cluster head synchronizes its nodes, at which time the nodes transmit the data packet to the nodes of the receiving cluster.

1.3 Motivation:
Our model of cooperative transmission for a single hop is further depicted in. Every node in the receiving cluster receives from every node in the sending cluster. Sending nodes are synchronized, and the power level of the received signal at a receiving node is the sum of all the signal powers coming from all the sender nodes. This reduces the likelihood of a packet being received in error. We assume that some mechanism for error detection is incorporated into the packet format, so a node that does not receive a packet correctly will not transmit on the next hop in the path.

1.3.1 Definitions
The CAN protocol and the one-path scheme, the cooperative path is set as the middle row. In the disjoint-paths scheme, paths are formed from nodes in the same row, except that the source and the sink nodes are in the middle row. Data packets arrive at the source node following the Poisson distribution with a rate that corresponds to the maximum load that the network can carry.

1.3.3 Module Description:

1. Recruiting, Transmitting & receiving 2. Route Construction 3. Data transmission using CANs 4. Message details with Route paths

1. Recruiting, Transmitting & receiving: Our cooperative transmission protocol consists of two phases. In the routing phase, the initial path between the source and the sink nodes is discovered as an underlying one-node-thick path. Then, the path undergoes a thickening process in the recruiting-andtransmitting phase. In this phase, the nodes on the initial path become cluster heads, which recruit additional adjacent nodes from their neighborhood. Recruiting is done dynamically and per packet as the packet traverses the path. When a packet is received by a cluster head of the receiving cluster, the cluster head initiates the recruiting by the next node on the one-node-thick path. Once this recruiting is completed and the receiving cluster is established, the packet is transmitted from the sending cluster to the newly established receiving cluster. 2. Route Construction: Upon receiving the CL packet from node 5, node 2 sends a confirm (CF) packet to the nodes in its sending cluster (nodes 1 and 3) to synchronize their transmission of the data packet. The CF packet contains the waiting-time-to-send and the transmission power level. The transmission power level is the total transmission power (a protocol-selectable parameter) divided by the number of the nodes in the sending cluster. In the case of our example, the value of is divided by 3 (nodes 13 are cooperating in sending). After the waiting-time-to-send expires, sending cluster nodes 13 send the data packet to the receiving cluster nodes 3. Data transmission using CANs The capacity of the CAN protocol degrades with an increase in the transmission range, as a transmission on one hop blocks a large number of nodes from transmitting other packets, and hence the network can only carry lower load. In the CAN protocol, failure to receive a packet results in a large reduction in the success probability on the next hop. The disjoint-paths scheme has larger energy consumption, as demonstrated in, which shows the effect of the transmission range on the total energy consumption. Here, we sum the energy consumption for all packets transmitted (control and data packets). Our cooperative transmission protocol saves between 6% and 20% of the energy consumption compared to the CAN protocol and between 10% and 40% of the energy consumption compared to the disjoint-paths scheme. As the transmission range

increases, the contention increases and the noise power increases. This increases the energy consumption. The elevated contention increases the retransmission of control and data packets, which, in turn, increases the total energy consumption. 4. Message details with Route paths: The work in proposes and evaluates the performance of a cross-layer framework that uses virtual multiple- inputsingle-output (MISO) links for MANET and shares some similarity with our paper. However, there are some major differences between the two works. On the physical layer, the architecture of is based on virtual MISO, which is also referred to in as virtual antenna array. As pointed out in that paper, nodes simultaneously transmit and/or jointly receive appropriately encoded signals. This model is totally different from our model, where we use MISO system with orthogonal transmissions. On the MAC layer, relies on the knowledge of the neighbors to select the cooperating nodes. To achieve this, assumes that the list of neighbors is obtained by the HELLO messages of the routing protocol

1.4 Overview: We evaluated the performance of cooperative transmission, where nodes in a sending cluster are synchronized to communicate a packet to nodes in a receiving cluster. In our communication model, the power of the received signal at each node of the receiving cluster is a sum of the powers of the transmitted independent signals of the nodes in the sending cluster. The increased power of the received signal, is the traditional single node to single node communication, leads to overall saving in network energy and to end-to-end robustness to data loss.

2. LITERATURE SURVEY
2.1 INTRODUCTION
The problem of energy-efficient routing in wireless networks that support cooperative transmission was formulated in. In, two energy-efficient approximation algorithms are presented for finding a cooperative route in wireless networks. The two algorithms for finding one cooperative route are designed such that each hop consists of multiple sender nodes to one receiver node. One of the algorithms (CAN) is used throughout this paper for performance comparison. The works in focus on MAC layer design for networks with cooperative transmission. In, when no acknowledgement is received from the destination after timeout, the cooperative nodes, which correctly received the data, retransmit it. Only one cooperative node retransmits at any time, and the other cooperative nodes flush their copy once they hear the retransmission. Hence, this work focuses on reducing the transmission errors, without benefiting from the energy savings of simultaneous transmissions. In, high-rate nodes help low-rate nodes by forwarding their transmissions. The work describes how the helper nodes are discovered. Similarly to, only one node can cooperate at a time, and simultaneous transmissions are not used, hence the energy savings are not considered. Likewise, in only one node cooperates in forwarding the data.

The IEEE 802.11 protocol was extended in to support multiple antennas per node. The works in use the model with only one helper node at each hop in addition to the sender and the receiver. The model in utilizes multiple nodes to forward the data, but only one node can transmit at any time. Several good tutorial papers on cooperative transmission have been published. As most of the current works look at the cooperation from the transmitter side only, our paper differs in that our communication model includes groups of cooperating nodes at both sides of the transmission link with the purpose of reduction in energy consumption. Similar to multiple-inputmultiple-output (MIMO) communications, the main gain of cooperative transmission comes from the fact that there is limited correlation between communications from different transmitters. The increase in the degree of freedom of signal detection decreases the bit error rate. Consequently, the gain of cooperation is similar in nature to what is achieved by MIMO techniques. Of course, there are substantial differences in the environment and in the operation between cooperative transmission and MIMO. In the MIMO systems, each node is equipped with multiple antennas. Information is transmitted from the sender node by multiple antennas and received by multiple antennas at the receiver node. The close proximity of the antennas at the transmitting nodes and of the antennas at the receiving nodes makes synchronization easier to implement. The ability of nodes to sense the carrier and to measure the interference level can be used to decide on the number of antennas that are employed for transmission. On the contrary, in cooperative transmission, the synchronization of transmissions of the relatively dispersed cooperating nodes necessitates a more elaborate protocol. A protocol is also required to identify the neighboring nodes as potential cooperators and to make a selection of the cooperating nodes. Moreover, due to the geographical dispersion of the cooperating nodes, the protocols in cooperative networks need to be distributed in their operation. In, a MAC protocol for MIMO systems is described, which is based on centralized cluster architecture. This protocol uses clustering mechanisms like LEACH. Nodes in a cluster cooperate to forward the data to only the next cluster head on the path to the sink. However, the centralized architecture leads to higher energy usage for the cluster maintenance. In contrast, distributed mechanisms are more efficient in the cluster maintenance operation and lack the single-point-of failure vulnerability. Thus, they may be better suited for sensor or mobile networks. Finally, the significant cost increase in MIMO to implement multiple antennas at each node would be most often considered impractical

in many wireless networks and, in particular, in sensor networks. The work in proposes and evaluates the performance of a cross-layer framework that uses virtual multiple- inputsingleoutput (MISO) links for MANET and shares some similarity with our paper. However, there are some major differences between the two works. On the physical layer, the architecture of is based on virtual MISO, which is also referred to in as virtual antenna array. As pointed out in that paper, nodes simultaneously transmit and/or jointly receive appropriately encoded signals. This model is totally different from our model, where we use MISO system with orthogonal transmissions. On the MAC layer, relies on the knowledge of the neighbors to select the cooperating nodes. To achieve this, assumes that the list of neighbors is obtained by the HELLO messages of the routing protocol. In our paper, we do not assume any knowledge of the neighboring nodes. Rather, we design our own recruiting protocol. Furthermore, the selection of the nodes to cooperate is done randomly, without regard to how useful these nodes could be in improving the cooperative communication. In contrast, in our protocol, selection of cooperating nodes is done based on an elaborate calculation of the costs of the connections. These costs are evaluated not only between the source and the collaborating node, but also between the collaborating nodes and the target nodes in the receiving cluster. Finally, our protocol avoids transmission collisions by reserving the recruiting nodes and preventing them from transmitting during the collaboration.

Power Efficiency of Cooperative Communication in Wireless Sensor Networks

INTRODUCTION Wireless communication systems have recently gained popularity as their benefits are being acknowledged and engineering ingenuity continues to overcome their inherent. One serious disadvantage of wireless sensor networks (WSNs) is that the sensors used in these networks are often limited to the use of a single battery, and their success is highly dependent upon power efficient protocols. Traditional layered protocols often prove to be inefficient for WSNs, and determining whether more power efficient protocols can be developed is important to the future advancement of these networks. One recently developed protocol, the cross-layer module (XLM), has been shown to increase network efficiency and reliability in comparison to traditional layered protocols. XLM melts together the physical, MAC, network and transport layers. At the core of XLM is initiative determination, which is detailed in. Cooperative

communications is also an alternative to traditional protocols that can increase power efficiency in WSNs by having several nodes simultaneously transmit a single message to the intended destination. The result is an energy savings due to the wireless broadcast advantage (WBA). The WBA stems from the fact that when a wireless node transmits a packet, all nodes within the transmission radius are able to listen. Usually, nodes for which the packet is not intended ignore the packet, but it is possible for nodes to accept all incoming packets. When a node can communicate with a group of nodes by only transmitting once, instead of transmitting to each receiving node individually, the node is using the WBA. In this paper, a protocol named Coop XLM that integrates cooperative communication and XLM is presented. Coop XLM retains the initiative determination of XLM and adds the ability for multiple nodes to participate in a single transmission. Simulation results show that Coop XLM provides energy savings when compared to XLM. However, Coop XLM only improves unique good put when compared to XLM at lower duty cycles. At higher duty cycles, XLM has a higher unique good put than Coop XLM. The Open Systems Interconnection (OSI) layers have been used extensively in wired networks to provide portability and modularity. Researchers and designers are able to focus on optimizing a certain layer while treating the remaining layers as black boxes. OSI layers work well in wired networks because these networks have limited interactions between layers. However, there are many inter-layer effects in a wireless network. Thus, although the OSI layers have led to simplicity of system integration for wired networks, they can lead to suboptimal system performance in wireless ones. Take for example the case of packet loss; the transport layer will attribute the problem to congestion in the neighboring network layer even though the problem may be caused by burst interferences at the MAC layer. This misdiagnosis due to abstraction will cause lower throughput. Empirical studies have shown that wireless channel characteristics, whose impact would traditionally be confined to the physical layer, actually affect all layers in terms of performance. In addition, the medium access control (MAC) and routing layers significantly influence each other due to interference. The physical and transport layers are coupled due to the broadcast nature of wireless communication. As the power level of each node is increased, the probability of collisions between packets increases. In order to address inter-layer effects, a protocol that combines several layers needs to be developed.

Some previous works have combined a few layers, such as the MAC and routing layers, or else they have combined all layers but not implemented the design. In order to jointly optimize several layers and remove negative inter-layer effects, a unified cross-layer protocol is required. Cross-Layer Module (XLM) is such a protocol. XLM is a cross-layer protocol designed specifically for efficiency and reliability in WSN communication. The main concepts of XLM include receiver-based contention, initiative determination, initiative-based forwarding, local congestion control and distributed duty cycle operation. XLM melts the transport, network, MAC and physical layers together. Unlike proactive routing protocols, XLM does not determine the route from the source to the sink before the need arises. Instead, XLM waits until the source has data to send to the sink; therefore, it is a reactive protocol. Although the sensor networks considered in this paper are stationary, some of them have nodes with duty cycles other than 100%. Sleeping nodes are equivalent to dead nodes for a particular communication. Each live node has two duties: source duty and router duty. The source duty is only necessary when an event occurs in the nodes transmission radius. In this case, the node is responsible for generating and transmitting the packet towards the sink. The router duty is the nodes duty to receive and forward packets that other nodes have generated. A basic assumption is that all nodes know their own location and that of the sink. In order to explain XLM, a walk-through of a single communication is presented next. When a source node wants to send data to the sink, it listens to the medium to check if other signals are being broadcast. If the medium is busy, source node performs a contention window size back off. Once the back off timer expires, source node broadcasts a request to send (RTS) to all nodes within its transmission radius. The transmission radius is denoted in by the dashed circle. The sink may or may not be within the transmission radius. If it is, then the sink becomes the chosen next hop; otherwise, receiver-based contention Wireless communication systems have a multitude of potential applications; however, one serious disadvantage of wireless sensor networks is that the sensors used in these networks are often limited to the use of a single battery, and their success is highly dependent upon power efficient protocols. Traditional layered protocols often prove to be inefficient for WSNs. One recently developed protocol, the cross-layer module (XLM), is a unified protocol that is designed specifically for WSNs. XLM has been shown to increase network efficiency and reliability in comparison to traditional layered protocols. The core of XLM, initiative determination,

maintains a balance between received signal to- noise ratio (SNR), local congestion and remaining energy to increase reliability and network lifetime. Cross-layer design can help achieve better energy performance in WSNs; however, it is important to strive for the advantages of flexibility, modularity, simplicity and scalability found in traditional layered protocols. Cooperative communications is also an alternative to traditional protocols that can increase efficiency in WSNs by having several nodes simultaneously transmit a single message to the intended destination. In this paper, a new protocol termed Coop XLM, which integrates cooperative communication with XLM, is created and examined via simulation. Simulation results indicate that energy is saved with Coop XLM in comparison to XLM and the Coop XLM yields higher good put at lower duty cycles but yields lower good put at higher duty cycles. Coop XLM is a protocol that should be used when power savings is of paramount importance, such as in the case of WSNs. In future studies, it would also be interesting to use cooperative communication for increased hop length. Instead of varying transmission power, the cooperative nodes would instead transmit simultaneously at full power. The transmitted signal would be able to go farther for the same received SNR. This scheme would decrease the number of hops required for a packet to reach the sink; thus, the power used to propagate a packet through the entire network would decrease. This scheme also has its challenges. For example, using the XLM protocol, how would the cooperative nodes be able to select a common destination node? There is no guarantee that the nodes that heard the cooperative RTS would be able to send a CTS with an SNR that would be received by all the cooperative nodes.

Cooperative Communication for Wireless Sensors Network : A Mac Protocol solution

The motivation of this paper is to fill the gap between cooperative communications technique developed for physical layer and an appropriate MAC layer scheme for Wireless Sensor Networks (WSN). The cooperative radio techniques, also known as Virtual Multiple Input Single Output (VMISO, originate from works using diversity techniques with collocated multiple antennas. Instead of using multiple antennas to take advantage of the diversity, the cooperative communication uses multiple nodes equipped with a single antenna using distributed coding scheme to achieve similar gains. The cooperative communication

scheme is also inherently a network solution, and there are issues at multiple levels of the network stack to solve in order to reach the gain offered by the diversity. This paper mainly focus on finding the good tradeoff between the issues at the Mac layer and the physical layer performances. We developed a Mac layer scheme that used a distributed algorithm to select a relay node in an efficient way without extra overhead in signaling and processing. The reliability of the communications that use cooperation helps us to design an acknowledgment agnostic solution. The paper is organized as follows. In section 2, we present the related work. We introduce the design of our solution and the specific mechanisms we developed. In section 4, we present performance results and an analysis. Finally we conclude the paper and present some future works.

RELATED WORK Recently, a new class of radio diversity techniques called cooperative communication derived from diversity techniques using co-located antennas has received lot of interests. Laneman et al. and others have developed a set of cooperative communication scheme for distributed wireless network like: ad hoc networks or sensors networks. Theirs respective works has paved the way for a lot of studies using cooperative transmission on a real Mac layer framework. Ji et al.and Lin et al. proposed different framework for Cooperative MAC protocol. These solutions are based on network-assisted diversity multiple access (NDMA). These Authors present a novel throughput-efficient medium access scheme for WSN. This scheme enables a node to retrieve a packet from many previously received packets (MPR). In [Liu et al. proposed the first cooperative MAC protocol called CoopMac based on the well knows IEEE 802.11 protocol. They defined two alternative solutions CoopMAC I and CoopMAC II. In CoopMAC I, a new frame HTS (Helper ready To Send) is added to the IEEE 802.11, to inform others that an alternative node (a relay node) will help the sender to transmit more efficiently. Then, in CoopMAC II, HTS frame is not used; instead they used the RTS header to advise which node should act as a relay node. Chou et al. present a solution to perform cooperative communication in distributed wireless networks. Authors claim that only one relay must participate in the cooperative transmission. In order to select the relay node among its neighbors, they developed

mechanisms such as a busy tone and a special RTS (Relay-RTS). This RRTS is used with the classic RTS/CTS mechanism to inform the source and the relay node chosen. Most of these solutions used extra messages in order to setup the cooperative process and select the relay node. In a WSN context, where the resources are limited, the use of these signaling packets should be avoided to reduce the power consumption. a new cooperative MAC protocol tailored for WSN is proposed. In order to fulfill the set of constraints imposed by the cooperative communication scheme and the wireless sensors scheme we have developed an algorithm allowing the automatic selection of the forwarder node (relay node) using only few message exchanges during the network setup phase. To optimize the selection of the relay node algorithm we are using a cross-layer design to fetch information from the physical layer. Our simulations show that the proposed solutions brought enhancements (packet delivery ratio) and reliability to the network in the case of a low dense network. Nevertheless in case of a massively dense network, the use of cooperation techniques do not bring any enhancements and even will have a negative impact on the performances. This is due to the fact that most of wireless links in the network are good enough to carry traffic with very few loss provoked by interferences coming from others transmitting node. This issue is not balancing the overload of a cooperative communication. This concern lead us toward fact that any Mac layer scheme that are exploiting cooperative communication should be used in adaptive way, in order to be efficient in any case. In our future works we will focus on optimizing the group identifier decision process with the aim of finding an even more efficient selection of a relay nodes also well suited for sensor networks.

Cooperative Routing in Static Wireless Networks WE study the problem of routing, cooperation, and energy efficiency in static wireless ad hoc networks. In these networks, the nodes often spend most of their energy on communication. In many applications, the nodes are small and have limited and non replenishable energy supplies. For this reason, energy conservation is critical for extending the lifetime of these networks, and it is not surprising that the problem of energy efficiency and energy-efficient communication in ad hoc networks has received a lot of attention in the past several years. This problem, however, can be approached from two different angles: energy-efficient route selection algorithms at the

network layer or efficient communication schemes at the physical layer. While each of these two areas has received a lot of attention separately, not much work has been done on jointly addressing these two problems. Our analysis in this paper tackles this less studied area. The amount of energy required to establish a link between two nodes is usually assumed to be proportional to the distance between the nodes raised to a constant power. This fixed exponent, referred to as the path-loss exponent, is usually assumed to be between 2 to 4. Due to this relationship, it is beneficial, in terms of energy saving, to relay the information through a multihop route. Multihop routing extends the coverage by allowing a node to communicate with nodes that would have otherwise been outside of its transmission range. The problem of finding a minimum energy route becomes more interesting once some special properties of the wireless medium are taken into account. In particular, in this work, we exploit the wireless broadcast property and the benefit of transmission side diversity to achieve energy savings. When omnidirectional antennas are used for communication, the signal transmitted by a node is received by all nodes within a certain radius. For example, in Fig. 1, the signal transmitted by s is received by both nodes 1 and 2. This property, usually referred to as the wireless broadcast advantage (WBA), was first studied in a network context in . Clearly, this property of the wireless physical medium significantly changes many network layer route selection algorithms. The problem of finding the minimum energy multicast and broadcast tree in a wireless network is studied in and . This problem is shown to be NP-Complete in and . Maric and Yates look at the problem of efficient broadcasting when signal energy accumulation over multiple transmissions is possible. WBA also adds substantial complexity to route selection algorithms even in non broad cast scenarios. For example, this model is used in in the context of selecting the minimum energy link and node disjoint paths in a wireless network. Another interesting property of the wireless medium is the benefit of space diversity at the physical layer. This type of diversity is achieved by employing multiple antennas on the transmitter or the receiver side. It is well known that transmission and receiver space diversity can result in lower error probability or higher transmission capacity. An overview of different transmission diversity techniques is given in. In our paper, we assume that each node is only equipped with a single antenna. However, we allow for the possibility that several nodes can cooperate with each other in transmitting the information to other nodes, and through this cooperation effectively achieve similar energy savings as a multiple antenna system. Architecture for achieving the required

level of coordination among the cooperating nodes is discussed in. We shall refer to the energy savings due to cooperative transmission by several nodes as the wireless cooperation advantage (WCA). Our aim in this paper is to take advantage of the wireless broadcast property and the transmission side diversity created through cooperation to reduce the end-to-end energy consumption in routing the information between two nodes. To make it clear, consider a simple example. For the network shown in Fig. 2, assume that the minimum energy route from s to d is determined to be as shown using the shaded line. As discussed previously, the information transmitted by node s is received by nodes 1 and 2. After the first transmission, nodes s, 1, and 2 have the information and can cooperate in getting the information to 3, as shown in Fig. 2. Our goal is to quantify the energy savings that can be achieved through cooperation and to find the optimal cooperative route in order to maximize energy savings. We do not consider other issues such as the level of coordination among the cooperating nodes required, and simply assume that the required coordination can take place by employing appropriate hardware architecture at each node and using a low-bandwidth control channel. We assume that this coordination consumes an amount of energy that is negligible in comparison to the energy required for relaying the actual data. Moreover, we realize that the use of cooperative relaying may require additional transmissions and, hence, be inefficient in terms of bandwidth utilization. However, again, our goal in this paper is merely to quantify the energy savings achievable through cooperation, and hence, we do not concern ourselves with the issues of bandwidth consumption. Potentially, the mechanisms proposed in this paper are applicable to situations where bandwidth is plentiful but energy is scarce (e.g, communications in space). Of course, many of our assumptions are idealized, but allow for analytical tractability of the problem at hand.

2.5 Technology Used:

Initially the language was called as oak but it was renamed as Java in 1995. The primary motivation of this language was the need for a platform-independent (i.e., architecture neutral) language that could be used to create software to be embedded in various consumer electronic devices. Java is a programmers language.

Java is cohesive and consistent. Except for those constraints imposed by the Internet environment, Java gives the programmer, full control. Finally, Java is to Internet programming where C was to system programming.

Importance of Java to the Internet Java has had a profound effect on the Internet. This is because; Java expands the Universe of objects that can move about freely in Cyberspace. In a network, two categories of objects are transmitted between the Server and the Personal computer. They are: Passive information and Dynamic active programs. The Dynamic, Self-executing programs cause serious problems in the areas of Security and probability. But, Java addresses those concerns and by doing so, has opened the door to an exciting new form of program called the Applet. Java can be used to create two types of programs Applications and Applets : An application is a program that runs on our Computer under the operating system of that computer. It is more or less like one creating using C or C++. Javas ability to create Applets makes it important. An Applet is an application designed to be transmitted over the Internet and executed by a Java compatible web browser. An applet is actually a tiny Java program, dynamically downloaded across the network, just like an image. But the difference is, it is an intelligent program, not just a media file. It can react to the user input and dynamically change.
Features of Java Security

Every time you that you download a normal program, you are risking a viral infection. Prior to Java, most users did not download executable programs frequently, and those who did scan them for viruses prior to execution. Most users still worried about the possibility of infecting their systems with a virus. In addition, another type of malicious program exists that must be guarded against. This type of program can gather private information, such as credit card numbers, bank account balances, and passwords. Java answers both these concerns by providing a firewall between a network application and your computer.

When you use a Java-compatible Web browser, you can safely download Java applets without fear of virus infection or malicious intent.
Portability

For programs to be dynamically downloaded to all the various types of platforms connected to the Internet, some means of generating portable executable code is needed .As you will see, the same mechanism that helps ensure security also helps create portability. Indeed, Javas solution to these two problems is both elegant and efficient.
The Byte code

The key that allows the Java to solve the security and portability problems is that the output of Java compiler is Byte code. Byte code is a highly optimized set of instructions designed to be executed by the Java run-time system, which is called the Java Virtual Machine (JVM). That is, in its standard form, the JVM is an interpreter for byte code. Translating a Java program into byte code helps makes it much easier to run a program in a wide variety of environments. The reason is, once the run-time package exists for a given system, any Java program can run on it. Although Java was designed for interpretation, there is technically nothing about Java that prevents on-the-fly compilation of byte code into native code. Sun has just completed its Just In Time (JIT) compiler for byte code. When the JIT compiler is a part of JVM, it compiles byte code into executable code in real time, on a piece-by-piece, demand basis. It is not possible to compile an entire Java program into executable code all at once, because Java performs various run-time checks that can be done only at run time. The JIT compiles code, as it is needed, during execution.
Java Virtual Machine (JVM)

Beyond the language, there is the Java virtual machine. The Java virtual machine is an important element of the Java technology. The virtual machine can be embedded within a web browser or an operating system. Once a piece of Java code is loaded onto a machine, it is verified. As part of the loading process, a class loader is invoked and does byte code verification makes sure that the

code thats has been generated by the compiler will not corrupt the machine that its loaded on. Byte code verification takes place at the end of the compilation process to make sure that is all accurate and correct. So byte code verification is integral to the compiling and executing of Java code. Swing is a platform-independent, Model-View-Controller GUI framework for Java. It follows a single thread program ming model, and possesses the following traits: Extensible Swing is a highly partitioned architecture, which allows for the "plugging" of various custom implementations of specified framework interfaces: Users can provide their own custom implementation(s) of these components to override the default implementations. In general, Swing users can extend the framework by extending existing (framework) classes and/or providing alternative implementations of core components. Swing is a component-based framework. The distinction between objects and components is a fairly subtle point: concisely, a component is a well-behaved object with a known/specified characteristic pattern of behaviour. Swing objects asynchronously fire events, have "bound" properties, and respond to a well-known set of commands (specific to the component.) Specifically, Swing components are Java Beans components, compliant with the Java Beans Component Architecture specifications. Customizable Given the programmatic rendering model of the Swing framework, fine control over the details of rendering of a component is possible in Swing. As a general pattern, the visual representation of a Swing component is a composition of a standard set of elements, such as a "border", "inset", decorations, etc. Typically, users will programmatically customize a standard Swing component (such as a JTable) by assigning specific Borders, Colors, Backgrounds, opacities, etc., as the properties of that component. The core component will then use these properties (settings) to determine the appropriate renderers to use in painting its various aspects. However, it is also completely possible to create unique GUI controls with highly customized visual representation.

Configurable Swing's heavy reliance on runtime mechanisms and indirect composition patterns allows it to respond at runtime to fundamental changes in its settings. For example, a Swing-based application can change its look and feel at runtime. Further, users can provide their own look and feel implementation, which allows for uniform changes in the look and feel of existing Swing applications without any programmatic change to the application code. Lightweight UI Swing's configurability is a result of a choice not to use the native host OS's GUI controls for displaying itself. Swing "paints" its controls programmatically through the use of Java 2D APIs, rather than calling into a native user interface toolkit. Thus, a Swing component does not have a corresponding native OS GUI component, and is free to render itself in any way that is possible with the underlying graphics APIs. However, at its core every Swing component relies on an AWT container, since (Swing's) JComponent extends (AWT's) Container. This allows Swing to plug into the host OS's GUI management framework, including the crucial device/screen mappings and user interactions, such as key presses or mouse movements. Swing simply "transposes" its own (OS agnostic) semantics over the underlying (OS specific) components. So, for example, every Swing component paints its rendition on the graphic device in response to a call to component.paint(), which is defined in (AWT) Container. But unlike AWT components, which delegated the painting to their OS-native "heavyweight" widget, Swing components are responsible for their own rendering. This transposition and decoupling is not merely visual, and extends to Swing's management and application of its own OS-independent semantics for events fired within its component containment hierarchies. Generally speaking, the Swing Architecture delegates the task of mapping the various flavors of OS GUI semantics onto a simple, but generalized, pattern to the AWT container. Building on that generalized platform, it establishes its own rich and complex GUI semantics in the form of the JComponent model.

Loosely-Coupled and MVC The Swing library makes heavy use of the Model/View/Controller software design pattern[1], which conceptually decouples the data being viewed from the user interface controls through which it is viewed. Because of this, most Swing components have associated models (which are specified in terms of Java interfaces), and the programmer can use various default implementations or provide their own. The framework provides default implementations of model interfaces for all of its concrete components. The typical use of the Swing framework does not require the creation of custom models, as the framework provides a set of default implementations that are transparently, by default, associated with the corresponding JComponent child class in the Swing library. In general, only complex components, such as tables, trees and sometimes lists, may require the custom model implementations around the application-specific data structures. To get a good sense of the potential that the Swing architecture makes possible, consider the hypothetical situation where custom models for tables and lists are wrappers over DAO and/or EJB services.. Typically, Swing component model objects are responsible for providing a concise interface defining events fired, and accessible properties for the (conceptual) data model for use by the associated JComponent. Given that the overall MVC pattern is a loosely-coupled collaborative object relationship pattern, the model provides the programmatic means for attaching event listeners to the data model object. Typically, these events are model centric (ex: a "row inserted" event in a table model) and are mapped by the JComponent specialization into a meaningful event for the GUI component. For example, the JTable has a model called TableModel that describes an interface for how a table would access tabular data. A default implementation of this operates on a two-dimensional array. The view component of a Swing JComponent is the object used to graphically "represent" the conceptual GUI control. A distinction of Swing, as a GUI framework, is in its reliance on programmatically-rendered GUI controls (as opposed to the use of the native host OS's GUI controls). Prior to Java 6 Update 10, this distinction was a source of complications when mixing

AWT controls, which use native controls, with Swing controls in a GUI (see Mixing AWT and Swing components). Finally, in terms of visual composition and management, Swing favors relative layouts (which specify the positional relationships between components) as opposed to absolute layouts (which specify the exact location and size of components). This bias towards "fluid"' visual ordering is due to its origins in the applet operating environment that framed the design and development of the original Java GUI toolkit. (Conceptually, this view of the layout management is quite similar to that which informs the rendering of HTML content in browsers, and addresses the same set of concerns that motivated the former.) RELATIONSHIP OF AWT: Since early versions of Java, a portion of the Abstract Window Toolkit (AWT) has provided platform-independent APIs for user interface components. In AWT, each component is rendered and controlled by a native peer component specific to the underlying windowing system. By contrast, Swing components are often described as lightweight because they do not require allocation of native resources in the operating system's windowing toolkit. The AWT components are referred to as heavyweight components. Much of the Swing API is generally a complementary extension of the AWT rather than a direct replacement. In fact, every Swing lightweight interface ultimately exists within an AWT heavyweight component because all of the top-level components in Swing (JApplet, JDialog, JFrame, and JWindow) extend an AWT top-level container. Prior to Java 6 Update 10, the use of both lightweight and heavyweight components within the same window was generally discouraged due to Z-order incompatibilities. However, later version of Java have fixed these issues, and both Swing and AWT components can now be used in one GUI without Z-order issues. The core rendering functionality used by Swing to draw its lightweight components is provided by Java 2D, another part of JFC.

Relationship to SWT The Standard Widget Toolkit (SWT) is a competing toolkit originally developed by IBM and now maintained by the Eclipse community. SWT's implementation has more in common with the heavyweight components of AWT. This confers benefits such as more accurate fidelity with the underlying native windowing toolkit, at the cost of an increased exposure to the native platform in the programming model. The advent of SWT has given rise to a great deal of division among Java desktop developers, with many strongly favoring either SWT or Swing. Sun's development on Swing continues to focus on platform look and feel (PLAF) fidelity with each platform's windowing toolkit in the approaching Java SE 7 release (as of December 2006). There has been significant debate and speculation about the performance of SWT versus Swing; some hinted that SWT's heavy dependence on JNI would make it slower when the GUI component and Java need to communicate data, but faster at rendering when the data model has been loaded into the GUI, but this has not been confirmed either way. [2] A fairly thorough set of benchmarks in 2005 concluded that neither Swing nor SWT clearly outperformed the other in the general case. SWT serves the Windows platform very well but is considered by some to be less effective as a technology for cross-platform development. By using the high-level features of each native windowing toolkit, SWT returns to the issues seen in the mid 1990s (with toolkits like zApp, Zinc, XVT and IBM/Smalltalk) where toolkits attempted to mask differences in focus behaviour, event triggering and graphical layout. Failure to match behavior on each platform can cause subtle but difficult-to-resolve bugs that impact user interaction and the appearance of the GUI.

Relation between AWT and Swing

3. SYSTEM ANALYSIS
Introduction:
The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in systems engineering, information systems and software engineering, is the process of creating or altering systems, and the models and methodologies that people use to develop these systems. In software engineering the SDLC concept underpins many kinds of software development methodologies. These methodologies form the framework for planning and controlling the creation of an information system the software development process.

SOFTWARE MODEL OR ARCHITECTURE ANALYSIS: Structured project management techniques (such as an SDLC) enhance managements control over projects by dividing complex tasks into manageable sections. A software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. But none of the SDLC models discuss the key issues like Change management, Incident management and Release management processes within the SDLC process, but, it is addressed in the overall project management. In the proposed hypothetical model, the concept of user-developer interaction in the conventional SDLC model has been converted into a three dimensional model which comprises of the user, owner and the developer. In the proposed hypothetical model, the concept of user-developer interaction in the conventional SDLC model has been converted into a three dimensional model which comprises of the user, owner and the developer. The one size fits all approach to applying SDLC methodologies is no longer appropriate. We have made an attempt to address the above mentioned defects by using a new hypothetical model for SDLC described elsewhere. The drawback of addressing these management processes under the overall project management is missing of key technical issues pertaining to software development process that is, these issues are talked in the project management at the surface level but not at the ground level.

WHAT IS SDLC? A software cycle deals with various parts and phases from planning to testing and deploying software. All these activities are carried out in different ways, as per the needs. Each way is known as a Software Development Lifecycle Model(SDLC)[2].A software life cycle model is either a descriptive or prescriptive characterization of how software is or should be developed. A descriptive model describes the history of how a particular software system was developed. Descriptive models may be used as the basis for understanding and improving software development processes or for building empirically grounded prescriptive models. SDLC models * The Linear model (Waterfall) - Separate and distinct phases of specification and development. - All activities in linear fashion. - Next phase starts only when first one is

complete. * Evolutionary development - Specification and development are interleaved (Spiral, incremental, prototype based, Rapid Application development). - Incremental Model (Waterfall in iteration), - RAD(Rapid Application Development) - Focus is on developing quality product in less time, - Spiral Model - We start from smaller module and keeps on building it like a spiral. It is also called Component based development. * Formal systems development - A mathematical system model is formally transformed to an implementation. * Agile Methods. - Inducing flexibility into development. * Reuse-based development - The system is assembled from existing components.

The General Model

Software life cycle models describe phases of the software cycle and the order in which those phases are executed. There are tons of models, and many companies adopt their own, but all have very similar patterns. The general, basic model is shown below: General Life Cycle Model Each phase produces deliverables required by the next phase in the life cycle. Requirements are translated into design. Code is produced during implementation that is driven by the design. Testing verifies the deliverable of the implementation phase against requirements

Spiral Model
SPIRAL MODEL was defined by Barry Boehm in his 1988 article, A spiral Model of Software Development and Enhancement. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration models. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with a client reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project. The steps for Spiral Model can be generalized as follows:

The new system requirements are defined in as much details as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.

A preliminary design is created for the new system. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.

A second prototype is evolved by a fourfold procedure: 1. Evaluating the first prototype in terms of its strengths, weakness, and risks. 2. Defining the requirements of the second prototype. 3. Planning an designing the second prototype. 4. Constructing and testing the second prototype.

At the customer option, the entire project can be aborted if the risk is deemed too great. Risk factors might involved development cost overruns, operating-cost miscalculation, or any other factor that could, in the customers judgment, result in a less-than-satisfactory final product.

The existing prototype is evaluated in the same manner as was the previous prototype, and if necessary, another prototype is developed from it according to the fourfold procedure outlined above.

The preceding steps are iterated until the customer is satisfied that the refined prototype represents the final product desired.

The final system is constructed, based on the refined prototype. The final system is thoroughly evaluated and tested. Routine maintenance is carried on a continuing basis to prevent large scale failures and to minimize down time.

Spiral Life Cycle Model

The spiral model is similar to the incremental model, with more emphases placed on risk analysis. The spiral model has four phases: Planning, Risk Analysis, Engineering and Evaluation. A software project repeatedly passes through these phases in iterations (called Spirals in this model). The baseline spiral, starting in the planning phase, requirements are gathered and risk is assessed. Each subsequent spirals builds on the baseline spiral. Requirements are gathered during the planning phase. In the risk analysis phase, a process is undertaken to identify risk and alternate solutions. A prototype is produced at the end of the risk analysis phase. Software is produced in the engineering phase, along with testing at the end of the phase. The evaluation phase allows the customer to evaluate the output of the

project to date before the project continues to the next spiral. In the spiral model, the angular component represents progress, and the radius of the spiral represents cost.

Advantages

High amount of risk analysis Good for large and mission-critical projects. Software is produced early in the software life cycle.

3.1 Existing System

Two energy-efficient approximation algorithms are presented for finding a cooperative route in wireless networks. The two algorithms for finding one cooperative route are designed such that each hop consists of multiple sender nodes to one receiver node. Existing methods focus on MAC layer design for networks with cooperative transmission. When no acknowledgement is received from the destination after timeout, the cooperative nodes, which correctly received the data, retransmit it. Only one cooperative node retransmits at any time, and the other cooperative nodes flush their copy once they hear the retransmission. Hence, this work focuses on reducing the transmission errors, without benefiting from the energy savings of simultaneous transmissions. In the multiple-inputmultiple-output (MIMO) systems, each node is equipped with multiple antennas. Information is transmitted from the sender node by multiple antennas and received by multiple antennas at the receiver node. The close proximity of the antennas at the transmitting nodes and of the antennas at the receiving nodes makes synchronization easier to implement. The ability of nodes to sense the carrier and to measure the interference level can be used to decide on the number of antennas that are employed for transmission.

3.1.2 Problem statement

The problem of energy-efficient routing in wireless networks that support cooperative transmission was formulated in. In, two energy-efficient approximation algorithms are presented for finding a cooperative route in wireless networks. The two algorithms for finding one cooperative route are designed such that each hop consists of multiple sender nodes to one receiver node. One of the algorithms (CAN) is used throughout this paper for performance comparison.

3.2 Proposed System

In this paper we propose a cooperative communication model with multiple nodes on both ends of a hop and with each data packet being transmitted only once per hop. In our model of cooperative transmission, every node on the path from the source node to the destination node becomes a cluster head, with the task of recruiting other nodes in its neighborhood and coordinating their transmissions. Consequently, the classical route from a source node to a sink node is replaced with a multihop cooperative path, and the classical point-to-point communication is replaced with many-to-many cooperative communication. The path can then be described as having a width, where the width of a path at a particular hop is determined by the number of nodes on each end of a hop. Every node in the receiving cluster receives from every node in the sending cluster. Sending nodes are synchronized, and the power level of the received signal at a receiving node is the sum of all the signal powers coming from all the sender nodes. This reduces the likelihood of a packet being received in error. We assume that some mechanism for error detection is incorporated into the packet format, so a node that does not receive a packet correctly will not transmit on the next hop in the path. Our cooperative transmission protocol consists of two phases. In the routing phase, the initial path between the source and the sink nodes is discovered as an underlying one-node-thick path. Then, the path undergoes a thickening process in the recruiting-and-transmitting phase. In this phase, the nodes on the initial path become cluster heads, which recruit additional adjacent nodes from their neighborhood.

3.3.1Advantages

A key advantage of cooperative transmission is the increase of the received power at the receiving nodes. This decreases the probability of bit error and of packet loss. Alternatively, the sender nodes can use smaller transmission power for the same probability of bit error, thus reducing the energy consumption. One of the goals of this paper is to study the energy savings achieved through cooperation. We also study the increase in the reliability of packet delivery, given some level of cooperation among the nodes. Finally, we also study the capacity of the cooperative transmission protocol.

3.4 FEASIBILITY STUDY

Preliminary investigation examine project feasibility, the likelihood the system will be useful to the organization. The main objective of the feasibility study is to test the Technical, Operational and Economical feasibility for adding new modules and debugging old running system. All system is feasible if they are unlimited resources and infinite time. There are aspects in the feasibility study portion of the preliminary investigation: Technical Feasibility Operational Feasibility Economical Feasibility

3.4.1 ECONOMIC FEASIBILITY A system can be developed technically and that will be used if installed must still be a good investment for the organization. In the economical feasibility, the development cost in creating the system is evaluated against the ultimate benefit derived from the new systems. Financial benefits must equal or exceed the costs. The system is economically feasible. It does not require any addition hardware or software. Since the interface for this system is developed using the existing resources and technologies available at NIC, There is nominal expenditure and economical feasibility for certain.

3.4.2 OPERATIONAL FEASIBILITY Proposed projects are beneficial only if they can be turned out into information system. That will meet the organizations operating requirements. Operational feasibility aspects of the project are to be taken as an important part of the project implementation. Some of the important issues raised are to test the operational feasibility of a project includes the following: Is there sufficient support for the management from the users? Will the system be used and work properly if it is being developed and implemented? Will there be any resistance from the user that will undermine the possible application benefits? This system is targeted to be in accordance with the above-mentioned issues. Beforehand, the management issues and user requirements have been taken into consideration. So there is no question of resistance from the users that can undermine the possible application benefits. The well-planned design would ensure the optimal utilization of the computer resources and would help in the improvement of performance status.

3.4.3 TECHNICAL FEASIBILITY The technical issue usually raised during the feasibility stage of the investigation includes the following: Does the necessary technology exist to do what is suggested? Do the proposed equipments have the technical capacity to hold the data required to use the new system? Will the proposed system provide adequate response to inquiries, regardless of the number or location of users? Can the system be upgraded if developed? Are there technical guarantees of accuracy, reliability, ease of access and data security? Earlier no system existed to cater to the needs of Secure Infrastructure Implementation System. The current system developed is technically feasible. It is a web based user interface for audit workflow at NIC-CSD. Thus it provides an easy access to the users. The databases

purpose is to create, establish and maintain a workflow among various entities in order to facilitate all concerned users in their various capacities or roles. Permission to the users would be granted based on the roles specified. Therefore, it provides the technical guarantee of accuracy, reliability and security. The software and hard requirements for the development of this project are not many and are already available in-house at NIC or are available as free as open source. The work for the project is done with the current equipment and existing software technology. Necessary bandwidth exists for providing a fast feedback to the users irrespective of the number of users using the system.

4. SYSTEM REQUIREMENTS SPECIFICATION

4.1 INTRODUCTION A Software Requirements Specification (SRS) a requirements specification for a software system is a complete description of the behavior of a system to be developed. It includes a set of use cases that describe all the interactions the users will have with the software. In addition to use cases, the SRS also contains non-functional requirements. Non-functional requirements are

requirements which impose constraints on the design or implementation (such as performance engineering requirements, quality standards, or design constraints). System requirements specification: A structured collection of information that embodies the requirements of a system. A business analyst, sometimes titled system analyst, is responsible for analyzing the business needs of their clients and stakeholders to help identify business problems and propose solutions. Within the systems development life cycle domain, the BA typically performs a liaison function between the business side of an enterprise and the information technology department or external service providers. Projects are subject to three sorts of requirements:

Business requirements describe in business terms what must be delivered or accomplished to provide value. Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set of business requirements.)

Process requirements describe activities performed by the developing organization. For instance, process requirements could specify specific methodologies that must be followed, and constraints that the organization must obey.

Product and process requirements are closely linked. Process requirements often specify the activities that will be performed to satisfy a product requirement. For example, a maximum development cost requirement (a process requirement) may be imposed to help achieve a maximum sales price requirement (a product requirement); a requirement that the product be maintainable (a Product requirement) often is addressed by imposing requirements to follow particular development styles 4.2 PURPOSE A systems engineering, a requirement can be a description of what a system must do, referred to as a Functional Requirement. This type of requirement specifies something that the delivered system must be able to do. Another type of requirement specifies something about the system itself, and how well it performs its functions. Such requirements are often called Non-functional requirements, or 'performance requirements' or 'quality of service requirements.' Examples of

such requirements include usability, availability, reliability, supportability, testability and maintainability. A collection of requirements define the characteristics or features of the desired system. A 'good' list of requirements as far as possible avoids saying how the system should implement the requirements, leaving such decisions to the system designer. Specifying how the system should be implemented is called "implementation bias" or "solution engineering". However, implementation constraints on the solution may validly be expressed by the future owner, for example for required interfaces to external systems; for interoperability with other systems; and for commonality (e.g. of user interfaces) with other owned products. In software engineering, the same meanings of requirements apply, except that the focus of interest is the software itself.

4.3 FUNCTIONAL REQUIREMENTS

4.4 NON FUNCTIONAL REQUIREMENTS

The major non-functional Requirements of the system are as follows Usability The system is designed with completely automated process hence there is no or less user intervention. Reliability The system is more reliable because of the qualities that are inherited from the chosen platform java. The code built by using java is more reliable. Performance

This system is developing in the high level languages and using the advanced front-end and back-end technologies it will give response to the end user on client system with in very less time. Supportability The system is designed to be the cross platform supportable. The system is supported on a wide range of hardware and any software platform, which is having JVM, built into the system. Implementation The system is implemented in web environment using struts framework. The apache tomcat is used as the web server and windows xp professional is used as the platform. Interface the user interface is based on Struts provides HTML Tag

4.5 HARDWARE REQUIREMENTS

System Hard Disk : : Pentium IV 2.4 GHz. 40 GB.

Floppy Drive Monitor Mouse Ram

: : : :

1.44 Mb. 15 VGA Color. Logitech. 512 MB.

4.6 SOFTWARE REQUIREMENTS

Operating System Language Technology Back End : : : : Windows xp , Linux Java1.4 or more Swing, AWT No Database

5. SYSTEM DESIGN
5.1 SYSTEM SPECIFICATIONS OBJECTIVES
The objective of this sub-project is to develop tools and methods to support the earlier phases of systems development; for implementation independent specification and verification, and for subsequent synthesis of specifications into efficient implementations. The sub-project is divided into four sub-tasks: i) adopt/further develop a model for formal, high-level system specification and verification. ii) Demonstrate the efficacy of the developed model by applying it to a suitable part of the consortium demonstrator, the network terminal for broadband access. iii) Develop a systematic method to refine the specification into synthesizable code and a prototype tool which supports the refinement process and links it to synthesis and compilation tools.

Justification
Today it is common to specify systems on higher levels using some natural language (e.g. English). For large systems, where large amounts of information must be handled, problems arise with ambiguities and inconsistencies with such specifications. Errors that are introduced are often detected late in the design cycle - in the simulation of the design after much design work has already been carried out - if detected at all. By making the initial system specifications in a formal language at a high abstraction level, functionality can be verified/simulated earlier in the development process. Ambiguities and in consistencies can be avoided, errors can be discovered earlier, and the design iteration cycles can be shortened, thereby reducing development times. It is of critical importance that the specification language provides modeling concepts at a high abstraction level to allow the representation of system functions at a conceptual level without introducing unnecessary details.

Further, most of the languages that are used for implementation of HW / SWdesigns (e.g. VHDL, C++) do not lend themselves well to formal verification. This is because they lack a formally defined semantics or because the semantics is complex. A lack of formal semantics sometimes causes ambiguities in the interpretation of the designs. Our goal is to develop functional system specification method for telecom systems, to demonstrate its efficacy on an industrially relevant example and to develop a tool to support the mapping of such specifications to synthesizable VHDL/C++. The specification language in which the system level functions will be developed will have a formal semantics in order to support formal verification of specifications.

5.2 SYSTEM COMPONENTS:

The diagram shows a general view of how desktop and workstation computers are organized. Different systems have different details, but in general all computers consist of components (processor, memory, controllers, video) connected together with a bus. Physically, a bus consists of many parallel wires, usually printed (in copper) on the main circuit board of the computer. Data signals, clock signals, and control signals are sent on the bus back and forth between components. A particular type of bus follows a carefully written standard that describes the signals that are carried on the wires and what the signals mean. The PCI standard (for example) describes the PCI bus used on most current PCs.

6. IMPLEMENTATION
Introduction
A project is a series of activities that aim at solving particular problems within a given time frame and in a particular location. The activities include time, money, human and material resources. Before achieving the objectives, a project goes through several stages. Implementation should take place at and be integrated into all stages of the project cycle. Implementation is the stage where all the planned activities are put into action. The most crucial stage in achieving a new successful system and in giving confidence on the system for the users that will work efficiently and effectively. The query optimizer is the component of a database management system that attempts to determine the most efficient way to execute a query. The optimizer considers the possible query plans for a given input query, and attempts to determine which of those plans will be the most efficient. Cost-based query optimizers assign an estimated "cost" to each possible query plan, and choose the plan with the smallest cost. Costs are used to estimate the runtime cost of evaluating the query, in terms of the number of I/O operations required, the CPU requirements, and other factors determined from the data dictionary. The set of query plans examined is formed by examining the possible access paths (e.g. index scan, sequential scan) and join algorithms (e.g. sort-merge join, hash join, nested loops). The search space can become quite large depending on the complexity of the SQL query. Cost estimation models are mathematical algorithms or parametric equations used to estimate the costs of a product or project. The results of the models are typically necessary to obtain approval to proceed, and are factored into business plans, budgets, and other financial planning and tracking mechanisms. The system can be implemented only after through testing and if it is found to work according to the specification. It involves careful planning, investigation of the current system and its constraints on implementation.

SAMPLE CODE: Main.java package sensor; import javax.swing.JOptionPane; import javax.swing.JFrame; import java.net.InetAddress; import javax.swing.UIManager; public class Main { public static void main(String[] args) { // TODO code application logic here try { String addr=InetAddress.getLocalHost().getHostAddress() try { // } catch (Exception ex) { System.out.println("Failed loading L&F: "); //System.out.println(ex); } Details dt=new Details(); String nodeId=(String)JOptionPane.showInputDialog(new JFrame(), "Enter Your Id"); // String pt=(String)JOptionPane.showInputDialog(new JFrame(), "Enter Your Port"); UIManager.setLookAndFeel("ch.randelshofer.quaqua.QuaquaLookAndFeel");

String no=(String)JOptionPane.showInputDialog(new JFrame(), "Enter no of known Nodes"); int Nodecnt=Integer.parseInt(no); for(int i=0;i<Nodecnt;i++) { String id=(String)JOptionPane.showInputDialog(new JFrame(), "Enter Id"); dt.info[dt.index][0]=id; dt.info[dt.index][1]=(String)JOptionPane.showInputDialog(new JFrame(), "Enter Cost"); int t=9000+Integer.parseInt(id); dt.info[dt.index][2]=String.valueOf(t) // dt.info[dt.index][1]=(String)JOptionPane.showInputDialog(new JFrame(), "Enter IP","127.0.0.1"); // dt.info[dt.index][2]=(String)JOptionPane.showInputDialog(new JFrame(), "Enter Port" dt.index++; //NodeFrame nf=new NodeFrame(nodeId,pt); NodeFrame nf=new NodeFrame(nodeId,nodeId); nf.setVisible(true); nf.setTitle("Node "+nodeId) //Receiver rr=new Receiver(nf,nodeId,pt); Receiver rr=new Receiver(nf,nodeId,nodeId); rr.start(); } catch(Exception e) { e.printStackTrace(); }}}

NodeFrame.java package sensor; import java.net.*; import javax.swing.JOptionPane; import javax.swing.JFrame; import javax.swing.table.DefaultTableModel; import java.util.Vector; import java.util.ArrayList;

import javax.swing.JLabel; import javax.swing.JPanel; import javax.swing.UIManager; import javax.swing.ImageIcon;

public class NodeFrame extends javax.swing.JFrame { Details dt=new Details(); String myid; String mypt; Receiver rr; public static ArrayList prepath; public static ArrayList preip; public static ArrayList preport; public static ArrayList precost;

public static ArrayList preid; String myip; public static int mn=0;

/** Creates new form NodeFrame */ public NodeFrame(String s1,String s2) { myid=s1; //mypt=s2;

int c=9000+Integer.parseInt(s2); mypt=String.valueOf(c);

try { //UIManager.setLookAndFeel("ch.randelshofer.quaqua.QuaquaLookAndFeel"); } catch (Exception ex) { System.out.println("Failed loading L&F: "); //System.out.println(ex); }

initComponents();

JPanel pane=(JPanel)this.getContentPane();; JLabel lab=new JLabel(); //lab.setBounds(-1,0,660,590); lab.setBounds(-1,0,695,600);

//lab.setIcon(new ImageIcon("images//cn.jpg")); lab.setIcon(new ImageIcon("images//img5.jpg")); pane.add(lab); setDefaultLookAndFeelDecorated(true); setResizable(false);

@SuppressWarnings("unchecked") // <editor-fold defaultstate="collapsed" desc="Generated Code">//GENBEGIN:initComponents private void initComponents() {

jTabbedPane1 = new javax.swing.JTabbedPane(); jPanel3 = new javax.swing.JPanel(); jScrollPane1 = new javax.swing.JScrollPane(); jTable1 = new javax.swing.JTable(); jPanel2 = new javax.swing.JPanel();

jButton1 = new javax.swing.JButton(); jPanel5 = new javax.swing.JPanel(); jPanel6 = new javax.swing.JPanel(); jScrollPane3 = new javax.swing.JScrollPane(); jTable3 = new javax.swing.JTable(); jPanel4 = new javax.swing.JPanel(); jLabel2 = new javax.swing.JLabel(); jTextField1 = new javax.swing.JTextField(); jButton2 = new javax.swing.JButton(); jScrollPane2 = new javax.swing.JScrollPane(); jTable2 = new javax.swing.JTable(); jLabel4 = new javax.swing.JLabel(); jTextField3 = new javax.swing.JTextField(); jButton4 = new javax.swing.JButton();

setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);

jTabbedPane1.setFont(new java.awt.Font("Tahoma", 0, 14));

jTable1.setModel(new javax.swing.table.DefaultTableModel( new Object [][] {

}, new String [] { "Path"

} )); jScrollPane1.setViewportView(jTable1);

javax.swing.GroupLayout jPanel3Layout = new javax.swing.GroupLayout(jPanel3); jPanel3.setLayout(jPanel3Layout); jPanel3Layout.setHorizontalGroup( jPanel3Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel3Layout.createSequentialGroup() .addGap(62, 62, 62) .addComponent(jScrollPane1, javax.swing.GroupLayout.PREFERRED_SIZE, 480, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap(55, Short.MAX_VALUE)) ); jPanel3Layout.setVerticalGroup( jPanel3Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(javax.swing.GroupLayout.Alignment.TRAILING, jPanel3Layout.createSequentialGroup() .addContainerGap(61, Short.MAX_VALUE) .addComponent(jScrollPane1, javax.swing.GroupLayout.PREFERRED_SIZE, 334, javax.swing.GroupLayout.PREFERRED_SIZE) .addGap(31, 31, 31)) );

jTabbedPane1.addTab("Known Node Path List", jPanel3);

jButton1.setFont(new java.awt.Font("Tahoma", 0, 12)); jButton1.setText("Construct"); jButton1.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButton1ActionPerformed(evt); } });

javax.swing.GroupLayout jPanel2Layout = new javax.swing.GroupLayout(jPanel2); jPanel2.setLayout(jPanel2Layout); jPanel2Layout.setHorizontalGroup( jPanel2Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel2Layout.createSequentialGroup() .addGap(260, 260, 260) .addComponent(jButton1) .addContainerGap(250, Short.MAX_VALUE)) ); jPanel2Layout.setVerticalGroup( jPanel2Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel2Layout.createSequentialGroup() .addGap(138, 138, 138) .addComponent(jButton1) .addContainerGap(263, Short.MAX_VALUE)) );

jTabbedPane1.addTab("Construction", jPanel2);

javax.swing.GroupLayout jPanel6Layout = new javax.swing.GroupLayout(jPanel6); jPanel6.setLayout(jPanel6Layout); jPanel6Layout.setHorizontalGroup( jPanel6Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGap(0, 488, Short.MAX_VALUE) ); jPanel6Layout.setVerticalGroup( jPanel6Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGap(0, 360, Short.MAX_VALUE) );

jTable3.setModel(new javax.swing.table.DefaultTableModel( new Object [][] {

}, new String [] { "Source", "Destination", "Path", "Message" } )); jScrollPane3.setViewportView(jTable3);

javax.swing.GroupLayout jPanel5Layout = new javax.swing.GroupLayout(jPanel5); jPanel5.setLayout(jPanel5Layout);

jPanel5Layout.setHorizontalGroup( jPanel5Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(javax.swing.GroupLayout.Alignment.TRAILING, jPanel5Layout.createSequentialGroup() .addContainerGap(94, Short.MAX_VALUE) .addComponent(jScrollPane3, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addGap(49, 49, 49)) .addGroup(jPanel5Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel5Layout.createSequentialGroup() .addGap(41, 41, 41) .addComponent(jPanel6, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap(68, Short.MAX_VALUE))) ); jPanel5Layout.setVerticalGroup( jPanel5Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(javax.swing.GroupLayout.Alignment.TRAILING, jPanel5Layout.createSequentialGroup() .addContainerGap(90, Short.MAX_VALUE) .addComponent(jScrollPane3, javax.swing.GroupLayout.PREFERRED_SIZE, 314, javax.swing.GroupLayout.PREFERRED_SIZE) .addGap(22, 22, 22)) .addGroup(jPanel5Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(javax.swing.GroupLayout.Alignment.TRAILING, jPanel5Layout.createSequentialGroup()

.addContainerGap(55, Short.MAX_VALUE) .addComponent(jPanel6, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap())) );

jTabbedPane1.addTab("Message Details", jPanel5);

jLabel2.setFont(new java.awt.Font("Tahoma", 0, 12)); jLabel2.setText("Enter Destination");

jButton2.setText("Get Route"); jButton2.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButton2ActionPerformed(evt); } });

jTable2.setModel(new javax.swing.table.DefaultTableModel( new Object [][] {

}, new String [] { "Route for Destination" }

)); jScrollPane2.setViewportView(jTable2);

jLabel4.setFont(new java.awt.Font("Tahoma", 0, 12)); jLabel4.setText("Enter Message");

jButton4.setText("Send "); jButton4.setEnabled(false); jButton4.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(java.awt.event.ActionEvent evt) { jButton4ActionPerformed(evt); } });

javax.swing.GroupLayout jPanel4Layout = new javax.swing.GroupLayout(jPanel4); jPanel4.setLayout(jPanel4Layout); jPanel4Layout.setHorizontalGroup( jPanel4Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel4Layout.createSequentialGroup() .addGap(122, 122, 122) .addGroup(jPanel4Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel4Layout.createSequentialGroup() .addComponent(jLabel4) .addGap(18, 18, 18)

.addComponent(jTextField3, javax.swing.GroupLayout.DEFAULT_SIZE, 249, Short.MAX_VALUE)) .addGroup(jPanel4Layout.createSequentialGroup() .addComponent(jLabel2) .addGap(40, 40, 40) .addComponent(jTextField1, javax.swing.GroupLayout.PREFERRED_SIZE, 51, javax.swing.GroupLayout.PREFERRED_SIZE))) .addGap(29, 29, 29) .addGroup(jPanel4Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.TRAILING , false) .addComponent(jButton4, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE) .addComponent(jButton2, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, Short.MAX_VALUE)) .addContainerGap(16, Short.MAX_VALUE)) .addGroup(jPanel4Layout.createSequentialGroup() .addContainerGap() .addComponent(jScrollPane2, javax.swing.GroupLayout.PREFERRED_SIZE, 575, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap(12, Short.MAX_VALUE)) ); jPanel4Layout.setVerticalGroup( jPanel4Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel4Layout.createSequentialGroup() .addGap(39, 39, 39) .addGroup(jPanel4Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.BASELIN E)

.addComponent(jLabel2) .addComponent(jTextField1, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addComponent(jButton2)) .addGroup(jPanel4Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(jPanel4Layout.createSequentialGroup() .addGap(24, 24, 24) .addGroup(jPanel4Layout.createParallelGroup(javax.swing.GroupLayout.Alignment.BASELIN E) .addComponent(jLabel4) .addComponent(jTextField3, javax.swing.GroupLayout.PREFERRED_SIZE, 27, javax.swing.GroupLayout.PREFERRED_SIZE))) .addGroup(jPanel4Layout.createSequentialGroup() .addGap(18, 18, 18) .addComponent(jButton4))) .addGap(55, 55, 55) .addComponent(jScrollPane2, javax.swing.GroupLayout.PREFERRED_SIZE, 205, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap(53, Short.MAX_VALUE)) );

jTabbedPane1.addTab("Routing Path", jPanel4);

javax.swing.GroupLayout layout = new javax.swing.GroupLayout(getContentPane()); getContentPane().setLayout(layout);

layout.setHorizontalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(layout.createSequentialGroup() .addGap(34, 34, 34) .addComponent(jTabbedPane1, javax.swing.GroupLayout.PREFERRED_SIZE, javax.swing.GroupLayout.DEFAULT_SIZE, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap(290, Short.MAX_VALUE)) ); layout.setVerticalGroup( layout.createParallelGroup(javax.swing.GroupLayout.Alignment.LEADING) .addGroup(javax.swing.GroupLayout.Alignment.TRAILING, layout.createSequentialGroup() .addContainerGap(115, Short.MAX_VALUE) .addComponent(jTabbedPane1, javax.swing.GroupLayout.PREFERRED_SIZE, 454, javax.swing.GroupLayout.PREFERRED_SIZE) .addContainerGap()) );

pack(); }// </editor-fold>//GEN-END:initComponents

private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {//GENFIRST:event_jButton1ActionPerformed // TODO add your handling code here: // Construct Button

System.out.println("index "+dt.index);

try { javax.swing.table.DefaultTableModel dm = (javax.swing.table.DefaultTableModel)jTable1.getModel();

String ip=InetAddress.getLocalHost().getHostAddress(); for(int i=0;i<dt.index;i++) { Vector v=new Vector(); String pp=myid+"-->"+dt.info[i][0]; //String p1=ip+"-->"+dt.info[i][1]; String p1=dt.info[i][1]; String p2=mypt+"-->"+dt.info[i][2]; System.out.println(pp); v.add(pp); dm.addRow(v); dt.path.add(pp); //dt.ipList.add(p1); dt.costList.add(p1); dt.portList.add(p2);

DatagramSocket ds=new DatagramSocket(); byte data[]=new byte[1000];

//String addr=InetAddress.getLocalHost().getHostAddress(); String addr="127.0.0.1"; //String ss="GetPath"+"#"+addr+"#"+mypt; // System.out.println(ss); //data=ss.getBytes(); for(int i=0;i<dt.index;i++) { String ss="GetPath"+"#"+addr+"#"+mypt+"#"+dt.info[i][1]; //System.out.println(ss); data=ss.getBytes(); //DatagramPacket dp=new DatagramPacket(data,0,data.length,InetAddress.getByName(dt.info[i] [1]),Integer.parseInt(dt.info[i][2])); DatagramPacket dp=new DatagramPacket(data,0,data.length,InetAddress.getByName("127.0.0.1"),Integer.parseInt(dt.info [i][2])); ds.send(dp); //System.out.println("send to :"+dt.info[i][1]+" : "+dt.info[i][2]); System.out.println("get path send to :"+dt.info[i][2]); }

jButton1.setEnabled(false); } catch(Exception e) { e.printStackTrace(); }

}//GEN-LAST:event_jButton1ActionPerformed

private void jButton2ActionPerformed(java.awt.event.ActionEvent evt) {//GENFIRST:event_jButton2ActionPerformed // TODO add your handling code here:

// Get Route Button

prepath=new ArrayList(); preip=new ArrayList(); preport=new ArrayList(); precost=new ArrayList();

DefaultTableModel dtm2 = (DefaultTableModel)jTable2.getModel(); int row1=dtm2.getRowCount();

for(int i=0;i<row1;i++) { dtm2.removeRow(0); }

String did=jTextField1.getText().trim();

//javax.swing.table.DefaultTableModel dm1 = (javax.swing.table.DefaultTableModel)jTable1.getModel(); //int rcnt=dm1.getRowCount();

int cc=0; ArrayList al=new ArrayList(); for(int i=0;i<dt.path.size();i++) { String ss=dt.path.get(i).toString(); //String ss1=dt.ipList.get(i).toString(); String ss1=dt.costList.get(i).toString(); String ss2=dt.portList.get(i).toString();

int ind1=ss.lastIndexOf('>')+1; String dd=ss.substring(ind1); //System.out.println(ss+" : "+dd+" : "+id); if(dd.equals(did)) { cc++; al.add(ss); prepath.add(ss); //preip.add(ss1); precost.add(ss1); preport.add(ss2); }

} System.out.println("path list "+cc+" : "+al.size()+" : "+al); try { myip=InetAddress.getLocalHost().getHostAddress(); //String ms="FindPath#"+myid+"#"+myip+"#"+mypt+"#"+did; //String ms="FindPath#"+myid+"#"+"127.0.0.1"+"#"+mypt+"#"+did; //byte bt[]=ms.getBytes();

DatagramSocket ds=new DatagramSocket(); for(int i=0;i<dt.index;i++) { String ms="FindPath#"+myid+"#"+dt.info[i][1]+"#"+mypt+"#"+did; byte bt[]=ms.getBytes(); //DatagramPacket dp=new DatagramPacket(bt,0,bt.length,InetAddress.getByName(dt.info[i][1]),Integer.parseInt(dt.info[i] [2])); DatagramPacket dp=new DatagramPacket(bt,0,bt.length,InetAddress.getByName("127.0.0.1"),Integer.parseInt(dt.info[i] [2])); ds.send(dp); }

/*System.out.println("Main route "+mn+prepath.get(mn).toString()); Vector v=new Vector(); v.add(prepath.get(mn)); dtm2.addRow(v);*/

jButton4.setEnabled(true); } catch(Exception e) { e.printStackTrace(); } }//GEN-LAST:event_jButton2ActionPerformed

private void jButton4ActionPerformed(java.awt.event.ActionEvent evt) {//GENFIRST:event_jButton4ActionPerformed // TODO add your handling code here: try { // send message

String did=jTextField1.getText().trim(); String mes=jTextField3.getText().trim();

ArrayList dpath=new ArrayList(); ArrayList dcost=new ArrayList();

DefaultTableModel tm1=(DefaultTableModel)jTable2.getModel(); int row=tm1.getRowCount();

int fl=0; for(int i=0;i<row;i++) { String s1=tm1.getValueAt(i, 0).toString(); String s2[]=s1.split("-->"); if(s2.length>=3) // s2.length>3 { dpath.add(s1); dcost.add(precost.get(i)); fl=1; } } System.out.println("dpath "+dpath); System.out.println("dcost "+dcost); System.out.println("fl "+fl);

if(fl==0) { DatagramSocket ds=new DatagramSocket(); String ms="Message#"+myid+"#"+did+"#"+myid+"-->"+did+"#"+mes+"#"+did; byte dd[]=ms.getBytes(); DatagramPacket dp=new DatagramPacket(dd,0,dd.length,InetAddress.getByName("127.0.0.1"),Integer.parseInt(did) +9000); ds.send(dp); }

else { String a1[]=dcost.get(0).toString().split("-->"); int cd1=0; for(int i=0;i<a1.length;i++) { cd1=cd1+Integer.parseInt(a1[i]); }

int lc=cd1; String lp=dpath.get(0).toString();

for(int i=1;i<dcost.size();i++) { String a2[]=dcost.get(i).toString().split("-->"); int cd2=0; for(int j=0;j<a2.length;j++) { cd2=cd2+Integer.parseInt(a2[j]); }

if(cd1>cd2) { lc=cd2; lp=dpath.get(i).toString();

cd1=cd2; }

} System.out.println("request to ---> "+lp+" : "+lc);

DatagramSocket ds=new DatagramSocket();

String re[]=lp.split("-->"); for(int i=1;i<re.length;i++) { String sg="Message#"+re[i-1]+"#"+re[i]+"#"+lp+"#"+mes+"#"+did; byte bte[]=sg.getBytes(); DatagramPacket dp=new DatagramPacket(bte,0,bte.length,InetAddress.getByName("127.0.0.1"),Integer.parseInt(re[i]) +9000); ds.send(dp); }

String sd1[]=dcost.get(0).toString().split("-->"); int cs1=Integer.parseInt(sd1[0]); int tc=cs1;

String sd2[]=dpath.get(0).toString().split("-->"); String tn=sd2[1];

for(int i=1;i<dcost.size();i++) { String sa[]=dcost.get(i).toString().split("-->"); int cs2=Integer.parseInt(sa[0]); if(cs1>cs2) { tc=cs2; String sa1[]=dpath.get(i).toString().split("-->"); tn=sa1[1];

cs1=cs2; } } // System.out.println("request to ---> "+tn+" : "+tc);

String ms="Request"+"#"+myid+"#"+tn+"#"+did+"#"+lp+"#"+lc; byte bte[]=ms.getBytes();

DatagramPacket dp=new DatagramPacket(bte,0,bte.length,InetAddress.getByName("127.0.0.1"),tc+9000); ds.send(dp);

} } catch(Exception e) { e.printStackTrace(); } }//GEN-LAST:event_jButton4ActionPerformed

/** * @param args the command line arguments */ public static void main(String args[]) { java.awt.EventQueue.invokeLater(new Runnable() { public void run() { // new NodeFrame().setVisible(true); } }); }

// Variables declaration - do not modify//GEN-BEGIN:variables private javax.swing.JButton jButton1; private javax.swing.JButton jButton2; private javax.swing.JButton jButton4; private javax.swing.JLabel jLabel2;

private javax.swing.JLabel jLabel4; private javax.swing.JPanel jPanel2; private javax.swing.JPanel jPanel3; private javax.swing.JPanel jPanel4; private javax.swing.JPanel jPanel5; private javax.swing.JPanel jPanel6; private javax.swing.JScrollPane jScrollPane1; private javax.swing.JScrollPane jScrollPane2; private javax.swing.JScrollPane jScrollPane3; private javax.swing.JTabbedPane jTabbedPane1; public javax.swing.JTable jTable1; public static javax.swing.JTable jTable2; public javax.swing.JTable jTable3; private javax.swing.JTextField jTextField1; private javax.swing.JTextField jTextField3; // End of variables declaration//GEN-END:variables }

7. SYSTEM TESTING
General Software Testing is the process used to help identify the correctness, completeness, security and quality of developed computer software. Testing is a process of technical investigation, performed on behalf of stakeholders, that is intended to reveal quality-related

information about the product with respect to the context in which it is intended to operate. In general, software engineers distinguish software faults from software failures. Our project" Visual cryptography For Cheating Prevention is tested with the following testing methodologies. Developing Methodologies The test process begins by developing a comprehensive plan to test the general functionality and special features on a variety of platform combinations. Strict quality control procedures are used. The process verifies that the application meets the requirements specified in the system requirements document and is bug free. The following are the considerations used to develop the framework for developing the test methodologies. Acquire and study the test strategy A team very familiar with the business risks associated with the software normally develops test strategy, the test team develops tactics. Thus the test team needs to acquire and study the test strategy. The test tactics are analyzed and studied for finding our various test factors, risks and effects. The risk involved in our project is implementing the encoding of the image. So, the proper knowledge about the testing strategies should be gained in order to avoid such high level risks. Determine the type of development project The type of the development refers to the platform or methodology for developing the project. As it is been a simulation project we go for the prototyping. The prototypes are simply predefined structure or model, which can be used for further modeling. By using the prototypes we can modify the existing module of the application for some other specific operations. Here the test tactics is to verify that all the tools are used properly and to test functionality. Determine the type of software system The type of software system relates to the type of processing which will be encountered by the system. In this project, the software system we prefer to use is Java . We have chosen Java for its portability and its support to graphics & multimedia specifically for image processing. Determine the scope of the software system

The scope of the project refers to the overall activities or operation to be included into the system being tested. The scope of the new system varies from that of the existing one. In the existing system, a large overhead occurs in contrast and pixel expansion. Also, the verification process is not efficient in the existing system. In this project, the pixel expansion is optimal because only two sub pixels are added each and every pixel. Also, each and every participants are verified or authentication. Identify the tactical risks The tactical risk is the subsets at a lower level of the strategic risks. The risks related to the application and its methodologies are identified. The risk involved in our project is implementing the encoding of the image. Determine when the testing should occur In the above processes we have identified the type of processing, scope and risks associated with our project. The testing can occur throughout all the phases of the project. During the analysis phase, the testing strategy and requirements are determined. In design phase, the complexities in design with respect to the requirements are determined and structural and functional test conditions are also tested. During implementation, the design consistency is determined. In test phase, the overall testing of the application is being done and previously the adequacy of the testing plan is also determined. In maintenance phase, the testing for modifying and reusing the system is done. Build the system test plan The test plan of the project should provide all the information on the application that is being tested. The test plan is simply a model that has to be followed during the progression of the testing. The test plan consists of the sequential set of procedures to test the application. Initially, the selection process of both secret and verification images are tested. Then the test is carried out for encoding of image, verification process and finally decoding process. Build the unit test plan In this case we are dividing the system into three different components or units each having specific functions. The three different components of the system are browser window

designing, browser events handling and adding speech to the browser. These units have their own test plan. The main purpose of the unit test plan is to eliminate the errors and bugs during the initial stage of the implementation. As the errors get debugged in the initial stage, the less complex the overall testing after integrating all the units of the system. The unit testing plan can be either simple or complex based on the functionality of that unit. TESTING TECHNIQUE - TOOL SELECTION PROCESS In this process the appropriate testing process is selected from various testing methodologies such as prototyping model, waterfall model etc and the selection is done by the means of analyzing the nature of the project. We go for Waterfall model. Select test factor This phase selects the appropriate test factor. The particular module of the project which is essential for the testing methodologies is sorted out first. This will help the testing process to be completed within time. The test factors for our project include encoding, verification and decoding process. Determine SDLC phase This phase involves the structural testing of the project which will be used for easy implementations of the functions. Though structural testing is so much associated with the coding phase, the structural testing should be carried out at all the phases of the lifecycle. These evaluates that all the structures are tested and sound. Identify the criteria to test In this phase the testing unit is trained with the necessary constraints and limit with which the project is to be tested. In our project the testing unit is trained to test whether the image to be encoded is in the PGM format. Select type of test Individual responsible for testing may prefer to select their own technique and tool based on the test situation. For selecting the appropriate testing process the project should be analyzed with the following three testing concepts:

1. Structural versus functional testing 2. Dynamic versus static testing 3. Manual versus automatic testing After analyzing through the above testing concepts we divided to test our project in Waterfall model testing methodology. Structural Testing Structural analysis based test sets are tend to uncover errors that occur during coding of the program. The properties of the test set are to reflect the internal structure of the program. Structural testing is designed to verify that the developed system and programs work as specified in the requirement. The objective is to ensure that the product is designed structurally sound and will function correctly. Functional Testing Functional testing ensures that the requirements are properly satisfied by the application system. The functions are those tasks that the system is designed to accomplish. This is not concerned with how processing occurs but rather with the results of the processing. The functional analysis based test sets tend to uncover errors that occurred in implementing requirements or design specifications. Select technique After selecting the appropriate testing methodology we have to select the necessary testing technique such as stress testing, execution testing, recovery testing, operation testing, compliance testing and security testing. We are performing operation testing

Figure 8.1 Testing technique and tool selection process

Select test method We have to select the testing method which is to be carried out throughout the lifecycle. The two different methods are static and dynamic. Dynamic testing needs the program to be executed completely before testing. This is a traditional concept where the faults detected at the end will be very hard to rectify. In static process the program is tested for each and every line and the testing process is allowed to pass through only after rectifying the occurred fault. These make this process more expensive, so a combination of both static and dynamic testing method Mode of testing It is necessary to select the test mode in which the testing method to be carried out. The two different modes are manual and automated tool. The real time projects needs frequent interactions. So, it is impossible to carry out the testing process by means of automated tool. Our project uses manual testing. Unit test technique This phase examines the techniques, assessment and management of unit testing and analysis. Testing and analysis strategies are categorized according to whether they goal is functional or structural or combination of these. It will assist a software engineer to define, conduct and evaluate unit tests and to assess new unit test techniques. System Testing Once the entire system has been built then it has to be tested against the "System Specification" to check if it delivers the features required. It is still developer focused, although specialist developers known as systems testers are normally employed to do it. In essence System Testing is not about checking the individual parts of the design, but about checking the system as a whole. In effect it is one giant component. System testing can involve a number of specialist types of test to see if all the functional and non-functional requirements have been met. Acceptance Testing Acceptance Testing checks the system against the "Requirements". It is similar to system s testing in that the whole system is checked but the important difference is the change in focus.

Systems Testing checks that the system that was specified has been delivered. Acceptance Testin g checks that the system delivers what was requested. The customer, and not the developer shoul d always do acceptance testing. The customer knows what is required from the system to achieve value in the business and is the only person qualified to make that judgment. Regression Testing This involves assurance that all aspects of an application system remain functional after testing. The introduction of change is the cause of problems in previously tested segments. It is retesting unchanged segments of the application system. It normally involves rerunning tests that have been previously executed to ensure that the same results can be achieved currently as achieved when the segments were last tested.

7.2 Test cases

+VE TEST CASES S .No 1 2 3 4 Test case Description Actual value Expected value Result True True True True

-VE TEST CASES S .No 1 2 3 4 Test case Description Actual value Expected value Result False False False False

Types of Testing: Smoke Testing: is the process of initial testing in which tester looks for the availability of all the functionality of the application in order to perform detailed testing on them. (Main check is for available forms) Sanity Testing: is a type of testing that is conducted on an application initially to check for the proper behavior of an application that is to check all the functionality are available before the detailed testing is conducted by on them. Regression Testing: is one of the best and important testing. Regression testing is the process in which the functionality, which is already tested before, is once again tested whenever some new change is added in order to check whether the existing functionality remains same. Re-Testing: is the process in which testing is performed on some functionality which is already tested before to make sure that the defects are reproducible and to rule out the environments issues if at all any defects are there.

Static Testing: is the testing, which is performed on an application when it is not been executed. Ex: GUI, Document Testing Dynamic Testing: is the testing which is performed on an application when it is being executed. Ex: Functional testing. Alpha Testing: it is a type of user acceptance testing, which is conducted on an application when it is just before released to the customer. Beta-Testing: it is a type of UAT that is conducted on an application when it is released to the customer, when deployed in to the real time environment and being accessed by the real time users. Monkey Testing: is the process in which abnormal operations, beyond capacity operations are done on the application to check the stability of it in spite of the users abnormal behavior. Compatibility testing: it is the testing process in which usually the products are tested on the environments with different combinations of databases (application servers, browsers etc) In order to check how far the product is compatible with all these environments platform combination. Installation Testing: it is the process of testing in which the tester try to install or try to deploy the module into the corresponding environment by following the guidelines produced in the deployment document and check whether the installation is successful or not. Adhoc Testing: Adhoc Testing is the process of testing in which unlike the formal testing where in test case document is used, with out that test case document testing can be done of an application, to cover that testing of the future which are not covered in that test case document. Also it is intended to perform GUI testing which may involve the cosmetic issues.

7.3 Results and Discussions

Energy-Efficient Protocol for Cooperative Networks 1. Running the project:

2.

Menu for showing co operative path:

Construction:

Message Details:

Routing path

When we press Construction Button It will show the path from Single node to Multiple nodes

1 2, 1 3, 1 4 are the directed paths from Node 1.According to above registration with Costs

Again u run the Co operative transmission for next node

Node 5:

The route from Node 5 to Node 6,Node 7 is Constructed with costs 13,14

Like this we done Communication with Node 6 to 2 nodes

6 77,6 9 Communication

Message Details processing:

Communication with 4 4:

Communication with 3 5,3 6 :-

3 7,3 77,3 9 will comes automatically will take the Support of Already existing Nodes

Node 2 2,2 23 Communication:-

Sending message from Node 1 3

1 3 with data I m from Node 1 to 3

Then Click Node 3 From Execution trace i.e

Then Go for Node 3 click Message details Button

Node 77 Registration:

Send data to receiver node 77 :

We send data from Node 2 77 (When we click Get Route It does nt give Route Because No Route Establishment with this )

Node 22:

Node 23:

Now we send data from 1 to 77

1 77 via Node 3,Node 6

Observe output at 3

Observe output at 6

Observe output at 77

Energy efficient at Index wise Based

Cost links with Cluster Heads: dt path [1-->2, 1-->3, 1-->4, 1-->3-->3, 1-->3-->3-->3, 1-->3-->6-->77, 1-->3-->3-->6-->77, 1->3-->6, 1-->3-->3-->6, 1-->3-->5-->6, 1-->3-->3-->3-->6] costList [12, 14, 14, 14-->33, 14-->33-->33, 14-->76-->8, 14-->33-->76-->8, 14-->76, 14-->33->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13] pre cost [14-->76, 14-->33-->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13] path cost [14-->76, 14-->33-->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13] costList [12, 14, 14, 14-->33, 14-->33-->33, 14-->76-->8, 14-->33-->76-->8, 14-->76, 14-->33->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13] pre cost [14-->76, 14-->33-->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13] path cost [14-->76, 14-->33-->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13] as1 1-->2-->23-->5-->6

dt path [1-->2, 1-->3, 1-->4, 1-->3-->3, 1-->3-->3-->3, 1-->3-->6-->77, 1-->3-->3-->6-->77, 1->3-->6, 1-->3-->3-->6, 1-->3-->5-->6, 1-->3-->3-->3-->6, 1-->3-->3-->5-->6] costList [12, 14, 14, 14-->33, 14-->33-->33, 14-->76-->8, 14-->33-->76-->8, 14-->76, 14-->33->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13, 12-->22-->55-->13] pre cost [14-->76, 14-->33-->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13, 12->22-->55-->13] path cost [14-->76, 14-->33-->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13, 12->22-->55-->13] costList [12, 14, 14, 14-->33, 14-->33-->33, 14-->76-->8, 14-->33-->76-->8, 14-->76, 14-->33->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13, 12-->22-->55-->13] pre cost [14-->76, 14-->33-->76, 14-->55-->13, 14-->33-->33-->76, 14-->33-->55-->13, 12->22-->55-->13]

8 CONCLUSION AND FUTURE ENHANCEMENTS

8.1 Conclusion
We evaluated the performance of cooperative transmission, where nodes in a sending cluster are synchronized to communicate a packet to nodes in a receiving cluster. In our communication model, the power of the received signal at each node of the receiving cluster is a sum of the powers of the transmitted independent signals of the nodes in the sending cluster. The increased power of the received signal, is the traditional single node to single node communication, leads to overall saving in network energy and to end-to-end robustness to data loss. We proposed an energy-efficient cooperative protocol, and we analyzed the robustness of the protocol to data packet loss. When the nodes are placed on a grid and as compared to the disjoint-paths scheme, we showed that our cooperative protocol reduces the probability of failure to deliver a packet to destination by a factor of up to 100, depending on the values of considered Parameters. Similarly, compared to the CAN protocol and to the one-path scheme, this reduction amounts to a factor of up to 10 000. Our study also analyzed the capacity upper bound of our protocol, showing improvement over the corresponding values of the other three protocols. The total energy consumption was analytically computed, illustrating substantial energy savings. For example, when nodes are positioned on a grid, the energy savings of our cooperative protocol over the CAN protocol is up to 80%. The size of the clusters, , should be relatively small, when the inter-cluster distance is small, with the optimal value of increasing with . For scenarios that are not covered by our theoretical analysis, we used simulation to evaluate and compare the protocols. For random placement of nodes, the simulation results show that our cooperative transmission protocol saves up to 20% of energy compared to the CAN protocol and up to 40% of energy compared with the disjoint-paths and the one-path scheme. Overall, the study demonstrates that the energy savings of our protocol, relative to the other schemes, do not substantially decrease even when the data packet loss approaches 50%. Our protocol also supports larger capacity and lower delay under high-load conditions, as compared to the CAN protocol, the one-path scheme, and the disjoint-paths scheme.