Mini Project

Abstract
Complementary to the transport capacity research, some recent work has formulated the multi hop capacity problem as a line network without additional network interference.These papers agree that numerous hops are helpful only in the power-limited" regime, that is where the spectral efficiency is low and overcoming noise is the primary concern. Both also find that in the bandwidth-limited regime". This project develop a new metric for quantifying end-to end throughput in Multi hop wireless networks, which we term random access transport capacity, since the interference model presumes uncoordinated transmissions. The metric quantifies the average maximum rate of successful end-to-end transmissions, multiplied by the communication distance, and normalized by the network area. We show that a simple upper bound on this quantity is computable in closed-form in terms of key network parameters when the number of retransmissions is not restricted and the hops are assumed to be equally spaced on a line between the source and destination. We also derive the optimum number of hops and optimal per hop success probability and show that our result follows the well-known square root scaling law while providing exact expressions for the preconstants, which contain most of the design-relevant network parameters. Numerical results demonstrate that the upper bound is accurate for the purpose of determining the optimal hop count and success (or outage) probability.
CHAPTER-1 INTRODUCTION
1.1 About the project: D etermining the capacity of distributed wireless networks (i.e., ad hoc networks) is one of the most general and challenging open problems in information theory. Straight forward applications of known information theoretic tools and inequalities becomes intractable almost immediately and have hence yielded little in the way of results. This motivates the exploration of approaches to describing ad hoc network throughput that, while falling short of strict information theory upper bound standards, do provide insight into the fundamental trends on achievable throughput.
The main line of present inquiry is to consider the transport capacity of an ad hoc network, which quantifies the bits per second that can be reliably communicated over some distance in the network. A significant merit of this approach is that it describes important aspects of the capacity region of all possible rate pairs in the network notably how the region scales. An alternative approach pioneered by the current authors and others has focused on computing achievable rate regions and network densities for different architectures and technologies. A key to this approach is to assume that the interferer locations are random, in particular that they are Poisson distributed over the plane. Although this is an idealization, it accurately models the scenario where transmitters are randomly scattered and uncoordinated, which seems to be quite a bit more realistic than other popular alternatives, such as assuming they are placed deterministically on a regular grid. This approach has allowed closed-form derivation of outage probability as well as the maximum allowable transmission density at a specified outage probability and data rate, the latter of which we have termed the transmission capacity. Since more hops must be taken in order to bring up the per hop SNR and allow the target SINR to be met. The second trend appears at first to be counter-intuitive because larger path loss exponents cause faster attenuation of the desired signal, which would seem to imply that more hops would be needed to maintain the signal strength. Strangely enough, at high interference density (and SNR) this is explained by the fact that higher path loss exponents provide better isolation from the aggregate interference, and so longer hops can be taken at the same target SINR despite the increased attenuation of the desired signal..
This project develop a new metric for quantifying end-to end throughput in Multi hop wireless networks, which we named as random access transport capacity, since the interference model presumes uncoordinated transmissions. The metric quantifies the average maximum rate of successful end-to-end transmissions, multiplied by the communication distance, and normalized by the network area. We show that a simple upper bound on this quantity is computable in closed-form in terms of key network parameters when the number of retransmissions is not restricted and the hops are assumed to be equally spaced on a line between the source and destination. We also derive the optimum number of hops and optimal per hop success probability and show that our result follows the well-known square root scaling law while providing exact expressions for the pre-constants, which contain most of the design-relevant network parameters. Numerical results demonstrate that the upper bound is accurate for the purpose of determining
the optimal hop count and success (or outage) probability. A multicast channel in HBH is identified by , where is the unicast address of the source and is a class-D IP address allocated by the source. This definition solves the address allocation problem while being compatible with SSMs channel definition. Therefore, HBH can support IP Multicast clouds as leaves of the distribution tree.
1.2 Scope A multicast routing protocol that implements multicast distribution through recursive unicast trees. The main goals of HBH are: to support unicast clouds, allowing incremental deployment; to have a stable tree structure, by minimizing the impact of receiver departures; and to construct low-cost trees. To reduce administrative costs. To lower error rates. To increase productivity. The design, analysis and deployment of wireless networks necessitate a fundamental understanding of how much information transfer they can support, as well as what the appropriate architectures and protocols are for operating them. This monograph addresses these questions by presenting various models and results that quantify the information The design, analysis and deployment of such wireless networks necessitate a fundamental understanding of how much information transfer they can support, as well as what the appropriate architectures and protocols are for operating them. This monograph addresses these questions by presenting various models and results that quantify the information transport capability of wireless networks, as well as shed light on architecture design from a high level point of view.
The models take into consideration important features such as the spatial distribution of nodes, strategies for sharing the wireless medium, the attenuation of signals with distance, and how information is to be transferred, whether it be by encoding, decoding, choice of power level, spatio-temporal scheduling of transmissions, choice of multi-hop routes, or other modalities of cooperation between nodes. An important aspect of the approach is to characterize how the information hauling capacity scales with the number of nodes in the network transport capability of wireless networks, as well as shed light on architecture design from a high level point of view.
The models take into consideration important features such as the spatial distribution of nodes, strategies for sharing the wireless medium, the attenuation of signals with distance, and how information is to be transferred, whether it be by encoding, decoding, choice of power level, spatio-temporal scheduling of transmissions, choice of multi-hop routes, or other modalities of cooperation between nodes. An important aspect of the approach is to characterize how the information hauling capacity scales with the number of nodes in the network. The monograph begins by studying models of wireless networks based on current technology, which schedules concurrent transmissions to take account of interference, and then routes packets from their sources to destinations in a multi-hop fashion.
An index of performance, called transport capacity, which is measured by the bit meters per second the network can convey in aggregate, is studied. For arbitrary networks, including those allowing for optimization of node locations, the scaling law for the transport capacity in terms of the number of nodes in the network is identified. For random networks, where nodes are randomly distributed, and source-destination pairs are randomly chosen, the scaling law for the maximum common throughput capacity
pairs are randomly chosen, the scaling law for the maximum common throughput capacity that can be supported for all the source-destination pairs is characterized.
CHAPTER-2 LITERATURE SURVEY
2.1 Transmission capacity:
The transmission capacity (TC) of a wireless ad hoc network is defined as the maximum spatial intensity of successful transmissions such that the outage probability does not exceed some specified threshold. This work studies the improvement in TC obtainable with successive interference cancellation (SIC), an important receiver technique that has been shown to achieve the capacity of several classes of multiuser channels, but has not been carefully evaluated in the context of ad hoc wireless networks. This paper develops closed-form upper bounds and easily computable lower bounds for the TC of ad hoc networks with SIC receivers, for both perfect and imperfect SIC. The analysis applies to any multiuser receiver that cancels the K strongest interfering signals by a factor z is in [0, 1]. In addition to providing the first closed-form capacity
results for SIC in ad hoc networks, design-relevant insights are made possible. In particular, it is shown that SIC should be used with direct sequence spread spectrum. Also, any imperfections in the interference cancellation rapidly degrade its usefulness. More encouragingly, only a few often just one - interfering nodes need to be canceled in order to get the vast majority of the available performance gain. 2.2 Transport capacity: Transport capacity defined as the supreme over the set of feasible rate vectors of the distance weighted sum of rates. We consider two assumption sets. Under the first assumption set, which essentially requires only a mild time average type of bound on the fading process, we show that the transport capacity can grow no faster , where denotes the number of nodes, even when the channel state information (CSI) is available non-causally at both the transmitters and the receivers. This assumption includes common models of stationary argotic channels; constant, frequency selective channels; flat, rapidly varying channels; and flat slowly varying channels. In the second assumption set, which essentially features an independence, time average of expectation, and nonzeroness condition on the fading process, we constructively show how to achieve transport capacity of even when the CSI is unknown to both the transmitters and the receivers, provided that every node has an appropriately nearby node. This assumption set includes common models of i.i.d. channels; constant, flat channels; and constant, frequency selective channels. The transport capacity is achieved by nodes only communicating with neighbors, and only using point-to-point coding. The thrust of these results is that the multi-hop strategy, towards which much protocol development activity is currently targeted, is appropriate for fading environments. 2.3 Network information theory:
Network information theory deals with the fundamental limits on information flow in networks and optimal coding techniques and protocols that achieve these limits. It extends Shannon's point-to-point information theory and the Ford-Fulkerson max-flow min-cut theorem to networks with multiple sources and destinations, broadcasting, interference, relaying, distributed compression and computing. Although a complete theory is yet to be developed, several beautiful results and techniques have been developed over the past forty years with potential applications in wireless communication, the Internet, and other networked systems. This set of lecture notes, which is a much expanded version of lecture notes used in graduate courses over the past eight years at Stanford, UCSD, CUHK, UC Berkeley, and EPFL, aims to provide a broad coverage of key results, techniques, and open problems in network information theory. The lectures are organized into four parts: background, single-hop networks, multi-hop networks, and extensions. The organization attempts to balance the introduction of new techniques and new models. Extensions (if any) to many users and large networks are discussed throughout. The lecture notes provide a unified, simplified, and formalized treatment of achievability using a few basic lemmas. The proofs in the lecture notes use elementary tools and techniques, which should make them accessible to graduate students in EE, CS, Statistics, and related fields as well as to researchers and practitioners in industry.
2.4 Stochastic geometry: The spatial structure observed in communication networks is usually far from being regular. The network geometry and its structural fluctuations are critical parameters that greatly influence the performance of random networks. Specifically, since the interference and the signal strength at a
receiver critically depends on the distribution of the interfering transmitters, mathematical techniques are needed to explicitly model the node distribution.As a consequence, stochastic geometry and random geometric graph theory have emerged as essential tools to model and quantify interference, connectivity, coverage, as well as outage probability and throughput in large wireless networks. These techniques including point process theory and percolation theory were instrumental in recent breakthroughs and have shed light to the fundamental limits of wireless networks. This page links to material that summarizes the main developments in stochastic geometry and random geometric graphs for the analysis and design of wireless networks. The new analytical tools from these fields and the key results and insights that were derived in the last decade are presented. Our hope is that this web page can serve to the community as a repository and resource for researchers and scientists in the field. 2.5 Adhoc Networks: A mobile ad hoc network (MANET), is a self-configuring infrastructureless network of mobile devices connected by wireless links. ad hoc is Latin and means "for this purpose". Each device in a MANET is free to move independently in any direction, and will therefore change its links to other devices frequently. Each must forward traffic unrelated to its own use, and therefore be a router. The primary challenge in building a MANET is equipping each device to continuously maintain the information required to properly route traffic. Such networks may operate by themselves or may be connected to the larger Internet. MANETs are a kind of wireless ad hoc networks that usually has a routeable networking environment on top of a Link Layer ad hoc network.
2.6 Conclusion of literature survey: This text presents one theory to address these questions. Starting with models which are salient to current technology and the current proposals to operate them in a multi-hop manner, we have shown how one can get insights by studying their behavior in terms of the number of nodes in the network. The performance measure of transport capacity measures the distance hauling capacity of wireless networks. We have provided sharp order estimates of the transport capacity in the best
case. For random networks, we have studied the common throughput capacity that can be supported for all the nodes. The constructive procedure for obtaining the sharp lower bound gives insight into an order optimal architecture for wireless networks operating under a multi-hop strategy. Such results, it is hoped, can enable one to understand the forest of wireless networks as well as the role of protocols and trees in it.
CHAPTER-3 SYSTEM ANALYSIS
3.1 Existing System:
Existing mesh based multicast routing. It defines the mean link duration metric to adapt and reduce refreshing control packets and also suggests a new reactive multicast mesh construction algorithm with overhearing Technique that forms a fish bone structure.
Each mesh member chooses its forwarding node independently and entirely in a distributed fashion, based on its own perceived network conditions to provide a tradeoff between reducing data overhead and achieving multicast reliability. The work given in proposes query packets containing source id, sequence number, next sequence number, hop count and the time interval needed to send next query packet. Query packet is sent by multiple sources and is processed by intermediate nodes and receivers.
3.2.Proposed System:
The tree management algorithm of HBH (Hop by Hop multicast routing protocol) uses three control messages to construct SPT. Messages are periodically sent to the source by the receivers. The source periodically produces messages that are multicast to the receivers. As the messages travels in the tree, the intermediate nodes may generate messages that are responsible of refining the tree structure.
In this project, we propose a link stability based multicast routing scheme that establishes a route from source to multicast destinations in MANET. A multicast mesh is created with stable links when a source node needs to send data to receiver nodes. The scheme consists of following phases.
1. A multicast channel in HBH is identified by , where is the unicast address of the source and
is a class-D IP address allocated by the source. This definition solves the address allocation problem while being compatible with SSMs channel definition. Therefore, HBH can support IP Multicast clouds as leaves of the distribution tree.
2. The tree structure of HBH has the advantage of an enhanced stability of the table entries when compared with REUNITE. The tree management scheme of HBH minimizes the impact of member departures in the tree structure.
3. There is no route changes for other members when a member leaves the group because the unicast routes are symmetric.
Merits
A multicast routing protocol that implements multicast distribution through recursive unicast trees. The main goals of HBH are: 1. To support unicast clouds, allowing incremental deployment,to have a stable tree structure, by minimizing the impact of receiver departures and to construct low-cost trees. 2. To reduce administrative costs. 3. To lower error rates. 4. To increase productivity.
3.3 Software Requirement Specifications
The user is expected to ensure that the minimum requirements for running the product are satisfied. The hardware and the software environment in which this product was developed are specified. It is necessary to make sure that the hardware and the software, the customer uses is compatible to the specification given below.
Hardware Requirements
PROCESSOR RAM MONITOR HARD DISK : : :
PENTIUM IV 2.6 GHz 512 MB DD RAM 15 COLOR 20 GB
Software Requirements
Front End Backend Tools Used
: Java, JFC (Swing) : MS-Access (Data Base) : Eclipse 3.3
Operating System : Windows XP/7
STUDY OF THE SYSTEM

