DOCSLIB.ORG

Performance Analysis of Multi-Hop Wireless Networks

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Performance Analysis of Multi-Hop Wireless Networks PERFORMANCE ANALYSIS OF MULTI-HOP WIRELESS NETWORKS A thesis submitted to Kent State University in partial fulfillment of the requirements for the degree of Master of Science by Hassan Hadi Latheeth AL-Maksousy December 2012 Thesis written by Hassan Hadi Latheeth AL-Maksousy B.S., Al-Mustansiriya University, 2006 Approved by Dr. Hassan Peyravi , Chair, Master Thesis Committee Dr. Javed Khan , Members, Master Thesis Committee Dr. Feodor F. Dragan Accepted by Dr. Javed Khan , Chair, Department of Computer Science Dr. Raymond A. Craig , Associate Dean, College of Arts and Sciences ii TABLE OF CONTENTS LIST OF FIGURES . vii LIST OF TABLES . viii Acknowledgements . ix 1 Introduction . 1 1.1 Multi-hop Wireless Networks . 2 1.2 Issues and Difficulties . 3 1.2.1 Unpredictable Link Properties . 5 1.2.2 Node Mobility . 5 1.2.3 Limited Battery Life . 6 1.2.4 Hidden and Exposed Terminal Problems . 6 1.2.5 Route Maintenance . 7 1.2.6 Security . 8 1.3 Multi-hop Wireless Network Protocols . 8 2 Previous and Current Work . 9 2.1 IEEE 802.11s: Mesh Networks . 9 2.1.1 Approaches to Wireless Mesh . 12 iii 2.1.2 The Single Radio Approach (Everything on the Same Channel) 12 2.1.3 The Dual Radio Approach (Sharing the Backhaul) . 13 2.1.4 The Multi Radio Approach (A Structured Wireless Mesh) . 13 2.1.5 Physical Layer . 14 2.1.6 Frame Structure of IEEE 802.11s . 15 2.1.7 Mesh Coordinated Channel Access . 17 2.1.8 Routing . 18 2.1.9 Applications . 19 2.1.10 Issues . 20 2.2 IEEE 802.15.5 . 22 2.3 IEEE 802.16j . 24 2.3.1 Physical Layer . 25 2.3.2 OFDMA and SOFDMA . 27 2.3.3 Frame Structure of IEEE 802.16j . 28 2.3.3.1 Frame Structure for Transparent Relay . 28 2.3.3.2 Frame Structure for Non Transparent Relay . 29 2.3.4 MAC Layer . 29 2.3.5 Routing . 32 2.3.6 Issues . 32 2.3.7 QoS Scheduling . 34 2.4 Previous Work . 35 iv 2.4.1 Throughput . 36 2.4.2 End-to-End Delay . 36 2.4.3 Fairness . 37 3 Multi-hop Wireless Network Performance . 39 3.1 Bandwidth Degradation . 39 3.2 Radio Frequency Interference . 40 3.3 Network Latency . 41 3.4 Fairness Provisioning Technique . 43 3.4.1 Background on Fairness . 43 3.4.2 Jain Fairness Index . 44 3.4.3 Max-Min Fairness . 44 3.4.4 Proportional Fairness . 45 4 The Simulator . 46 4.1 Software . 46 4.2 QualNet Architecture . 48 4.3 Models . 51 4.3.1 Nodes and Topology . 51 4.3.2 Applications . 52 4.3.2.1 Constant Bitrate . 52 4.3.2.2 File Transfer Protocol . 53 v 4.3.2.3 Source Traffic Model . 54 4.3.3 Protocols . 54 4.3.3.1 IEEE 802.11e . 55 4.3.3.2 IEEE 802.11s . 55 4.3.3.3 TDMA . 55 4.3.3.4 TDMA characteristics . 56 4.4 Simulation Parameters . 57 4.4.1 Duration . 57 4.4.2 QoS Metrics . 57 4.4.3 Physical Layer . 58 4.4.4 MAC Layer . 58 4.4.5 Network Layer . 59 5 Results . 60 6 Future Work and Conclusion . 65 6.1 Future Work . 65 6.2 Conclusion . 66 Glossary . 68 BIBLIOGRAPHY . 72 vi LIST OF FIGURES 1 Relay and mesh. 3 2 Hidden terminal. 6 3 Exposed terminal. 7 4 IEEE 802.11s frame structure . 16 5 IEEE 802.16j transparent frame structure. 29 6 IEEE 802.16j non-transparent frame structure. 30 7 Throughput degradation. 40 8 QualNet architecture. 46 9 (a) Linear, and (b) tree. 51 10 Throughput and normalized throughput. 60 11 Average throughput on varying topologies. 61 12 Fairness index of average end-to-end delay on varying topologies. 61 13 Average end-to-end delay per node on varying topologies. 62 14 Average end-to-end delay per node on varying topologies. 63 15 Average throughput and Jain fairness index for varying protocols. 63 16 Average end-to-end delay and Jain fairness index for varying protocols. 63 17 Controlling rate for better fairness. 64 vii LIST OF TABLES 1 Scenario input data. 52 viii Acknowledgements I would first like to thank my adviser Dr. Hassan Peyravi for all of his guidance, support, and advice. He has broadened my knowledge and helped me to become a better researcher. I was truly fortunate to have him as my adviser. I would also like to thank the committee members Dr. Javed Khan and Dr. Feodor F. Dragan for the valuable comments and suggestions they have offered me. Their feedback has improved the quality of this thesis. I am so thankful for my parents. I am thankful for their unconditional love and for raising me the right way, making me the person I am today. Finally, I would like to thank the Kent community at large and especially the department of Computer Science. I would like to extend a special thanks to Marcy Curtiss, the gradute secretary. They have all made me feel welcome and have sur- rounded me with the warmth of a family. Kent State University will always have a special place in my heart. ix CHAPTER 1 Introduction Broadband access to the Internet has become necessary in all of todays networks to support high quality multimedia services, such as video, voice, high definition TV or interactive games. Network communications with end devices are becoming increasingly wireless. Many standards for wireless networking are now taking the next step to support mesh architectures in which data is commonly forwarded on paths consisting of multiple wireless hops. These multi-hop network architectures have great flexibilities, however it will be shown that they suffer from a performance limitation. There is a significant body of the literature addressing the fairness problem with respect to throughput and delay performance in multi-hop wireless networks. How- ever, none has shown the impact of other important factors such as network topology, level of aggregation, and source traffic models. In this thesis, we study the effect of these important factors under normal and extreme conditions and show major limita- tions in terms of hop counts, traffic load and contention domain in terms of horizontal (spread) and vertical (hop count) contentions. The result show that supporting de- lay and throughput sensitive applications require careful deployment of the underling 1 2 relay nodes. 1.1 Multi-hop Wireless Networks Multi-hop wireless networks (MWNs) are being used as alternative solutions to the wired back-haul links. They are similar to the mobile ad hoc networks (MANETs), but differ in terms of mobility, topology, and architecture. Nodes in MWNs are relatively fixed with relatively robust connectivity and often follow a hierarchical architecture. MWNs can be classified into relay architecture, where nodes form a sink tree, or mesh topology, in which multiple connections exists among mesh nodes. Most of wireless networks operate in high frequency bands above 2 GHz. However, at higher carrier frequency cell size needs to be decreased because of an increase in path loss [1] and increased power consumption. In order to conserver power, base stations (BSs) need to be placed closer together. Therefore more BSs are needed to achieve the same coverage. MWNs overcome these problems by extending ranges through increasing capacity and reduce power consumption through route diversity. A MWN can be arranged in one of two architectures: relay or mesh. The relay and mesh topologies have some of the same elements. They both have BSs and subscriber stations (SSs). The SSs are trying to connect with the BS, but each topology does this in a different way. In relay, the network infrastructure includes relay stations (RSs) that are mostly installed, owned and controlled by a service provider. A RS is not directly connected 3 to wire infrastructure and has the minimum functionality necessary to support multi- hop communication. The important aspect is that traffic always leads from or to a BS. SS to SS communication paths that do not include a BS are not considered. SSs may forward traffic to another SS, RS or BS, and can communicate directly with each other. Nodes are comprised of mesh routers and mesh clients. Therefore, the routing process is controlled not only by BSs but also by SSs. Each node can forward packets on behalf of other nodes that may not be within direct wireless transmission range of their destination. A system that has a direct connection to backhaul services outside the mesh network is termed a mesh BS. All the other systems are called a mesh SS [2]. So, every SS can be RS but not every RS can be a SS. BS RS RS SS SS SS BS Relay Mesh Figure 1: Relay and mesh. 1.2 Issues and Difficulties There are many benefits for using multi-hop technology such as rapid deployment with lower-cost back-haul, extend coverage due to multi-hop forwarding in hard-to- wire areas, enhanced throughput due to shorter hops and extended battery life due 4 to lower power transmission. [2] MWNs suffer from some drawbacks including: 1. Performance: MWNs do not match the performance of a wired network. 2. Routing complexity: These networks need path management which creates ex- tra delay due to multi-hop relaying. For example, we must also specify the maximum number of hops for each node which should not be exceeded, because more hops mean more transmission time. 3. Increased channel contention: When a packet follows a.
Load more

