• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Cloud data management
 

Cloud data management

on

  • 497 views

 

Statistics

Views

Total Views
497
Views on SlideShare
497
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Cloud data management Cloud data management Document Transcript

    • Abstract:A significant challenge in cloud data management is ensuring that all query processing iscarried out securely within a cloud infrastructure. To be secure, query processing must(1) authenticate users and machines involved in query processing, (2) secure the transferof data across machines in the cloud, and (3) ensure the integrity of all query results. Allthree requirements can be directly applied to mitigate potential threats at theinfrastructure, network, and user levels2. System Analysis:2.1 Existing System : Efforts at each layer of network systems Mesh network between STAs Ad hoc mode in IEEE 802.11 standard2.2 Proposed System: • IEEE 802.11 protocol under unsaturated traffic conditions for multi-hop networks
    • • Bandwidth reservation • QoS Routing • Congestion Control • MAC protocol : DCF(CP) / PCF(CFP) • Decision making • two-dimensional Markov chain model to analyze the performance of the IEEE 802.11 protocol in single hop wireless networks2.3 Feasibility Study: A feasibility study is an evaluation of a proposal designed todetermine the difficulty in carrying out a designated task. Generally, Itprecedes technical development and project implementation. Its anevaluation or analysis of the potential impact of a proposed project.2.3.1 Economical Feasibility
    • Economic analysis is the most frequently used method for evaluatingthe effectiveness of a new system, benefits outweigh costs, then the decisionis made to design and implement the system.2.3.2 Operational Feasibility Operational feasibility is a measure of how well a proposed systemsolves the problems, and takes advantage of the opportunities identifiedduring scope definition and how it satisfies the requirements identified in therequirements analysis phase of system development2.3.3 Technical Feasibility An outline design of system requirements in terms of Input, Processes,Output, Fields, Programs, and Procedures. This can be quantified in terms ofvolumes of data, trends, frequency of updating, etc. in order to estimatewhether the new system will perform adequately or not. Technologicalfeasibility is carried out to determine whether the company has thecapability, in terms of software, hardware, personnel and expertise, to handlethe completion of the project
    • 3. SYSTEM REQUIREMENTS:3.1 Hardware Requirements:Processor Type : Pentium -IVSpeed : 2.4GHZRam : 256 MB RAMHard disk : 20 GB HD3.2 Software Requirements:Operating System : LinuxProgramming Package : Tcl Scripting , C++Tools : VMware4 Software Descriptions
    • Network simulation is a technique where a program models thebehavior of a network either by calculating the interaction between thedifferent network entities (hosts/routers, data links, packets, etc) usingmathematical formulas, or actually capturing and playing back observationsfrom a production network. The behavior of the network and the variousapplications and services it supports can then be observed in a test lab;various attributes of the environment can also be modified in a controlledmanner to assess how the network would behave under different conditions.When a simulation program is used in conjunction with live applications andservices in order to observe end-to-end performance to the user desktop, thistechnique is also referred to as network emulation.Motivation for Simulations • Cheap -- does not require costly equipment • Complex scenarios can be easily tested • Results can be quickly obtained – more ideas can • be tested in a smaller timeframe • The real thing isnt yet available
    • • Controlled experimental conditions • Repeatability helps aid debugging • Disadvantages: Real systems too complex to modelMost of the commercial simulators are GUI driven, while some networksimulators require input scripts or commands (network parameters). Thenetwork parameters describe the state of the network (node placement,existing links) and the events (data transmissions, link failures, etc).Important outputs of simulations are the trace files. Trace files can documentevery event that occurred in the simulation and are used for analysis. Certainsimulators have added functionality of capturing this type of data directlyfrom a functioning production environment, at various times of the day,week, or month, in order to reflect average, worst-case, and best-caseconditions Most network simulators use discrete event simulation, in which a listof pending "events" is stored, and those events are processed in order, withsome events triggering future events -- such as the event of the arrival of apacket at one node triggering the event of the arrival of that packet at adownstream node.
    • Some network simulation problems, notably those relying on queuingtheory, are well suited to Markov chain simulations, in which no list offuture events is maintained and the simulation consists of transiting betweendifferent system "states" in a memory less fashion. Markov chain simulationis typically faster but less accurate and flexible than detailed discrete eventsimulation. Some simulations are cyclic based simulations and these arefaster as compared to event based simulations.Advantages of simulation * Normal analytical techniques make use of extensive mathematicalmodels which require assumptions and restrictions to be placed on themodel. This can result in an avoidable inaccuracy in the output data.Simulations avoid placing restrictions on the system and also take randomprocesses into account; in fact in some cases simulation is the only practicalmodeling technique applicable * Analysts can study the relationships between components in detail andcan simulate the projected consequences of multiple design options beforehaving to implement the outcome in the real-world. * It is possible to easily compare alternative designs so as to select theoptimal system.
    • * The actual process of developing the simulation can itself providevaluable insights into the inner workings of the network which can in turn beused at a later stage.Disadvantages of simulation * Accurate simulation model development requires extensive resources. * The simulation results are only as good as the model and as such arestill only estimates / projected outcomes. * Optimization can only be performed involving a few alternatives as themodel is usually developed using a limited number of variables. * Simulations cost a lot of money to build and are very expensive to makeInput data Simulation models are generated from a set of data taken from astochastic system. It is necessary to check that the data is statistically validby fitting a statistical distribution and then testing the significance of such afit. Further, as with any modelling process, the input data’s accuracy must bechecked and any outliers must be removed.
    • Output data When a simulation has been completed, the data needs to be analysed.The simulations output data will only produce a likely estimate of real-world events. Methods to increase the accuracy of output data include:repeatedly performing simulations and comparing results, dividing eventsinto batches and processing them individually, and checking that the resultsof simulations conducted in adjacent time periods “connect” to produce acoherent holistic view of the system The main idea is to partly implement HTTP, FTP and TCP protocols.Routing is the process of selecting paths in a network along which to sendnetwork traffic. Routing is performed for many kinds of networks, includingthe telephone network (Circuit switching) , electronic data networks (such asthe Internet), and transportation networks. This article is concerned primarilywith routing in electronic data networks using packet switching technology.In packet switching networks, routing directs packet forwarding, the transitof logically addressed packets from their source toward their ultimatedestination through intermediate nodes, typically hardware devices called
    • routers, bridges, gateways, firewalls, or switches. General-purposecomputers can also forward packets and perform routing, though they arenot specialized hardware and may suffer from limited performance. Therouting process usually directs forwarding on the basis of routing tableswhich maintain a record of the routes to various network destinations. Thus,constructing routing tables, which are held in the routers memory, is veryimportant for efficient routing. Most routing algorithms use only onenetwork path at a time, but multipath routing techniques enable the use ofmultiple alternative paths.Routing, in a more narrow sense of the term, is often contrasted withbridging in its assumption that network addresses are structured and thatsimilar addresses imply proximity within the network. Because structuredaddresses allow a single routing table entry to represent the route to a groupof devices, structured addressing (routing, in the narrow sense) outperformsunstructured addressing (bridging) in large networks, and has become thedominant form of addressing on the Internet, though bridging is still widelyused within localized environments.Routing schemes differ in their delivery semantics: • unicast delivers a message to a single specified node;
    • • broadcast delivers a message to all nodes in the network; • multicast delivers a message to a group of nodes that have expressed interest in receiving the message; • anycast delivers a message to any one out of a group of nodes, typically the one nearest to the source.Path selectionPath selection involves applying a routing metric to multiple routes, in orderto select (or predict) the best route. In the case of computer networking, the metric is computed by arouting algorithm, and can cover such information as bandwidth, networkdelay, hop count, path cost, load, MTU, reliability, and communication cost(see e.g. this survey for a list of proposed routing metrics). The routing tablestores only the best possible routes, while link-state or topological databasesmay store all other information as well.
    • Because a routing metric is specific to a given routing protocol, multi-protocol routers must use some external heuristic in order to select betweenroutes learned from different routing protocols. Ciscos routers. A localnetwork administrator, in special cases, can set up host-specific routes to aparticular machine which provides more control over network usage, permitstesting and better overall security. This can come in handy when required todebug network connections or routing tables. As the Internet and IP networks become mission critical businesstools, there has been increased interest in techniques and methods to monitorthe routing posture of networks. Incorrect routing or routing issues causeundesirable performance degradation, flapping and/or downtime. Monitoringrouting in a network is achieved using Route analytics tools and techniques.Protocols: TCP, UDP, HTTP, Routing algorithms etc • Traffic Models: CBR, VBR, Web etc • Error Models: Uniform, bursty etc • Radio propagation, Mobility models • Energy Models • Topology Generation tools
    • • Visualization tools • ExtensibilitySimulators help in easy verification of protocols in less time, money • NS offers support for simulating a variety of • protocol suites and scenarios • Front end is oTCL, back end is C++ • NS is an on-going effort of research and development5 Project Descriptions5.1 Problem Definition • Error-free retransmission • No delay bound under bad link • Resource fluctuation due to wireless medium • Delay for adaptation
    • 5.2 Overview of the Project Single hop IEEE 802.11 networks under saturated traffic conditions.A model that describe the behavior of IEEE 802.11 under different offeredtraffic loads. This model shows the effect of the offered load on thetransmission probability. We also propose a three dimensional model toattempt to describe the behavior of multi-hop 802.11 networks. The 3Dmodel allows the modeling of not only data sources but also relay stationsthat forward traffic. The IEEE 802.11 DCF scheme, stressing key elementsrelated to this paper. The protocol under unsaturated traffic loads isdiscussed.5.3 Module Description 1. Multi-hop Wireless Network A wireless network adopting multihop wireless technology withoutdeployment of wired backhaul links Similar to Mobile Ad hoc Networks(MANET), but nodes in MWN is relative ‘fixed’ , it may introduce‘hierarchy’ network architecture. every station is assumed to be a datasource that sends out saturated traffic. In a multi-hop wireless network, each
    • station in the whole network is not necessarily a data source. A station mayact as a data source for a period of time when it has original data to send,while at other times it may act as a relay station that simply forwards otherstations’ data 2. IEEE 802.11 MAC protocol Recently, the IEEE has standardized the 802.11 protocol for WirelessLocal Area Networks. The primary medium access control (MAC) techniqueof 802.11 is called distributed coordination function (DCF). DCF is a carriersense multiple access with collision avoidance (CSMA/CA) scheme withbinary slotted exponential back off. We provides a simple, but neverthelessextremely accurate, analytical model to compute the 802.11 DCFthroughput, in the assumption of finite number of terminals and idealchannel conditions. The proposed analysis applies to both the packettransmission schemes employed by DCF, namely, the basic access and theRTS/CTS access mechanisms. In addition, it also applies to a combinationof the two schemes, in which packets longer than a given threshold aretransmitted according to the RTS/CTS mechanism.
    • Media Access Scheme: CSMA/CA Avoidance by RTS/CTS ACK mechanism Exponential Back off 3. Implementation of saturated traffic in relay station Stations are statistically identical, each station has idle periods that areexponentially distributed, and packet length is constant. At any given time,statistically, a certain number of stations within a given station’stransmission range act as data sources that inject data traffic. These arecalled source stations. Other stations act as data relays that forward trafficwithin the network. These are called relay stations. A relay station listens tothe medium, gets packets from it and forwards the packets it receives. Thenumber of packets a relay station receives and accepts to forward dependson the upper layer routing protocol. the analysis of the MAC protocol, weneed to find a way to isolate or take into account the upper layer protocol.The different routing protocols distribute the traffic load among the stationsin different ways
    • 4. Performance Analysis • Energy Conception • Packet delay • Flow of traffic5.3.1 Modules 1. Multi-hop Wireless Network 2. IEEE 802.11 MAC protocol 3. Implementation of saturated traffic in relay station 4. Performance analysis
    • 5.4 Data Flow DiagramLevel 0: Multi-hop Node Ad-Hoc Single hop Networks neighbor creationLevel 1: Source Node Destination Node Response IEEE802.11 protocol
    • Level 2: Source Relay Node Destination One hop neighbor Traffic Monitoring IEEE802.11 protocol5.5 Use case Diagram
    • Intermediate Source Relay Destination Station Request One hop neighbor Response IEEE802.11 Routing Traffic Monitoring6. System Testing
    • The program ``validate in the root directory of the ns distribution runs allcurrent standard tests. Protocols covered in validate represent the most stablecore of ns. We insure that validate passes on several different systems foreach ns release, and we run it over the daily snapshot (see below).We encourage you to report problems with validated protocols to us. We tryto resolve these problems rapidly (as resources allow).Even though we consider these protocols ``validated, our test suite coverageis not complete. You are advised to look at what aspects of the protocols aretested in the test suite before drawing research conclusions from theseprotocols.Protocols and modules covered at least in part by validate include thefollowing:Application-level: • HTTP, web caching and invalidation, TcpApp (test-suite- webcache.tcl) • telnet and ftp sources (test-suite-simple.tcl) • Constant-Bit-Rate (CBR) sources (e.g., in test-suite-cbq.tcl) • On/Off sources (in test-suite-intserv.tcl)
    • Transport protocols (UDP, TCP, RTP, SRM): • basic TCP behavior (test-suite-simple.tcl, test-suite-v1{,a}.tcl) • Tahoe, Reno, New-Reno, and SACK TCP under different losses (test- suite-tcpVariants.tcl) • FACK TCP (limited validation in test-suite-tcpVariants.tcl) • TCP vegas (test-suite-vegas-v1.tcl) • New-Reno TCP (test-suite-newreno.tcl) • SACK TCP (test-suite-sack{,-v1,v1a}) • full TCP (test-suite-full.tcl), partial validation only. • TCP initial window behavior (test-suite-tcp.tcl) • rate-based pacing TCP (test-suite-rbp.tcl) • RFC-2001 (Reno) TCP behavior (test-suite-rfc2001.tcl) • RTP (in test-suite-friendly.tcl, not yet added to "validate") • SRM (in test-suite-srm.tcl)Routing: • algorithmic routing (test-suite-algo-routing)
    • • hierarchical routing (test-suite-hier-routing.tcl) • lan routing and broadcast (test-suite-lan.tcl) • manual routing (test-suite-manual-routing.tcl) • centralized multicast, DM multicast, not detailedDM, not multicast over LAN (test-suite-mcast.tcl) • routing dynamics (test-suite-routed.tcl) • detailed simulation using virtual classifier (test-suite-vc.tcl) • mixed-mode session-levels simulation (test-suite-mixmode.tcl) • session-level simulation (test-suite-session.tcl)Router Mechanisms (scheduling, queue management, admissionscontrol, etc.): • several queue scheduling algorithms: FQ (Fair Queueing), SFQ (Stochastic Fair Queuing), DRR (Deficit Round Robin), FIFO (with drop-tail and RED queue management) (test-suite-schedule.tcl) • CBQ (both in v1 and v2 mode) (test-stuite-cbq{,-v1,-v1a}) • RED queue management (test-suite-red{,-v1,-v1a}) • ECN behavior (and TCP interactions) (test-suite-ecn.tcl) • admission control algorithms: MS, HB, ACTP, ACTO, parameter- based (in test-suite-intserv.tcl)
    • Link-layer mechanisms: • LANs, with CSMA/CD MAC protocols (in test-suite-lan.tcl) • snoopOther: • Error Modules (e.g., in test-suite-ecn.tcl, test-suite-tcp-init-win.tcl, test-suite-session.tcl, and test-suite-srm.tcl) In addition there are a number of protocols in the standard ns distributionwhich are not covered by validate. Because they cannot be automaticallytested, bit-rot sometimes breaks these protocols. We attempt to keep non-validated protocols working and welcomebug reports. Becuase of difficulties maintaining code that we did not writeand for which we may not know ``ground truth, we cannot promise thatthese protocols will remain working. We strongly encourage people usingthese protocols in their research to examine their output carefully andimplement test suites for them so that we can move them into the``validated category.Configure:
    • A simple ./configure will try to auto-detect the packages ns needs to build.Auto-detection searchs sensible places (like /usr/local) and the directoryabove current direcory. If you have packages installed elsewhere you canexplicitly tell ns where something is with options like --with-tcl=/your/path/to/tcl. Run ./configure --help for a complete list of optionsTo make this even easier, the make utility has a set of built-in rules so youonly need to tell it what new things it needs to know to build your particularutility. For example, if you typed in make love, make would first look forsome new rules from you. If you didnt supply it any then it would look at itsbuilt-in rules. One of those built-in rules tells make that it can run the linker(ld) on a program name ending in .o to produce the executable program.So, make would look for a file named love.o. But, it wouldnt stop there.Even if it found the .o file, it has some other rules that tell it to make sure the.o file is up to date. In other words, newer than the source program. Themost common source program on Linux systems is written in C and its filename ends in .c.If make finds the .c file (love.c in our example) as well as the .o file, itwould check their timestamps to make sure the .o was newer. If it was not
    • newer or did not exist, it would use another built-in rule to build a new .ofrom the .c (using the C compiler). This same type of situation exists forother programming languages. The end result, in any case, is that whenmake is done, assuming it can find the right pieces, the executable programwill be built and up to date.The old UNIX joke, by the way, is what early versions of make said when itcould not find the necessary files. In the example above, if there was nolove.o, love.c or any other source format, the program would have said:make: dont know how to make love. Stop.Getting back to the task at hand, the default file for additional rules inMakefile in the current directory. If you have some source files for aprogram and there is a Makefile file there, take a look. It is just text. Thelines that have a word followed by a colon are targets. That is, these arewords you can type following the make command name to do variousthings. If you just type make with no target, the first target will be executed.What you will likely see at the beginning of most Makefile files are whatlook like some assignment statements. That is, lines with a couple of fieldswith an equal sign between them. Surprise, that is what they are. They set
    • internal variables in make. Common things to set are the location of the Ccompiler (yes, there is a default), version numbers of the program and such.This now beings up back to configure. On different systems, the C compilermight be in a different place, you might be using ZSH instead of BASH asyour shell, the program might need to know your host name, it might use adbm library and need to know if the system had gdbm or ndbm and a wholebunch of other things. You used to do this configuring by editing Makefile.Another pain for the programmer and it also meant that any time you wantedto install software on a new system you needed to do a complete inventoryof what was where.As more and more software became available and more and more POSIX-compliant platforms appeared, this got harder and harder. This is whereconfigure comes in. It is a shell script (generally written by GNU Autoconf)that goes up and looks for software and even tries various things to see whatworks. It then takes its instructions from Makefile.in and builds Makefile(and possibly some other files) that work on the current system.Background work done, let me put the pieces together.
    • • You run configure (you usually have to type ./configure as most people dont have the current directory in their search path). This builds a new Makefile. • Type make This builds the program. That is, make would be executed, it would look for the first target in Makefile and do what the instructions said. The expected end result would be to build an executable program. • Now, as root, type make install. This again invokes make, make finds the target install in Makefile and files the directions to install the program.This is a very simplified explanation but, in most cases, this is what youneed to know. With most programs, there will be a file named INSTALLthat contains installation instructions that will fill you in on otherconsiderations. For example, it is common to supply some options to theconfigure command to change the final location of the executable program.There are also other make targets such as clean that remove unneeded filesafter an install and, in some cases test which allows you to test the softwarebetween the make and make install steps.
    • 7. Literature review1. Achieving higher throughput in ieee 802.11 wireless local areanetworks with burst transmission methods : As extensions in theemerging 802.11e for quality-of-service provisioning, burst transmission andthe acknowledgment aggregation are the two important operations toimprove the channel efficiency of IEEE 802.11-based wireless local areanetworks (WLANs). However, only a few works have been done on theseoperations, and usually assumed the networks to be operated under saturatedtraffic conditions and error-free channels. In practice, the assumptions maynot be valid because real-time traffic with proper rate control will notsaturate the networks and the channel is generally error-prone. Thus, theauthors consider two new methods resulted from these operations andanalyse their performance under unsaturated and error-prone WLANs, witha Markov chain model. The results show that the new methods generallyhave better throughput than the conventional IEEE 802.11 medium accesscontrol (MAC) in the WLANs.
    • 2. On the throughput performance of multirate IEEE 802.11 networkswith variable-loaded stations: analysis, modeling, and a novel proportionalfairness criterion: This paper focuses on multirate IEEE 802.11 WirelessLAN employing the mandatory Distributed Coordination Function (DCF)option. Its aim is threefold. Upon starting from the multi-dimensionalMarkovian state transition model proposed by Malone et.al. forcharacterizing the behavior of the IEEE 802.11 protocol at the MediumAccess Control layer, it presents an extension accounting for packettransmission failures due to channel errors. Second, it establishes theconditions under which a network constituted by N stations, each stationtransmitting with its own bit rate, Rd(s), and packet rate, λs, can be assumedloaded. Finally, it proposes a modified Proportional Fairness (PF) criterion,suitable for mitigating the rate anomaly problem of multirate loaded IEEE802.11 Wireless LANs, employing the mandatory DCF option. Compared tothe widely adopted assumption of saturated network, the proposed fairnesscriterion can be applied to general loaded networks. The throughputallocation resulting from the proposed algorithm is able to greatly increasethe aggregate throughput of the DCF, while ensuring fairness levels amongthe stations of the same order as the ones guaranteed by the classical PF
    • criterion. Simulation results are presented for some sample scenarios,confirming the effectiveness of the proposed criterion for optimizedthroughput allocation.3. Enhancing quality of service in MANETS by effective routing :This paper evaluates the performance evaluation by combining Networklayer and MAC layer protocols with Transport layer congestion controlmechanisms operating in a mobile adhoc network. In Adhoc networks,certain QoS parameters like error rate, delay and packet loss are increasedand certain parameters like throughput and delivery ratio are decreased inTransport layer is due to MAC problems and disconnection is also possibledue to mobility because the network layer is not able to detect the path todeliver the packets. So, combine the mechanisms of these three layers toimprove the QoS drastically. We examine the effects of two different MACprotocols - IEEE 802.11and IEEE802.11e with AODV and DSR of routingalgorithms with Slow start and Arithmetic Increase and MultiplicativeDecrease (AIMD) mechanism of TCP.IEEE802.11 uses distributedcoordination function (DCF) where IEEE802.11e uses enhanced distributedcoordination function (EDCF). Specifically, we access the impact ofmultiple wireless hops and node mobility on the throughput performance of
    • TCP on each MAC protocol with two routing algorithms. Additionally theother QoS parameters of delay, Bandwidth delay product, delivery ratio andpacket loss is also investigated. Results show that in all instances, the QoSparameters 15-20% improvement in throughput, 40-45% improvement inbandwidth-delay product, 10-15% improvement in delivery ratio, packet lossis reduced drastically to 40-50% in IEEE802.11e with AODV algorithm innetwork layer and slow start mechanism in transport layer. Similarly Resultsshows, the QoS parameters 35-40% improvement in throughput, 25-30%improvement in bandwidth-delay product, 15-20% improvement in deliveryratio, packet loss is reduced drastically to 20-25% in IEEE802.11e withAODV algorithm in network layer and AIMD mechanism in transport layer.But if DSR algorithm is used in the network layer instead of AODV itaffects the QoS parameters. In both cases DSR algorithm increases the -packet loss which in turn affects the throughput and packet delivery ratio.The reason is analyzed and suggests the suitable mechanisms implementedin each layer to enhance QoS parameters.
    • 5. A distributed contention control mechanism for power saving in random-access Ad-hoc wireless local area networks: The power consumption of mobile computers connected to wireless networks is negatively affected by the congestion level of the channel, and significantly depends on the medium access control (MAC) protocol policy. This paper illustrates the design and the performance evaluation of a new mechanism for the distributed contention control of the random accesses to the shared transmission channel of a wireless LAN (WLAN). The aim is the design of a distributed access scheme where each frame transmission leads to an optimal power consumption level, from the network interface (NI) viewpoint. To achieve this goal, we present a new analytical model to define the optimal average power consumption required by the NI for a frame transmission, and for a given random-access scheme. Specifically, we considered the Standard IEEE 802.11 Distributed Coordination Function (DCF) access scheme for WLANs. By exploiting the optimal values analytically derived, we define a parametric and adaptive power-save, distributed contention control (PS-DCC) mechanism. The proposed mechanism has been investigated via simulation. The power consumption of the proposed mechanism approximates the analytically defined optimal level,
    • outperforming the Standard 802.11 DCF access scheme. To confirm the absence of overheads introduced, the channel utilization still results closely approximating the optimal values6. A Protocol Enhancement for IEEE 802.11 Distributed Power SavingMechanisms No Data Acknowledgement: Mobile devices includingwireless LAN functionality are becoming increasingly popular in society.The wide range of products available in the market target different customerneeds but most of them should meet two main requirements: QoS supportfor differentiating real-time services from non real-time and power savingfunctionality to achieve an operating time according to users expectations.The devices presenting the most challenging technical issues to meet thesetwo requirements are dual-mode handsets (cellular/WLAN) because of theirmandatory support of a strict QoS demanding application, VoIP, and theirsmall device size which severely limits the battery capacity. The focus of ourwork in this paper is the design and evaluation of an enhancement of thedistributed wireless LAN power saving mechanisms defined in the IEEE802.11 and 802.11e standards, no data acknowledgment (NDACK). Theobjective of NDAck is to increase the battery lifetime of wireless LANmobile devices while providing the required QoS. The protocol
    • improvement designed has been implemented in OPNET to evaluate theperformance enhancements obtained. Our results show that (i) NDAcksignificantly reduces the power consumption of stations running real-timeapplications, (ii) the larger the power consumption due to the congestion inthe wireless channel the larger the power consumption reduction withNDAck and (iii) NDAck results in a considerable QoS improvement forreal-time applications.8 Conclusion & Future Enhancements8.1 ConclusionThe performance analysis with saturated traffic does not apply to nodes thatdo not originate traffic but may forward it in on behalf of others. Sometimes,these relay stations may not have any packet to forward. Another challengeis the fact that not all relay stations receive the same amount of data toforward. This amount is determined by the upper layer routing protocol.8.2 Future Enhancements Enhancing the protocol from IEEE802.11 from IEEE802.11 e /IEEE802.16
    • 9 Appendix9.1 Source Code set val(chan) Channel/WirelessChannelset val(prop) Propagation/TwoRayGroundset val(netif) Phy/WirelessPhyset val(mac) Mac/802_11set val(ifq) Queue/DropTail/PriQueueset val(ll) LLset val(ant) Antenna/OmniAntennaset val(x) 800set val(y) 800set val(ifqlen) 1500set val(seed) 1.0set val(adhocRouting) AODVset val(nn) 10set val(stop) 15.0set val(energymodel) EnergyModel ;set val(radiomodel) RadioModel ;set val(initialenergy) 1000 ;# Initial energy in Joules
    • set ns_ [new Simulator]set topo [new Topography]set tracefd [open out.tr w]set namtrace [open out.nam w]$ns_ trace-all $tracefd$ns_ namtrace-all-wireless $namtrace $val(x) $val(y)$topo load_flatgrid $val(x) $val(y)set god_ [create-god $val(nn)]$ns_ node-config -adhocRouting AODV -llType $val(ll) -macType $val(mac) -ifqType $val(ifq) -ifqLen $val(ifqlen) -antType $val(ant)
    • -propType $val(prop) -phyType $val(netif) -channelType $val(chan) -topoInstance $topo -agentTrace ON -routerTrace ON -macTrace ON for {set i 0} {$i < $val(nn) } {incr i} {set node_($i) [$ns_ node]}set X1(0) 130.32set X1(1) 235.55set X1(2) 336.499set X1(3) 147set X1(4) 488.23set X1(5) 374.881set X1(6) 246.766set X1(7) 167.161set X1(8) 419.979set X1(9) 532.0set Y1(0) 539.172
    • set Y1(1) 476.86set Y1(2) 532.92set Y1(3) 774.801set Y1(4) 455.623set Y1(5) 344.034set Y1(6) 664.992set Y1(7) 326.676set Y1(8) 754.081set Y1(9) 619.0for {set i 0} {$i < $val(nn) } {incr i} { $node_($i) set X_ $X1($i) $node_($i) set Y_ $Y1($i) $node_($i) set Z_ 0.0}puts "Loading scenario file..."for {set i 0} {$i < $val(nn) } {incr i} { $ns_ initial_node_pos $node_($i) 30
    • }for {set i k} {$i < $val(nn) } {incr i} { $ns_ at $val(stop).0 "$node_($i) reset";}puts "-----------------------------------------------"puts "Routing table"puts "-----------------------------------------"puts "|Node | one hop neighbour|"puts "-----------------------------------------"for {set i 0} {$i < $val(nn) } {incr i} {for {set j 0} {$j < $val(nn) } {incr j} {set a [ expr $X1($j)-$X1($i)]set b [ expr $a*$a]set c [ expr $Y1($j)-$Y1($i)]set d [ expr $c*$c]set e [ expr $b+$d]
    • set f 0.5set g [expr pow($e,$f)]if {$g <= 200 && $i != $j} {puts "| Node($i) | ($j) |"}}puts "-----------------------------------------"}set udp_(0) [new Agent/UDP]$ns_ attach-agent $node_(0) $udp_(0)set null1_(0) [new Agent/Null]$ns_ attach-agent $node_(4) $null1_(0)set cbr1_(0) [new Application/Traffic/CBR]$cbr1_(0) set packetSize_ 1000$cbr1_(0) set interval_ 0.01$cbr1_(0) set random_ 1$cbr1_(0) set maxpkts_ 1000$cbr1_(0) attach-agent $udp_(0)
    • $ns_ connect $udp_(0) $null1_(0)$ns_ at 1.00 "$cbr1_(0) start"$ns_ at 5.3 "$cbr1_(0) stop"$ns_ at 0.0 "$node_(0) setdest 589 732 5"$ns_ at 0.0 "$node_(1) setdest 294 670 5"$ns_ at 0.0 "$node_(2) setdest 395 726 5"$ns_ at 0.0 "$node_(3) setdest 405 765 5"$ns_ at 0.0 "$node_(4) setdest 147 649 5"$ns_ at 0.0 "$node_(5) setdest 733 537 5"$ns_ at 0.0 "$node_(6) setdest 605 758 5"$ns_ at 0.0 "$node_(7) setdest 426 520 5"$ns_ at 0.0 "$node_(8) setdest 378 647 5"$ns_ at 0.0 "$node_(9) setdest 490 612 5"$ns_ at 0.05 "$node_(0) label M0"$ns_ at 0.05 "$node_(1) label M1"$ns_ at 0.05 "$node_(2) label M2"$ns_ at 0.05 "$node_(3) label M3"$ns_ at 0.05 "$node_(4) label M4"$ns_ at 0.05 "$node_(5) label M5"$ns_ at 0.05 "$node_(6) label M6"$ns_ at 0.05 "$node_(7) label M7"$ns_ at 0.05 "$node_(8) label M8"
    • $ns_ at 0.05 "$node_(9) label M9"$ns_ at 0.05 "$node_(0) add-mark m blue circle"$ns_ at 0.05 "$node_(1) add-mark m gray circle"$ns_ at 0.05 "$node_(2) add-mark m gray circle"$ns_ at 0.05 "$node_(3) add-mark m gray circle"$ns_ at 0.05 "$node_(4) add-mark m green circle"$ns_ at 0.05 "$node_(5) add-mark m gray circle"$ns_ at 0.05 "$node_(6) add-mark m gray circle"$ns_ at 0.05 "$node_(7) add-mark m gray circle"$ns_ at 0.05 "$node_(8) add-mark m gray circle"$ns_ at 0.05 "$node_(9) add-mark m gray circle"$ns_ at 15.0 "finish"$ns_ at $val(stop).0002 "puts "NS EXITING..." ; $ns_ halt"puts $tracefd "M 0.0 nn $val(nn) x $val(x) y $val(y) rp $val(adhocRouting)"puts $tracefd "M 0.0 prop $val(prop) ant $val(ant)"puts "Starting Simulation..."proc finish {} { #exec nam out.nam & exit 0}
    • $ns_ run9.2 Screen Shots
    • REFERENCES[1] Y. D. Barowski and S. Biaz, “The performance analysis of ieee-802.11under unsaturated traffic conditions,” Tech. Rep. CSSE04-09, AuburnUniversity, Aug. 2004.[2] V. Bharghavan, A. Demers, S. Shenker, and L. Zhang, “MACAW: Amedia access protocol for wireless LANs,” in ACM SIGCOMM, London,U.K, pp. 212–225, Oct. 1994.[3] G. Bianchi, “Performance analysis of the IEEE802.11 distributedcoordination function,” IEEE Journal in Selected Areas: Communication,vol. 18, pp. 535–547, March 2000.[4] L. Bononi, M. Conti, and L. Donatiello, “A distributed mechanism forpower saving in IEEE 802.11 wireless lans,” Mobile Networks andApplications, vol. 6, no. 3, pp. 211–222, 2001.[5] F. Cali, M. Conti, and Gregori, “IEEE802.11 wireless lan: Capacityanalysis and protocol enhancement,” in INFOCOM ’98 Seventeenth AnnualJoint Conference of the IEEE Computer and Communications Societies.Proceedings. IEEE, 1998.
    • [6] M. M. Carvalho and J. J. Garcia-Luna-Aceves, “Delay analysis of theIEEE802.11 in single-hop networks,” in 11th IEEE International Conferenceon Network Protocols (ICNP’03), Atlanta, Georgia, USA, Nov. 2003.[7] H. S. Chhaya and S. Gupta, “Performance modeling of asynchronousdata transfer methods of IEEE802.11 mac protocol,” Wirel. Netw., vol. 3,no. 3, pp. 217–234, 1997.[8] D. S. J. De Couto, D. Aguayo, B. A. Chambers, and R. Morris,“Performance of multihop wireless networks: Shortest path is not enough,”in Proceedings of the First Workshop on Hot Topics in Networks (HotNets-I), (Princeton, New Jersey), ACM SIGCOMM, October 2002.[9] L. M. Feeney and M. Nilsson, “Investigating the energy consumptionof a wireless network interface in an ad hoc networking environment,” inIEEE INFOCOM, Anchorage, AK, USA, 2001.[10] L. Huang and T.-H. Lai, “On the scalability of IEEE802.11 ad hocnetworks,” in Proceedings of the 3rd ACM international symposium onMobile ad hoc networking & computing, pp. 173–182, ACM Press, 2002