In the flexibility of the uses the interface has been developed a graphics concept in mind, associated through a browses interface. The GUIS at the top level have been categorized as 1. Administrative user interface 2. The operational or generic user interface
The administrative user interface concentrates on the consistent information that is practically, part of the organizational activities and which needs proper authentication for the data collection. The interfaces help the administrations with all the transactional states like Data insertion, Data deletion and Date updating along with the extensive data search
capabilities.
The operational or generic user interface helps the users upon the system in transactions through the existing data and required services. The operational user interface also helps the ordinary users in managing their own information helps the ordinary users in managing their own information in a customized manner as per the assisted flexibilities. Functional Requirements prefer to very important system requirements in a software engineering process (or at micro level, a sub part of requirement engineering) such as technical specifications, system design parameters and guidelines, data manipulation, data processing and calculation modules etc. Functional Requirements are in contrast to other software design requirements referred to as Non-Functional Requirements which are primarily based on parameters of system performance, software quality attributes, reliability and security, cost, constraints in design/implementation etc. The key goal of determining functional requirements in a software product design and implementation is to capture the required behavior of a software system in terms of functionality and the technology implementation of the business processes. The Functional Requirements document (also called Functional Specifications or Functional Requirement Specifications), defines the capabilities and functions that a System must be able to perform successfully. Functional Requirements should include: Descriptions of data to be entered into the system Descriptions of operations performed by each screen Descriptions of work-flows performed by the system Descriptions of system reports or other outputs Who can enter the data into the system? How the system meets applicable regulatory requirements The functional specification is designed to be read by a general audience. Readers should understand the system, but no particular technical knowledge should be required to understand the document.
Non Functional Requirements All the other requirements which do not form a part of the above specification are categorized as Non-Functional Requirements. A system may be required to present the user with a display of the number of records in a database. This is a functional requirement. How up-to-date this number needs to be is a non-functional requirement. If the number needs to be updated in real time, the system architects must ensure that the system is capable of updating the displayed record count within an acceptably short interval of the number of records changing. Sufficient network bandwidth may also be a non-functional requirement of a system.
Other examples:
Accessibility Availability Backup Certification Compliance Configuration Management Documentation Disaster Recovery Efficiency (resource consumption for given load) Effectiveness (resulting performance in relation to effort) Extensibility (adding features, and carry-forward of customizations at next major version upgrade) Failure Management Interoperability Maintainability Modifiability Open Source Operability Performance Platform compatibility Price Portability Quality (e.g. Faults Discovered, Faults Delivered, Fault Removal Efficacy) Recoverability Resilience Resource constraints (processor speed, memory, disk space, network bandwidth etc. ) Response time Robustness Scalability (horizontal, vertical) Security Software, tools, standards etc. Stability Safety Supportability Testability Usability by target user community Accessibility is a general term used to describe the degree to which a product, device, service, or environment is accessible by as many people as possible. Accessibility can be viewed as the "ability to access" and possible benefit of some system or entity. Accessibility is often used to focus on people with disabilities and their right of access to the system. Availability is the degree to which a system, subsystem, or equipment is operable and in a committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random, time. Simply put, availability is the proportion of time a system is in a functioning condition.Expressed mathematically, availability is 1 minus the unavailability. A backup or the process of backing up refers to making copies of data so that these additional copies may be used to restore the original after a data loss event. These additional copies are typically called "backups." Certification refers to the confirmation of certain characteristics of an object, system, or organization. This confirmation is often, but not always, provided by some form of external review, education, or assessment Compliance is the act of adhering to, and demonstrating adherence to, a standard or regulation. Configuration management (CM) is a field that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.
Documentation may refer to the process of providing evidence ("to document something") or to the communicable material used to provide such documentation (i.e. a document). Documentation may also (seldom) refer to tools aiming at identifying documents or to the field of study devoted to the study of documents and bibliographie Disaster recovery is the process, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster. Disaster recovery planning is a subset of a larger process known as business continuity planning and should include planning for resumption of applications, data, hardware, communications (such as networking) and other IT infrastructure Extensibility (sometimes confused with forward compatibility) is a system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change while minimizing impact to existing system functions. Interoperability is a property referring to the ability of diverse systems and organizations to work together (inter-operate). The term is often used in a technical systems engineering sense, or alternatively in a broad sense, taking into account social, political, and organizational factors that impact system to system performance. Maintenance is the ease with which a software product can be modified in order to: correct defects meet new requirements make future maintenance easier, or cope with a changed environment; Open source describes practices in production and development that promote access to the end product's source materialstypically, their source code
Operability is the ability to keep equipment, a system or a whole industrial installation in a safe and reliable functioning condition, according to pre-defined operational requirements. In a computing systems environment with multiple systems this includes the ability of products, systems and business processes to work together to accomplish a common task. Computer performance is characterized by the amount of useful work accomplished by a computer system compared to the time and resources used. Depending on the context, good computer performance may involve one or more of the following: Short response time for a given piece of work High throughput (rate of processing work) Low utilization of computing resource(s) High availability of the computing system or application Fast (or highly compact) data compression and decompression High bandwidth / short data transmission time Price in economics and business is the result of an exchange and from that trade we assign a numerical monetary value to a good, service or asset Portability is one of the key concepts of high-level programming. Portability is the software-code base feature to be able to reuse the existing code instead of creating new code when moving software from an environment to another. When one is targeting several platforms with the same application, portability is the key issue for development
cost reduction. Quality: The common element of the business definitions is that the quality of a product or service refers to the perception of the degree to which the product or service meets the customer's expectations. Quality has no specific meaning unless related to a specific function and/or object. Quality is a perceptual, conditional and somewhat subjective attribute. Reliability may be defined in several ways: The idea that something is fit for purpose with respect to time; The capacity of a device or system to perform as designed; The resistance to failure of a device or system; The ability of a device or system to perform a required function under stated conditions for a specified period of time; The probability that a functional unit will perform its required function for a specified interval under stated conditions. The ability of something to "fail well" (fail without catastrophic consequences Resilience is the ability to provide and maintain an acceptable level of service in the face of faults and challenges to normal operation. These services include: supporting distributed processing supporting networked storage maintaining service of communication services such as video conferencing instant messaging online collaboration access to applications and data as needed Response time perceived by the end user is the interval between (a) The instant at which an operator at a terminal enters a request for a response from a computer and (b) The instant at which the first character of the response is received at a terminal. In a data system, the system response time is the interval between the receipt of the end of transmission of an inquiry message and the beginning of the transmission of a response message to the station originating the inquiry. Robustness is the quality of being able to withstand stresses, pressures, or changes in procedure or circumstance. A system or design may be said to be "robust" if it is capable of coping well with variations (sometimes unpredictable variations) in its operating environment with minimal damage, alteration or loss of functionality. The concept of scalability applies to technology and business settings. Regardless of the setting, the base concept is consistent - The ability for a business or technology to accept increased volume without impacting the system. In telecommunications and software engineering, scalability is a desirable property of a system, a network, or a process, which indicates its ability to either handle growing amounts of work in a graceful manner or to be readily enlarged. Security is the degree of protection against danger, loss, and criminals. Security has to be compared and contrasted with other related concepts: Safety, continuity, reliability. The key difference between security and reliability is that security must take into account the actions of people attempting to cause destruction. Security as a state or condition is resistance to harm. From an objective perspective, it is a structure's actual (conceptual and never fully knowable) degree of resistance to harm.
Stability - it means much of the objects will be stable over time and will not need changes.
Safety is the state of being "safe", the condition of being protected against physical, social, spiritual, financial, political, emotional, occupational, psychological, educational or other types or consequences of failure, damage, error, accidents, harm or any other event which could be considered non-desirable. This can take the form of being protected from the event or from exposure to something that causes health or economical losses. It can include protection of people or of possessions Supportability (also known as serviceability) is one of the aspects of RASU (Reliability, Availability, Serviceability, and Usability)). It refers to the ability of technical support personnel to install, configure, and monitor products, identify exceptions or faults, debug or isolate faults to root cause analysis, and provide hardware or software maintenance in pursuit of solving a problem and restoring the product into service. Incorporating serviceability facilitating features typically results in more efficient product maintenance and reduces operational costs and maintains business continuity. Testability, a property applying to an empirical hypothesis, involves two components: (1) the logical property that is variously described as contingency, defeasibility, or falsifiability, which means that counter examples to the hypothesis are logically possible, and (2) the practical feasibility of observing a reproducible series of such counter examples if they do exist. In short it refers to the capability of an equipment or system to be tested Usability is a term used to denote the ease with which people can employ a particular tool or other human-made object in order to achieve a particular goal. In human-computer interaction and computer science, usability often refers to the elegance and clarity with which the interaction with a computer program or a web site is designed.
FEASIBILITY REPORT 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 Operation Feasibility Economical Feasibility 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. 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. 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, there is nominal expenditure and economical feasibility for certain. 3.4 Language Specifications
Java Technology
Java technology is both a programming language and a platform.
The Java Programming Language The Java programming language is a high-level language that can be characterized by all of the following buzzwords:
Simple Architecture neutral Object oriented Portable Distributed
High performance Interpreted Multithreaded Robust Dynamic Secure
With most programming languages, you either compile or interpret a program so that you can run it on your computer. The Java programming language is unusual in that a program is both compiled and interpreted. With the compiler, first you translate a program into an intermediate language called Java byte code-the platform-independent codes interpreted by the interpreter on the Java platform. The interpreter parses and runs each Java byte code instruction on the computer. Compilation happens just once; interpretation occurs each time the program is executed. The following figure illustrates how this works.
You can think of Java byte codes as the machine code instructions for the Java Virtual Machine (Java VM). Every Java interpreter, whether its a development tool or a Web browser that can run applets, is an implementation of the Java VM. Java byte codes help make write once, run anywhere possible. You can compile your program into byte codes on any platform that has a Java compiler. The byte codes can then be run on any implementation of the Java VM. That means that as long as a computer has a Java VM, the same program written in the Java programming language can run on Windows 2000, a Solaris workstation, or on an iMac.
The Java Platform
A platform is the hardware or software environment in which a program runs.Weve already mentioned some of the most popular platforms like Windows 2000, Linux, Solaris, and MacOS. Most platforms can be described as a combination of the operating system and hardware. The Java platform differs from most other platforms in that its a software-only platform that runs on top of other hardware-based platforms. The Java platform has two components:
The Java Virtual Machine (Java VM) The Java Application Programming Interface (Java API) Youve already been introduced to the Java VM. Its the base for the Java platform and is ported onto various hardware-based platforms. The Java API is a large collection of ready-made software components that provide many useful capabilities, such as graphical user interface (GUI) widgets. The Java API is grouped into libraries of related classes and interfaces; these libraries are known as packages. The next section, What Can Java Technology Do? Highlights what functionality some of the packages in the Java API provide. The following figure depicts a program thats running on the Java platform. As the figure shows, the Java API and the virtual machine insulate the program from the hardware.
Native code is code that after you compile it, the compiled code runs on a specific hardware platform. As a platform-independent environment, the Java platform can be a bit slower than native code. However, smart compilers, well-tuned interpreters, and just-in-time byte code compilers can bring performance close to that of native code without threatening portability.
What Can Java Technology Do?