Recommended publications
  • TCP Over Wireless Multi-Hop Protocols: Simulation and Experiments
    TCP over Wireless Multi-hop Protocols: Simulation and Experiments Mario Gerla, Rajive Bagrodia, Lixia Zhang, Ken Tang, Lan Wang {gerla, rajive, lixia, ktang, lanw}@cs.ucla.edu Wireless Adaptive Mobility Laboratory Computer Science Department University of California, Los Angeles Los Angeles, CA 90095 http://www.cs.ucla.edu/NRL/wireless Abstract include mobility, unpredictable wireless channel such as fading, interference and obstacles, broadcast medium shared In this study we investigate the interaction between TCP and by multiple users and very large number of heterogeneous MAC layer in a wireless multi-hop network. This type of nodes (e.g., thousands of sensors). network has traditionally found applications in the military To these challenging physical characteristics of the ad-hoc (automated battlefield), law enforcement (search and rescue) network, we must add the extremely demanding requirements and disaster recovery (flood, earthquake), where there is no posed on the network by the typical applications. These fixed wired infrastructure. More recently, wireless "ad-hoc" include multimedia support, multicast and multi-hop multi-hop networks have been proposed for nomadic computing communications. Multimedia (voice, video and image) is a applications. Key requirements in all the above applications are reliable data transfer and congestion control, features that are must when several individuals are collaborating in critical generally supported by TCP. Unfortunately, TCP performs on applications with real time constraints. Multicasting is a wireless in a much less predictable way than on wired protocols. natural extension of the multimedia requirement. Multi- Using simulation, we provide new insight into two critical hopping is justified (among other things) by the limited problems of TCP over wireless multi-hop.
    [Show full text]
  • Configuring Ipv6 First Hop Security
    Configuring IPv6 First Hop Security This chapter describes how to configure First Hop Security (FHS) features on Cisco NX-OS devices. This chapter includes the following sections: • About First-Hop Security, on page 1 • About vPC First-Hop Security Configuration, on page 3 • RA Guard, on page 6 • DHCPv6 Guard, on page 7 • IPv6 Snooping, on page 8 • How to Configure IPv6 FHS, on page 9 • Configuration Examples, on page 17 • Additional References for IPv6 First-Hop Security, on page 18 About First-Hop Security The Layer 2 and Layer 3 switches operate in the Layer 2 domains with technologies such as server virtualization, Overlay Transport Virtualization (OTV), and Layer 2 mobility. These devices are sometimes referred to as "first hops", specifically when they are facing end nodes. The First-Hop Security feature provides end node protection and optimizes link operations on IPv6 or dual-stack networks. First-Hop Security (FHS) is a set of features to optimize IPv6 link operation, and help with scale in large L2 domains. These features provide protection from a wide host of rogue or mis-configured users. You can use extended FHS features for different deployment scenarios, or attack vectors. The following FHS features are supported: • IPv6 RA Guard • DHCPv6 Guard • IPv6 Snooping Note See Guidelines and Limitations of First-Hop Security, on page 2 for information about enabling this feature. Configuring IPv6 First Hop Security 1 Configuring IPv6 First Hop Security IPv6 Global Policies Note Use the feature dhcp command to enable the FHS features on a switch. IPv6 Global Policies IPv6 global policies provide storage and access policy database services.
    [Show full text]
  • Junos® OS Protocol-Independent Routing Properties User Guide Copyright © 2021 Juniper Networks, Inc
    Junos® OS Protocol-Independent Routing Properties User Guide Published 2021-09-22 ii Juniper Networks, Inc. 1133 Innovation Way Sunnyvale, California 94089 USA 408-745-2000 www.juniper.net Juniper Networks, the Juniper Networks logo, Juniper, and Junos are registered trademarks of Juniper Networks, Inc. in the United States and other countries. All other trademarks, service marks, registered marks, or registered service marks are the property of their respective owners. Juniper Networks assumes no responsibility for any inaccuracies in this document. Juniper Networks reserves the right to change, modify, transfer, or otherwise revise this publication without notice. Junos® OS Protocol-Independent Routing Properties User Guide Copyright © 2021 Juniper Networks, Inc. All rights reserved. The information in this document is current as of the date on the title page. YEAR 2000 NOTICE Juniper Networks hardware and software products are Year 2000 compliant. Junos OS has no known time-related limitations through the year 2038. However, the NTP application is known to have some difficulty in the year 2036. END USER LICENSE AGREEMENT The Juniper Networks product that is the subject of this technical documentation consists of (or is intended for use with) Juniper Networks software. Use of such software is subject to the terms and conditions of the End User License Agreement ("EULA") posted at https://support.juniper.net/support/eula/. By downloading, installing or using such software, you agree to the terms and conditions of that EULA. iii Table
    [Show full text]
  • Don't Trust Traceroute (Completely)
    Don’t Trust Traceroute (Completely) Pietro Marchetta, Valerio Persico, Ethan Katz-Bassett Antonio Pescapé University of Southern California, CA, USA University of Napoli Federico II, Italy [email protected] {pietro.marchetta,valerio.persico,pescape}@unina.it ABSTRACT In this work, we propose a methodology based on the alias resolu- tion process to demonstrate that the IP level view of the route pro- vided by traceroute may be a poor representation of the real router- level route followed by the traffic. More precisely, we show how the traceroute output can lead one to (i) inaccurately reconstruct the route by overestimating the load balancers along the paths toward the destination and (ii) erroneously infer routing changes. Categories and Subject Descriptors C.2.1 [Computer-communication networks]: Network Architec- ture and Design—Network topology (a) Traceroute reports two addresses at the 8-th hop. The common interpretation is that the 7-th hop is splitting the traffic along two Keywords different forwarding paths (case 1); another explanation is that the 8- th hop is an RFC compliant router using multiple interfaces to reply Internet topology; Traceroute; IP alias resolution; IP to Router to the source (case 2). mapping 1 1. INTRODUCTION 0.8 Operators and researchers rely on traceroute to measure routes and they assume that, if traceroute returns different IPs at a given 0.6 hop, it indicates different paths. However, this is not always the case. Although state-of-the-art implementations of traceroute al- 0.4 low to trace all the paths
    [Show full text]
  • Routing Loop Attacks Using Ipv6 Tunnels
    Routing Loop Attacks using IPv6 Tunnels Gabi Nakibly Michael Arov National EW Research & Simulation Center Rafael – Advanced Defense Systems Haifa, Israel {gabin,marov}@rafael.co.il Abstract—IPv6 is the future network layer protocol for A tunnel in which the end points’ routing tables need the Internet. Since it is not compatible with its prede- to be explicitly configured is called a configured tunnel. cessor, some interoperability mechanisms were designed. Tunnels of this type do not scale well, since every end An important category of these mechanisms is automatic tunnels, which enable IPv6 communication over an IPv4 point must be reconfigured as peers join or leave the tun- network without prior configuration. This category includes nel. To alleviate this scalability problem, another type of ISATAP, 6to4 and Teredo. We present a novel class of tunnels was introduced – automatic tunnels. In automatic attacks that exploit vulnerabilities in these tunnels. These tunnels the egress entity’s IPv4 address is computationally attacks take advantage of inconsistencies between a tunnel’s derived from the destination IPv6 address. This feature overlay IPv6 routing state and the native IPv6 routing state. The attacks form routing loops which can be abused as a eliminates the need to keep an explicit routing table at vehicle for traffic amplification to facilitate DoS attacks. the tunnel’s end points. In particular, the end points do We exhibit five attacks of this class. One of the presented not have to be updated as peers join and leave the tunnel. attacks can DoS a Teredo server using a single packet. The In fact, the end points of an automatic tunnel do not exploited vulnerabilities are embedded in the design of the know which other end points are currently part of the tunnels; hence any implementation of these tunnels may be vulnerable.
    [Show full text]
  • Are We One Hop Away from a Better Internet?
    Are We One Hop Away from a Better Internet? Yi-Ching Chiu,∗ Brandon Schlinker,∗ Abhishek Balaji Radhakrishnan, Ethan Katz-Bassett, Ramesh Govindan Department of Computer Science, University of Southern California ABSTRACT of networks. A second challenge is that the goal is often an approach The Internet suffers from well-known performance, reliability, and that works in the general case, applicable equally to any Internet security problems. However, proposed improvements have seen lit- path, and it may be difficult to design such general solutions. tle adoption due to the difficulties of Internet-wide deployment. We We argue that, instead of solving problems for arbitrary paths, we observe that, instead of trying to solve these problems in the general can think in terms of solving problems for an arbitrary byte, query, case, it may be possible to make substantial progress by focusing or dollar, thereby putting more focus on paths that carry a higher on solutions tailored to the paths between popular content providers volume of traffic. Most traffic concentrates along a small number and their clients, which carry a large share of Internet traffic. of routes due to a number of trends: the rise of Internet video In this paper, we identify one property of these paths that may had led to Netflix and YouTube alone accounting for nearly half provide a foothold for deployable solutions: they are often very short. of North American traffic [2], more services are moving to shared Our measurements show that Google connects directly to networks cloud infrastructure, and a small number of mobile and broadband hosting more than 60% of end-user prefixes, and that other large providers deliver Internet connectivity to end-users.
    [Show full text]
  • Reverse Traceroute
    Reverse Traceroute Ethan Katz-Bassett, Harsha V. Madhyastha, Vijay K. Adhikari, Colin Scott, Justine Sherry, Peter van Wesep, Arvind Krishnamurthy, Thomas Anderson NSDI, April 2010 This work partially supported by Cisco, Google, NSF Researchers Need Reverse Paths, Too The inability to measure reverse paths was the biggest limitation of my previous systems: ! Geolocation constraints too loose [IMC ‘06] ! Hubble can’t locate reverse path outages [NSDI ‘08] ! iPlane predictions inaccurate [NSDI ‘09] Other systems use sophisticated measurements but are forced to assume symmetric paths: ! Netdiff compares ISP performance [NSDI ‘08] ! iSpy detects prefix hijacking [SIGCOMM ‘08] ! Eriksson et al. infer topology [SIGCOMM ʻ08] Everyone Needs Reverse Paths “The number one go-to tool is traceroute. Asymmetric paths are the number one plague. The reverse path itself is completely invisible.” NANOG Network operators troubleshooting tutorial, 2009. Goal: Reverse traceroute, without control of destination and deployable today without new support ! Want path from D back to S, don’t control D ! Traceroute gives S to D, but likely asymmetric ! Can’t use traceroute’s TTL limiting on reverse path KEY IDEA ! Technique does not require control of destination ! Want path from D back to S, don’t control D ! Set of vantage points KEY IDEA ! Multiple VPs combine for view unattainable from any one ! Traceroute from all vantage points to S ! Gives atlas of paths to S; if we hit one, we know rest of path " Destination-based routing KEY IDEA ! Traceroute atlas gives
    [Show full text]
  • Improving the Reliability of Internet Paths with One-Hop Source Routing
    Improving the Reliability of Internet Paths with One-hop Source Routing Krishna P. Gummadi, Harsha V. Madhyastha, Steven D. Gribble, Henry M. Levy, and David Wetherall Department of Computer Science & Engineering University of Washington {gummadi, harsha, gribble, levy, djw}@cs.washington.edu Abstract 1 Introduction Internet reliability demands continue to escalate as the Recent work has focused on increasing availability Internet evolves to support applications such as banking in the face of Internet path failures. To date, pro- and telephony. Yet studies over the past decade have posed solutions have relied on complex routing and path- consistently shown that the reliability of Internet paths monitoring schemes, trading scalability for availability falls far short of the “five 9s” (99.999%) of availability among a relatively small set of hosts. expected in the public-switched telephone network [11]. This paper proposes a simple, scalable approach to re- Small-scale studies performed in 1994 and 2000 found cover from Internet path failures. Our contributions are the chance of encountering a major routing pathology threefold. First, we conduct a broad measurement study along a path to be 1.5% to 3.3% [17, 26]. of Internet path failures on a collection of 3,153 Internet Previous research has attempted to improve Internet destinations consisting of popular Web servers, broad- reliability by various means, including server replica- band hosts, and randomly selected nodes. We monitored tion, multi-homing, or overlay networks. While effec- these destinations from 67 PlanetLab vantage points over tive, each of these techniques has limitations. For ex- a period of seven days, and found availabilities ranging ample, replication through clustering or content-delivery from 99.6% for servers to 94.4% for broadband hosts.
    [Show full text]
  • Hacking 802.11 Protocol Insecurities
    s e c u r I t y a n d p r I va c y a r e t W o c r I t- ical entities in any communication protocol. A d I t yA K s O O d Security itself is a prerequisite for robust implementation of networks. In this ar- ticle, I dissect the 802.11 [1] protocol attacks possible because of persistent problems in hacking 802.11 wireless networks. Before going into the attack patterns against the protocol, I will protocol insecurities briefly describe how 802.11 works by split- ting frames into functional objects. Aditya K Sood, a.k.a. 0kn0ck, is an independent security researcher and founder of SecNiche Security, a security research arena. He is a regular speaker at conferences such as XCON, OWASP, and CERT-IN. His other projects The protocol is constructed to work between ac- include Mlabs, CERA, and TrioSec. cess points and stations. Every second (unless dis- [email protected] abled), the access point transmits a signal in the form of wireless messages called beacons. The sta- tion listens for beacons on different frequencies called channels. Stations can also uses probe re- quest messages to scan a certain network for find- ing an access point. This probing and beaconing initiates the association between a station and an access point. An association message is used for initial connection by using a request/response mechanism. Similarly, a dissociation method is ap- plied for connection termination. The frames-based IEEE 802.11 Frame Format is used for sending data (Figure 1).
    [Show full text]
  • RIP: Routing Information Protocol a Routing Protocol Based on the Distance-Vector Algorithm
    Laboratory 6 RIP: Routing Information Protocol A Routing Protocol Based on the Distance-Vector Algorithm Objective The objective of this lab is to configure and analyze the performance of the Routing Information Protocol (RIP) model. Overview A router in the network needs to be able to look at a packet’s destination address and then determine which of the output ports is the best choice to get the packet to that address. The router makes this decision by consulting a forwarding table. The fundamental problem of routing is: How do routers acquire the information in their forwarding tables? Routing algorithms are required to build the routing tables and hence forwarding tables. The basic problem of routing is to find the lowest-cost path between any two nodes, where the cost of a path equals the sum of the costs of all the edges that make up the path. Routing is achieved in most practical networks by running routing protocols among the nodes. The protocols provide a distributed, dynamic way to solve the problem of finding the lowest-cost path in the presence of link and node failures and changing edge costs. One of the main classes of routing algorithms is the distance-vector algorithm. Each node constructs a vector containing the distances (costs) to all other nodes and distributes that vector to its immediate neighbors. RIP is the canonical example of a routing protocol built on the distance-vector algorithm. Routers running RIP send their advertisements regularly (e.g., every 30 seconds). A router also sends an update message whenever a triggered update from another router causes it to change its routing table.
    [Show full text]
  • Lab 2.8.1: Basic Static Route Configuration
    Lab 2.8.1: Basic Static Route Configuration Topology Diagram Addressing Table Device Interface IP Address Subnet Mask Default Gateway Fa0/0 172.16.3.1 255.255.255.0 N/A R1 S0/0/0 172.16.2.1 255.255.255.0 N/A Fa0/0 172.16.1.1 255.255.255.0 N/A R2 S0/0/0 172.16.2.2 255.255.255.0 N/A S0/0/1 192.168.1.2 255.255.255.0 N/A FA0/0 192.168.2.1 255.255.255.0 N/A R3 S0/0/1 192.168.1.1 255.255.255.0 N/A PC1 NIC 172.16.3.10 255.255.255.0 172.16.3.1 PC2 NIC 172.16.1.10 255.255.255.0 172.16.1.1 PC3 NIC 192.168.2.10 255.255.255.0 192.168.2.1 Learning Objectives Upon completion of this lab, you will be able to: • Cable a network according to the Topology Diagram. • Erase the startup configuration and reload a router to the default state. • Perform basic configuration tasks on a router. All contents are Copyright © 1992–2007 Cisco Systems, Inc. All rights reserved. This document is Cisco Public Information. Page 1 of 20 CCNA Exploration Routing Protocols and Concepts: Static Routing Lab 2.8.1: Basic Static Route Configuration • Interpret debug ip routing output. • Configure and activate Serial and Ethernet interfaces. • Test connectivity. • Gather information to discover causes for lack of connectivity between devices. • Configure a static route using an intermediate address.
    [Show full text]
  • The Impact of Rts/Cts Exchange on the Performance of Multi-Rate Ieee 802.11 Wireless Networks
    THE IMPACT OF RTS/CTS EXCHANGE ON THE PERFORMANCE OF MULTI-RATE IEEE 802.11 WIRELESS NETWORKS Yu-Jen Cheng Submitted to the faculty of the University Graduate School in partial fulfillment of the requirements for the degree Master of Science in the Department of Applied Mathematics and Computer Science Indiana University South Bend April 2008 Accepted by the Graduate Faculty, Indiana University South Bend, in partial fulfillment of the requirements for the degree of Master of Science Master’s Thesis Committee ______________________________ Chairperson, Liqiang Zhang, Ph.D. ______________________________ Yi Cheng, Ph.D. ______________________________ Dave Surma, Ph.D. Date of Oral Examination: March 28, 2008 ii ©2008 Yu-Jen Cheng All Rights Reserved iii Dedication This thesis is dedicated to my parents. They have supported me in my studies. iv Acknowledgments First of all, I would like to thank Dr. Liqiang Zhang for his support and encouragement. With the guidance from Dr. Zhang, I moved in the right direction toward finishing this thesis. Secondly, I would like to thank Dr. Yi Cheng and Dr. Dave Surma for their advice and feedback on this thesis. I would also like to thank all the faculty members and staff of Indiana University South Bend who have taught and helped me during my studying. Finally, I would like to thank my parents for their support and patience. v Abstract The RTS/CTS mechanism is an optional mechanism in DCF (Distributed Coordination Function) in IEEE 802.11 standard, which was designed to solve the hidden node problem. However, the RTS/CTS mechanism is turned off in most infrastructure- mode WLANs because the additional RTS/CTS frames exchange introduces transmission overhead.
    [Show full text]