The most common types of programs written in the Java programming language are applets and applications. If youve surfed the Web, youre probably already familiar with applets. An applet is a program that adheres to certain conventions that allow it to run within a Java-enabled browser. However, the Java programming language is not just for writing cute, entertaining applets for the Web. The general-purpose, high-level Java programming language is also a powerful software platform. Using the generous API, you can write many types of programs. An application is a standalone program that runs directly on the Java platform. A special kind of application known as a server serves and supports clients on a network. Examples of servers are Web servers, proxy servers, mail servers, and print servers. Another specialized program is a servlet. A servlet can almost be thought of as an applet that runs on the server side. Java Servlets are a popular choice for building interactive web applications, replacing the use of CGI scripts. Servlets are similar to applets in that they are runtime extensions of applications. Instead of working in browsers, though, servlets run within Java Web servers, configuring or tailoring the server. How does the API support all these kinds of programs? It does so with packages of software components that provides a wide range of functionality. Every full implementation of the Java platform gives you the following features: The essentials: Objects, strings, threads, numbers, input and output, data structures, system properties, date and time, and so on. Applets: The set of conventions used by applets. Networking: URLs, TCP (Transmission Control Protocol), UDP (User Data gram Protocol) sockets, and IP (Internet Protocol) addresses. Internationalization: Help for writing programs that can be localized for users worldwide. Programs can automatically adapt to specific locales and be displayed in the appropriate language.
Security: Both low level and high level, including electronic signatures, public and private key management, access control, and certificates. Software components: Known as JavaBeansTM, can plug into existing component architectures. Object serialization: Allows lightweight persistence and communication via Remote Method Invocation (RMI). Java Database Connectivity (JDBC TM): Provides uniform access to a wide range of relational databases. The Java platform also has APIs for 2D and 3D graphics, accessibility, servers, collaboration, telephony, speech, animation, and more. The following figure depicts what is included in the Java 2 SDK.
3.5. Conclusion of the system analysis: In this project, we propose a link stability based multicast routing scheme that establishes a route from source to multicast destinations in MANET. A multicast mesh is created with stable links when a source node needs to send data to receiver nodes. And to support unicast clouds, allowing incremental deployment. To have a stable tree structure, by minimizing the impact of receiver departures and to construct low-cost trees.To reduce administrative costs,to lower error rates and to increase productivity.
CHAPTER-4 SYSTEM DESIGN
4.1 DESIGN OVERVIEW :-
Software design sits at the technical kernel of the software engineering process and is applied regardless of the development paradigm and area of application. Design is the first step in the development phase for any engineered product or system. The designers goal is to produce a model or representation of an entity that will later be built. Beginning, once system requirement have been specified and analyzed, system design is the first of the three technical activities -design, code and test that is required to build and verify software. The importance can be stated with a single word Quality. Design is the place where quality is fostered in software development. Design provides us with representations of software that can assess for quality. Design is the only way that we can accurately translate a customers view into a finished software product or system. Software design serves as a foundation for all the software engineering steps that follow. Without a strong design we risk building an unstable system one that will be difficult to test, one whose quality cannot be assessed until the last stage. During design, progressive refinement of data structure, program structure, and procedural details are developed reviewed and documented. System design can be viewed from either technical or project management perspective. From the technical point of view, design is comprised of four activities architectural design, data structure design, interface design and procedural design.
Level1
Figure1:Normal Transport Network Flow
Level 2
Figure2: Some Network Failure its using Alter path network
Data Flow Diagram: A data flow diagram is graphical tool used to describe and analyze movement of data through a system. These are the central tool and the basis from which the other components are developed. The transformation of data from input to output, through processed, may be described logically and independently of physical components associated with the system. These are known as the logical data flow diagrams. The physical data flow diagrams show the actual implements and movement of data between people, departments and workstations. A full description of a system actually consists of a set of data flow diagrams. Using two familiar notations Yourdon, Gane and Sarson notation develops the data flow diagrams. Each component in a DFD is labeled with a descriptive name. Process is further identified with a number that will be used for identification purpose. The development of DFDS is done in several levels. Each process in lower level diagrams can be broken down into a more detailed DFD in the next level. The lop-level diagram is often called context diagram. It consists a single process bit, which plays vital role in studying the current system. The process in the context level diagram is exploded into other process at the first level DFD. The idea behind the explosion of a process into more process is that understanding at one level of detail is exploded into greater detail at the next level. This is done until further explosion is necessary and an adequate amount of detail is described for analyst to understand the process. Larry Constantine first developed the DFD as a way of expressing system requirements in a graphical from, this lead to the modular design. The DFD is also called as bubble chart. It is a simple graphical formalism that can be used to represent a system in terms of the input data to the system, various processing carried out on these data, and the output data is generated by the system.
CONSTRUCTING A DFD: Several rules of thumb are used in drawing DFDS: 1. Process should be named and numbered for an easy reference. Each name should be representative of the process. 2. The direction of flow is from top to bottom and from left to right. Data traditionally flow from source to the destination although they may flow back to the source. One way to indicate this is to draw long flow line back to a source. An alternative way is to repeat the source symbol as a destination. Since it is used more than once in the DFD it is marked with a short diagonal. 3. When a process is exploded into lower level details, they are numbered. 4. The names of data stores and destinations are written in capital letters. Process and dataflow names have the first letter of each work capitalized. A DFD typically shows the minimum contents of data store. Each data store should contain all the data elements that flow in and out.Questionnaires should contain all the data elements that flow in and out. Missing interfaces redundancies and like is then accounted for often through interviews. SAILENT FEATURES OF DFDS 1. The DFD shows flow of data, not of control loops and decision are controlled considerations do not appear on a DFD. 2. The DFD does not indicate the time factor involved in any process whether the dataflow take place daily, weekly, monthly or yearly. 3. The sequence of events is not brought out on the DFD. TYPES OF DATA FLOW DIAGRAMS Current Physical Current Logical New Logical New Physical
Data Flow Diagram:
Figure 3: DFD for sending information from Server mobile to Client mobile.
4.2 Rapid Application Development (RAD) Model
Rapid application development is a software development methodology that involves methods like iterative development and software prototyping. According to Whitten (2004), it is a merger of various structured techniques, especially data-driven Information Engineering, with prototyping techniques to accelerate software systems development. In rapid application development, structured techniques and prototyping are especially
used to define users' requirements and to design the final system. The development process starts with the development of preliminary data models and business process models using structured techniques. In the next stage, requirements are verified using prototyping, eventually to refine the data and process models. These stages are repeated iteratively; further development results in "a combined business requirements and technical design statement to be used for constructing new systems". RAD approaches may entail compromises in functionality and performance in exchange for enabling faster development and facilitating application maintenance http://upload.wikimedia.org/wikipedia/commons/5/5f/RADModel.JPG
Fig 4: Rapid Application Development (RAD ) Model
4.3.UML Design Overview: Introduction to uml : unified modeling language ,uml for short,is the international standard notation for object-oriented analysis and design (ooad).It is a standardized specialization language that can be used for object modeling. Goals of uml: The uml was invented primarily to address the challenges faced in the design and architectures of complex systems.The basic objectives or goals behind uml modeling are:define an easy to use and visual modeling language for modeling a systems structure. Types of Diagrams: Use-case diagrams : They depict the interactions between the system and external systems and users.In other words they graphically describe who will use the system and in what ways the user expects to interact with the system. Class diagrams : They depict the systems object structure.they show object classes what the system is composed of as well as the relationships between those object classes. Object diagrams : Model actual object instances Sequence diagrams : They depict how objects interact with each other via messages in the execution a use case or an operation .They illustrate how messages are sent and received between objects and in what sequence.
Collaboration diagrams : They are similar to sequence diagrams but do not focus on the timing or sequence of messages .Instead ,they present the interaction between objects in a network format. State chart diagrams : They model the dynamic behavior of a particular object,illustrating an objects life cycle. Activity diagrams : Depict the sequential flow of activities.
4.3. Diagrams: Class Diagram:
Figure 4: Class Diagram of nodes for performing action
Sequence Diagram:
Figure 5: Sequence Diagram for sending packets from mobile server to mobile client
State chart Diagram:
Figure 6 : State chart Diagram for sending packets from sender to destination
Activity Diagram:
Figure 7: Activity Diagram for sending packets from mobile server to mobile client
Collaboration Diagram:
Figure 8: Collaboration Diagram for Network formation
Component Diagram:
Figure 9: Component Diagram for Network Formation
CoCcc
4.4. Conclusion of the System Design: The idea behind the explosion of a process into more process is that understanding at one level of detail is exploded into greater detail at the next level. This is done until further explosion is necessary and an adequate amount of detail is described for analyst to understand the process. The designing was primarily to address the challenges faced in the design and architectures of complex systems. The basic objective behind modeling are: Define an easy to use and visual modeling language for modeling a systems structure.
CHAPTER-5 SYSTEM IMPLEMENTATION
Implementation is the stage of the project when the theoretical design is turned out into a working system. Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the user, confidence that the new system will work and be effective. The implementation stage involves careful planning, investigation of the existing system and its constraints on implementation, designing of methods to achieve changeover and evaluation of changeover methods.
5.1. Modules in the project: 1. Single Hop, Single Transmission Module 2. Multiple Hops, Multiple Transmissions per Hop Module 3. Random access transport capacity Module 4. End-to-End Guaranteed Delivery Module
1. Single Hop, Single Transmission
In this project we develop a new, quite general model for end-to-end throughput in a multi hop wireless network. We term the resulting metric random access transport capacity since the analysis requires all transmissions to be independent, which precludes cooperative transmission scheduling among the nodes, since this would generally couple transmissions and the active transmitter locations would no longer be independent. However, that the model does not preclude cooperative or multi packet reception, although we do not consider such approaches in this paper. The general model includes arbitrary paths of hops and an end-to-end delay.
2. Multiple Hops, Multiple Transmissions per Hop Module The random access transport capacity for a multi hop wireless network is the maximum average source to destination rate that can be sustained reliably over a distance with at most transmission attempts per packet, normalized by the area of the network. Formally, this paper is to move beyond the single-hop, single-transmission model to a network that allows multiple hops and multiple transmissions per hop, while retaining some of the tractability of the transmission capacity model. 3. Random access transport capacity Module:
That Module, only nodes that compose network detect other nodes of network and Form network without alternative system management. Such as existing network, alternative base station, wire, cable, router and bridge are possible to compose network without infrastructure for composing network, see Fig below.
Node S checks the table that there is any information of node D, which cant communicate with infrastructure. If it doesnt have information about node D, node S sends RREQ messages, with sequence number to countermeasure loops, to the neighboring nodes via broadcast and starts path discovery process. RREQ messages are sent throughout the network within the predefined time period until it reaches to the destination node D,
In emergency situation, a node that cant communicate with infrastructure turns on Ad hoc mode and communicate with a node who can communicate with infrastructure. However suppose one of the node in the path moves and path is broken. Then a surrounding node which is the nearest to the node S broadcasts RREQ_rp message to recover path. Using reserve part in the message, it notices to receive nodes that it is for path. See fig given below... Recovery
Figure 5: Recovery of the disaster situation
4. End-to-End Guaranteed Delivery Module:
Each transmission per hop to have independent success probability requires sufficient diversity in the interference and signal strength per transmission attempt, which could possibly be achieved through diversity techniques such as frequency hopping.
It follows the square-root scaling law for source-destination transmissions in large wireless networks. That is, unscheduled, channel-blind transmissions can achieve given wellpositioned relays a transport capacity that scales the same as optimally scheduled nearest neighbour routing.
5.2. ARCHITECTURE AND ITS DESCRIPTION
The two-tier application programming model was developed to enhance the file server application programming model. As compared with the file server application programming model, the two-tier application programming model provides you with improved usability, scalability, and flexibility of applications. In Two-Tier model, you will have two separate layers namely Client & Server. can-support-only-a-few-users.JPG
The applications developed using the two-tier application programming model have a user-friendly interface. These applications can support only a few users and allow data to be shared within a homogeneous environment.
Example of the Model

two-tier-application-model-example.JPG
The various tiers in a two-tier architecture are separated from each other by physical boundaries. These physical boundaries can be machine boundaries, process boundaries, or corporate boundaries.
Characteristics 1
char-1.JPG
Two-tier application programming model is a combination of a client application and a server application. In this application programming model, the client application directly interacts with the server application without the presence of any intermediate application.
Characteristics 2
The Client application communicates with the data layer through a database bridge A pplication Programming Interface (API). An Example of a database bridge API is JDBC commonly known as Java Database Connectivity. Database Connectivity. two-tier-char-3.jpg
Characteristics 3
two-tier-char-7.jpg
High network traffic because of an increase in the number of trips of data transfer across the physical boundaries of the network. Each time a database operation is performed, the data is transmitted across the physical boundary that separates the business logic and data layers
Usage:
two-tier-usage.jpg
Suitable for environments where business rules do not change frequently and the number of users are limited. For E.g.: This model can be used to run the localized accounting application of a company.
5.3. IMPLEMENTATION:
import java.awt.*; import java.applet.*; import java.awt.event.*; import javax.swing.*; import java.net.*; import java.io.*;
//<applet code="app1" height=800 width=800> </applet>
public class app1 extends Applet implements ActionListener,ItemListener { Button but1,but2,but3; CheckboxGroup cg1,cg2,cg3,cg4,cg5,cg6,cg7,cg8,cg9; Checkbox ch1,ch2,ch3,ch4,ch5,ch6,ch7,ch8,ch9,ch10,ch11,ch12,ch13,ch14,ch15,ch16,ch17,ch18; String msg; String message[]=new String[9];
Label l1,l2,l3,l4,l5,l6,l7,l8,l9; Font f=new Font("SansSerif",Font.BOLD, 30); public static Socket cs[]=new Socket[9]; public static PrintWriter pw;
public void init() { setBackground(new Color(223,122,200)); setSize(800,600); setLayout(null); repaint(); l1=new Label("Tower1 Details:"); l1.setBounds(0,100,90,20);
add(l1); cg1=new CheckboxGroup(); ch1=new Checkbox("FAULT",false,cg1);
ch2=new Checkbox("NO FAULT",true,cg1); ch1.setBounds(0,120,82,20); ch2.setBounds(0,140,82,20); add(ch1); add(ch2); ch1.addItemListener(this); ch2.addItemListener(this); //************************************************ l2=new Label("Tower2 Details:"); l2.setBounds(110,100,90,20); add(l2);
cg2=new CheckboxGroup();
ch3=new
Checkbox("FAULT",false,cg2);
ch4=new Checkbox("NO FAULT",true,cg2);
ch3.setBounds(110,120,82,20); ch4.setBounds(110,140,82,20);
add(ch3); add(ch4);
ch3.addItemListener(this); ch4.addItemListener(this); //**************************************************** l3=new Label("Tower3 Details:"); l3.setBounds(210,100,90,20);
add(l3);
ch5=new
add(ch5); add(ch6);
ch5.addItemListener(this); ch6.addItemListener(this);
//**************************************************** l4=new Label("Tower4 Details:"); l4.setBounds(310,100,90,20);
add(l4);
ch7=new
add(ch7); add(ch8);
add(l5);
ch9=new
add(ch9); add(ch10);
ch9.addItemListener(this);
ch10.addItemListener(this); //**************************************************** l6=new Label("Tower6 Details:"); l6.setBounds(510,100,90,20);
add(l6);
ch11=new Checkbox("FAULT",false,cg6); ch12=new Checkbox("NO FAULT",true,cg6);
add(l7);
add(l8);
add(l9);
ch17.addItemListener(this); ch18.addItemListener(this); //************************************************ but1=new Button("SEND"); but1.setBounds(300,400,50,50);
add(but1); but1.addActionListener(this); //************************************************ but2=new Button("DETAILS"); but2.setBounds(100,400,60,50); but2.setVisible(false); add(but2); but2.addActionListener(this); //************************************************ /* but3=new Button("PATH "); but3.setBounds(500,400,50,50); but3.setVisible(false); add(but3); but3.addActionListener(this); } */
public app1() {
try { ServerSocket ss=new ServerSocket(4545); System.out.println("Server is listening....."); int i=0; while(i<9) { cs[i]=ss.accept(); System.out.println("Server is connected to :"+cs[i]); message[i]="n"; i++; } } catch(Exception ee) { System.out.println("error in:"+ee); } }
public void paint(Graphics g) { String mss="Random Access Transport Capacity(Tower Details)"; setForeground(Color.blue); g.setFont(f); g.drawString(mss,15,35); }
public void actionPerformed(ActionEvent e) { if(e.getSource()==but1) { try {
int i=0; while(i<9) { pw=new PrintWriter(cs[i].getOutputStream(),true); pw.println(message[i]); i++; } showStatus("SIGNAL IS SENDED SUCESSFULLY"); but2.setVisible(true); //but3.setVisible(true); } catch(Exception er) { System.out.println("error at :"+er); } } if(e.getSource()==but2) { new NBTowers(message);
} /* if(e.getSource()==but3) { new PathFound(message); } */ }
public void itemStateChanged(ItemEvent i) { if(i.getItemSelectable()==ch1) { message[0]="Y";
showStatus("selected fault"+message); }
if(i.getItemSelectable()==ch2) { message[0]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch3) { message[1]="Y"; showStatus("selected fault"+message); }
if(i.getItemSelectable()==ch6) { message[2]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch7) { message[3]="Y";
if(i.getItemSelectable()==ch12) { message[5]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch13) { message[6]="Y";
if(i.getItemSelectable()==ch14) { message[6]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch15)
{ message[7]="Y"; showStatus("selected fault"+message); }
if(i.getItemSelectable()==ch18) { message[8]="N"; showStatus("selected No fault"+message); } }}
import javax.microedition.midlet.*; import javax.microedition.lcdui.*; import javax.microedition.io.*; import java.io.*; import java.util.*;
public class client extends MIDlet { static protected Display display; protected Displayable displayable;
Form form1; Ticker tick1;
GetMessage gm;
public client() { display = Display.getDisplay(this);
form1=new Form("You are Connected"); tick1=new Ticker("Welcome to Dotcom's NetCity.."); gm=new GetMessage(); }
public void startApp() { try { display.setCurrent(form1); form1.setTicker(tick1); gm.start();
} catch(Exception ex) { System.out.println("Exeption in start"+ex); } }
public void pauseApp(){}
public void destroyApp(boolean unconditional) { display = null; displayable = null; } }
class GetMessage extends Thread { StreamConnection stream1; PrintStream out1; InputStream in1;
public void run() { try { stream1=(StreamConnection) Connector.open("socket://localhost:4500"); out1 = new PrintStream(stream1.openOutputStream()); in1 = stream1.openInputStream(); System.out.println("Connected"); } catch(Exception ex)
{ System.out.println("In Thread:"+ex); }
while(true) { try { byte b[]=new byte[100]; System.out.println("Iam waiting...");
int w=in1.read(b); System.out.println("length="+w);
String type1=new String(b,0,w);
String from=type1.trim();
Alert currentAlert = new Alert("Message For You"); currentAlert.setTimeout(5000); currentAlert.setString("Message:"+from+"\n"); currentAlert.setType(AlertType.INFO); client.display.setCurrent(currentAlert);
System.out.println("Message:"+from); } catch(Exception ex) { } } }}
HELP NOTES --------------------------------------------------------1.compile all the given programs by typing compile.bat file in dos prompt. 2.Run the app1.java applet file by appletviewer app1.java 3.Then a white screen will be appeared, minimize it. 4.Run the Sink.java,then Tower1.java Tower2,3,4,5,6,7,8, upto Tower9.java 5.Run the Source.java program 6.Build the server and client j2me programs 7.Run the server and client. 8.Then maximize the appletwindow,then make the towers on and off its yours wish 9.Then click the send button ,to send the information to all towers 10.Then send the message in mobile the client will receive the message. NOTE: Tower Details
1. Sink can reach only to towers 1,2 and 3.
2.tower1 can reach only sink and tower4.
3.tower2 can reach only sink and towers 4,5 and 6.
4.tower3 can reach only sink and tower 6.
5.tower4 can reach only tower 1,2 and 7.
6.tower5 can reach only tower 2,8 and Source.
7.tower6 can reach only tower 2,3 and 8.
8.tower7 can reach only tower 4 and Source.
9.tower8 can reach only tower 5,6 and source.
10.tower9 can reach only tower 8 and Source.
11. Source can reach only tower 7,5,9.
PATH FOUND: ************
1.server------>Sink--->t2--->t5--->source------>client.
// primary path.
2.ser--->Sink--->t2--->t4--->t7--->source---->client. //if tower 5 is fault.
3.sink--->t2--->t6--->t8--->t9--->source.// if tower5 and 4 is fault.
4.sink--->t1--->t4--->t7--->source.
//if t2 is fault.
5.sink--->t3--->t6--->t8--->t9--->source. //if t2 and t1 is fault.
6.sink--->t3--->t6--->t8--->t5--->source. //if t2 ,t1 and t9 is fault .
7.if t1,t2,t3 will get fault then no transmission occurs.
5.4. Conclusion of the System Implementation:
Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the user, confidence that the new system will work and be effective. Atlast this implementation stage involves careful planning, investigation of the existing system and its constraints on implementation, designing of methods to achieve changeover and evaluation of changeover methods.
CHAPTER-6 INTEGRATION AND TESTING
Software testing is a critical element of software quality assurance and represents the ultimate review of specification, design and coding. In fact, testing is the one step in the software engineering process that could be viewed as destructive rather than constructive. A strategy for software testing integrates software test case design methods into a wellplanned series of steps that result in the successful construction of software. Testing is the set of activities that can be planned in advance and conducted systematically. The underlying motivation of program testing is to affirm software quality with methods that can economically and effectively apply to both strategic to both large and small-scale systems. 6.1 TESTING:
Figure 10: Testing progress TYPES OF TESTS
Unit testing Unit testing involves the design of test cases that validate that the internal program logic is functioning properly, and that program inputs produce valid outputs. All decision branches and internal code flow should be validated. It is the testing of individual software units of the application .it is done after the completion of an individual unit before integration. This is a structural testing, that relies on knowledge of its construction and is invasive. Unit tests perform basic tests at component level and test a specific business process, application, and/or system configuration. Unit tests ensure that each unique path of a business process performs accurately to the documented specifications and contains clearly defined inputs and expected results.
Integration testing
Integration tests are designed to test integrated software components to determine if they actually run as one program. Testing is event driven and is more concerned with the basic outcome of screens or fields. Integration tests demonstrate that although the components were individually satisfaction, as shown by successfully unit testing, the combination of components is correct and consistent. Integration testing is specifically aimed at exposing the problems that arise from the combination of components.
Functional test
Functional tests provide systematic demonstrations that functions tested are available as specified by the business and technical requirements, system documentation, and user manuals. Functional testing is centered on the following items: Valid Input Invalid Input Functions Output : identified classes of valid input must be accepted. : identified classes of invalid input must be rejected. : identified functions must be exercised. : identified classes of application outputs must be exercised.
Systems/Procedures: interfacing systems or procedures must be invoked.
Organization and preparation of functional tests is focused on requirements, key functions, or special test cases. In addition, systematic coverage pertaining to identify Business process flows; data fields, predefined processes, and successive processes must be considered for testing. Before functional testing is complete, additional tests are identified and the effective value of current tests is determined.
System Test System testing ensures that the entire integrated software system meets requirements. It tests a configuration to ensure known and predictable results. An example of system testing is the configuration oriented system integration test. System testing is based on process descriptions and flows, emphasizing pre-driven process links and integration points.
White Box Testing White Box Testing is a testing in which in which the software tester has knowledge of the inner workings, structure and language of the software, or at least its purpose. It is purpose. It is used to test areas that cannot be reached from a black box level.
Black Box Testing Black Box Testing is testing the software without any knowledge of the inner workings, structure or language of the module being tested. Black box tests, as most other kinds of tests, must be written from a definitive source document, such as specification or requirements document, such as specification or requirements document. It is a testing in which the software under test is treated, as a black box .you cannot see into it. The test provides inputs and responds to outputs without considering how the software works.
Test strategy and approach Field testing will be performed manually and functional tests will be written in detail.
Test objectives All field entries must work properly. Pages must be activated from the identified link. The entry screen, messages and responses must not be delayed.
Features to be tested Verify that the entries are of the correct format No duplicate entries should be allowed All links should take the user to the correct page
Integration Testing
Software integration testing is the incremental integration testing of two or more integrated software components on a single platform to produce failures caused by interface defects. The task of the integration test is to check that components or software applications, e.g. components in a software system or one step up software applications at the company level interact without error.
Test Results: All the test cases mentioned passed successfully. No defects encountered.
Acceptance Testing User Acceptance Testing is a critical phase of any project and requires significant participation by the end user. It also ensures that the system meets the functional requirements.
Test Results: All the test cases mentioned passed successfully. No defects encountered.
Test Cases:
Case # Test Case Method Message in Alpha numeric Special Character 3 Message Message save to 4 outbox 5Envoke Fault Towers 2
Bug ClosedStatus Yes Yes Yes Yes Yes Yes Yes
1Message in Character No No No No No
Summary Sent Successful Successfully Sent Successful Successfully Sent Successful Successfully SuccessfulSaved SuccessfulInvoked SuccessfulRevoked SuccessfulTested
6Revoke Fault Towers No Random Tower 7 No Testing
Table1: Total no.of Testcase methods involved.
CaseTest Case # Method
Description
Bug ClosedStatus Yes
Summary
Messsage in 1 Press start button No Character Type Message:"Hello" Press send button
Message Successful Sent Successfully
Table2: Enter message in characters
Case Test Case # Method 2
Description
Bug ClosedStatus No Yes
Summary
Messsage in Press start button Alphanumeric Type Message:"Hello 123" Press send button
Message Successful Sent Successfully
Table3: Enter Message in Alphanumeric.
Case Test Case # Method Message in 3Special Characters
Description Press Start button Type Message:"H#ll$" Press send button
Bug ClosedStatus No Yes
Summary
Message SuccessfulSent Successfully
Table 4: Enter message in Special characters.
Case Test Case Description # Method Message sent to After typing 4 Outbox messages press ok then message is saved
Bug ClosedStatus No Yes Successful
Summary Message Saved
Table5 : Messages sent to outbox
Case Test Case # Method Envoke Fault 5 Towers
Description
Summary
Successfully can No envoke the fault towers by pressing "fault" so that tower gets "off"
SuccessfulEnvoked
Table6 : Envoke fault Towers.
Case Test Case # Method Revoke Fault 6 Towers
Description
Summary
Successfully can No revoke the fault towers by pressing "no fault " so that tower gets "on".
SuccessfulRevoked
Table7 : Revoke fault Towers.
CaseTest Case Description Bug ClosedStatus Summary # Method Random Randomly Can 7 No Yes SuccessfulTested Testing Tower "Off" the towers and "on"the towers ,so that"fault" towers doesnt receives messages and"no fault" towers receives messages .
Table 8: Random Testing Towers.
6.2.Validation of Results:
Figure 11: Node Details when all are On state.
Figure 12: Some nodes are in on state and other in off state.
Figure 13: Packet Switching Network Details.
Figure 14 : Nodes/Towers Status.
Figure 15:Client Mobile.
Figure 16: Server mobile.
Figure 17 : Message sent from server.
Figure 18 : Message Received By Client
6.3. Conclusion of the Testing: A software project will complete after it is tested with the test cases and proves that it is working in all the scenarios. The testing phase of the project will play an important role in the software project development. All the modules are tested and exceptions are handled and the system is error free. Software testing integrates software test case design methods into a well-planned series of steps that result in the successful construction of software.
into a well-planned series of steps that result in the successful construction of software. Testing is the set of activities that can be planned in advance and conducted systematically. The underlying motivation of program testing is to affirm software quality with methods that can economically and effectively apply to both strategic to both large and small-scale systems.
CHAPTER-7 CONCLUSION AND FURURE WORK
7.1 Conclusion:
This project introduced a metric called the random access transport capacity, which is similar in spirit to the well known transport capacity metric but made more tractable (and admittedly, less general) with three admittedly strong assumptions:
(i) Uncoordinated transmissions, allowing a Poisson interference model, (ii) Equally spaced relays on a line between the source and destination, which allows identical statistics for each hop, and (iii) An iid interference and signal sample for each retransmission, which allows a geometric distribution to model the number of transmissions required per hop. The primary benefit of these assumptions is that they allow a closed-form and reasonably tight upper bound to be derived for the end-to-end throughput in terms of the key network parameters, which is notoriously difficult to accomplish in a general model.
7.2 Future work:
The project has covered almost all the requirements. Further requirements and improvements can easily be done since the coding is mainly structured or modular in nature. Improvements can be appended by changing the existing modules or adding new modules. Alternatively, the approach in this project can be viewed as a nontrivial extension of the more recent transmission capacity line of work all of which is single hop, single transmission, and not end-to-end to a multi hop, end-to-end setting where retransmissions are allowed.
BIBLIOGRAPHY
References :
1) P. Gupta and P. Kumar, The capacity of wireless networks," IEEE Trans. Inf. Theory, vol. 46, no. 2, pp. 388-404, Mar. 2000.
2) M. Grossglauser and D. Tse, Mobility increases the capacity of ad-hoc wireless networks," IEEE/ACM Trans. Networking, vol. 10, no. 4, pp. 477-86, Aug. 2002.
3) R. Negi and A. Rajeswaran, Capacity of power constrained ad-hoc networks," in Proc. IEEE INFOCOM, vol. 1, Mar. 2004, pp. 443-53.
4) A. Ozgur, O. Leveque, and D. Tse, Hierarchical cooperation achieves optimal capacity scaling in ad hoc networks," IEEE Trans. Inf. Theory, vol. 53, no. 10, pp. 3549-72, Oct. 2007.
5) F. Xue and P. R. Kumar, Scaling laws for ad hoc wireless networks: an information theoretic approach," Foundations Trends Netw., vol. 1,no. 2, pp. 145-270, 2006.
6) S. Toumpis and A. J. Goldsmith, Large wireless networks under fading, mobility, and delay constraints," in Proc. IEEE INFOCOM, Hong Kong, Mar. 2004.
7) O. Leveque and I. E. Teletar, Information-theoretic upper bounds on the capacity of large extended ad hoc wireless networks," IEEE Trans. Inf. Theory, pp. 858-65, Mar. 2005.
8) M. Franceschetti, M. Migliore, and P. Minero, The capacity of wireless networks: information-theoretic and physical limits," IEEE Trans. Inf. Theory, vol. 55, no. 8, pp. 3413-24, Aug. 2009.
9) U. Niesen, P. Gupta, and D. Shah, On capacity scaling of arbitrary wireless networks," IEEE Trans. Inf. Theory, vol. 55, no. 9, pp. 3959-3982, Sep. 2009.
10) L. Xie and P. R. Kumar, A network information theory for wireless communication: scaling laws and optimal operation," IEEE Trans. Inf. Theory, pp. 748-67, May 2004.
11) F. Xue, L. Xie, and P. R. Kumar, The transport capacity of wireless networks over fading channels," IEEE Trans. Inf. Theory, pp. 834-47, Mar. 2005.
12) G. Mergen and L. Tong, Stability and capacity of regular wireless networks," IEEE Trans. Inf. Theory, vol. 51, no. 6, pp. 1938-53, June 2005.
13) S. Weber, X. Yang, J. G. Andrews, and G. de Veciana, Transmission capacity of wireless ad hoc networks with outage constraints," IEEE Trans. Inf. Theory, vol. 51, no. 12, pp. 4091-4102, Dec. 2005.
14) S. Weber, J. G. Andrews, and N. Jindal, The effect of fading, channel inversion, and threshold scheduling on ad hoc networks," IEEE Trans. Inf. Theory, vol. 53, no. 11, pp. 4127-49, Nov. 2007.
15) A tutorial on transmission capacity," IEEE. Trans. Commun., submitted. [Online]. Available: arxiv.org/abs/0809.0016.
Sites Referred: http://java.sun.com http://www.sourcefordgde.com http://www.networkcomputing.com/ http://www.roseindia.com/ http://www.java2s.com/
TEXT BOOKS: a. D. Stoyan, W. Kendall, and J. Mecke, Stochastic Geometry and Its Applications, 2nd Edition, 2nd ed. John Wiley and Sons, 1996.
b. S. Weber, J. G. Andrews, and N. Jindal, The effect of fading, channel inversion, and threshold scheduling on ad hoc networks,
c. R. K. Ganti and M. Haenggi, Spatial and temporal correlation of the interference in aloha ad hoc networks
d. F. Baccelli, B. Blaszczyszyn, and P. Muhlethaler, An Aloha protocol for multihop mobile wireless networks
e. H. Inaltekin, M. Chiang, H. V. Poor, and S. Wicker, The behavior of unbounded path-loss models and the effect of singularity on computed network characteristics,
f. M. Haenggi and D. Puccinelli, Routing in ad hoc networks: a case for long hops,
g. M. Sikora, J. N. Laneman, M. Haenggi, D. J. Costello, and T. Fuja, Bandwidth- and powerefficient routing in linear wireless networks,
h. Ghasemi and E. Sousa, Interference aggregation in spectrum-sensing cognitive wireless networks, C. Yin, L. Gao, and S. Cui, Scaling laws for overlaid wireless networks: A cognitive radio network vs. a primary network,
Abbreviations:
PPP MANET CSI MAC HB H
- Poisson Point Process - Mobile ad Hoc Networks - Channel State Information - Medium access Control - Hop By Hop multicast routing protocol

Mini Project

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Mini Project

Încărcat de

Drepturi de autor:

Formate disponibile

Abstract

CHAPTER-2 LITERATURE SURVEY

2.1 Transmission capacity:

CHAPTER-3 SYSTEM ANALYSIS

3.1 Existing System:

3.3 Software Requirement Specifications

PROCESSOR RAM MONITOR HARD DISK : : :

PENTIUM IV 2.6 GHz 512 MB DD RAM 15 COLOR 20 GB

Front End Backend Tools Used

: Java, JFC (Swing) : MS-Access (Data Base) : Eclipse 3.3

Operating System : Windows XP/7

STUDY OF THE SYSTEM

Simple Architecture neutral Object oriented Portable Distributed

High performance Interpreted Multithreaded Robust Dynamic Secure

The Java Platform

What Can Java Technology Do?

CHAPTER-4 SYSTEM DESIGN

4.1 DESIGN OVERVIEW :-

Figure1:Normal Transport Network Flow

Figure2: Some Network Failure its using Alter path network

Data Flow Diagram:

4.2 Rapid Application Development (RAD) Model

Fig 4: Rapid Application Development (RAD ) Model

4.3. Diagrams: Class Diagram:

Figure 4: Class Diagram of nodes for performing action

State chart Diagram:

Figure 8: Collaboration Diagram for Network formation

Figure 9: Component Diagram for Network Formation

CHAPTER-5 SYSTEM IMPLEMENTATION

1. Single Hop, Single Transmission

Figure 5: Recovery of the disaster situation

4. End-to-End Guaranteed Delivery Module:

5.2. ARCHITECTURE AND ITS DESCRIPTION

Example of the Model

//<applet code="app1" height=800 width=800> </applet>

add(l1); cg1=new CheckboxGroup(); ch1=new Checkbox("FAULT",false,cg1);

ch4=new Checkbox("NO FAULT",true,cg2);

ch3.addItemListener(this); ch4.addItemListener(this); //**************************************************** l3=new Label("Tower3 Details:"); l3.setBounds(210,100,90,20);

ch6=new Checkbox("NO FAULT",true,cg3);

//**************************************************** l4=new Label("Tower4 Details:"); l4.setBounds(310,100,90,20);

ch8=new Checkbox("NO FAULT",true,cg4);

ch7.addItemListener(this); ch8.addItemListener(this); //**************************************************** l5=new Label("Tower5 Details:"); l5.setBounds(410,100,90,20);

ch10=new Checkbox("NO FAULT",true,cg5);

ch10.addItemListener(this); //**************************************************** l6=new Label("Tower6 Details:"); l6.setBounds(510,100,90,20);

ch11=new Checkbox("FAULT",false,cg6); ch12=new Checkbox("NO FAULT",true,cg6);

ch11.addItemListener(this); ch12.addItemListener(this); //**************************************************** l7=new Label("Tower7 Details:"); l7.setBounds(610,100,90,20);

ch13=new Checkbox("FAULT",false,cg7); ch14=new Checkbox("NO FAULT",true,cg7);

ch13.addItemListener(this); ch14.addItemListener(this); //**************************************************** l8=new Label("Tower8 Details:"); l8.setBounds(710,100,90,20);

ch15=new Checkbox("FAULT",false,cg8); ch16=new Checkbox("NO FAULT",true,cg8);

ch15.addItemListener(this); ch16.addItemListener(this); //**************************************************** l9=new Label("Tower9 Details:"); l9.setBounds(0,200,90,20);

ch17=new Checkbox("FAULT",false,cg9); ch18=new Checkbox("NO FAULT",true,cg9);

ch17.addItemListener(this); ch18.addItemListener(this); //************************************************ but1=new Button("SEND"); but1.setBounds(300,400,50,50);

public void actionPerformed(ActionEvent e) { if(e.getSource()==but1) { try {

} /* if(e.getSource()==but3) { new PathFound(message); } */ }

public void itemStateChanged(ItemEvent i) { if(i.getItemSelectable()==ch1) { message[0]="Y";

if(i.getItemSelectable()==ch2) { message[0]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch3) { message[1]="Y"; showStatus("selected fault"+message); }

if(i.getItemSelectable()==ch4) { message[1]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch5) { message[2]="Y"; showStatus("selected fault"+message); }

if(i.getItemSelectable()==ch6) { message[2]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch7) { message[3]="Y";

if(i.getItemSelectable()==ch8) { message[3]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch9) { message[4]="Y"; showStatus("selected fault"+message); }

if(i.getItemSelectable()==ch10) { message[4]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch11) { message[5]="Y"; showStatus("selected fault"+message); }

if(i.getItemSelectable()==ch12) { message[5]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch13) { message[6]="Y";

if(i.getItemSelectable()==ch14) { message[6]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch15)

{ message[7]="Y"; showStatus("selected fault"+message); }

if(i.getItemSelectable()==ch16) { message[7]="N"; showStatus("selected No fault"+message); } if(i.getItemSelectable()==ch17) { message[8]="Y"; showStatus("selected fault"+message); }