DOCSLIB.ORG

An Experimental Evaluation of Hamnet Characteristics

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Experimental Evaluation of Hamnet Characteristics An Experimental Evaluation of HAMnet Characteristics Tobias DB1QP September 2017 Abstract The European Highspeed Amateur Radio Multimedia Network (HAMNET) is an IP network operated independently of the internet by and for radio amateurs using primarily directional radio links. After a short introduction to amateur radio, packet radio, and the HAMNET project and community, the structure of the HAMNET is examined and compared to other existing networks. Next, the design and implementation of a measurement system based on data collected by active measurement probes at several points in the network is described. Finally, the data collected by this system, as well as passive data collected from a subset of hosts in the network, are analyzed to explore the network structure, its behavior and capacity. Contents 1 Introduction 1 1.1 Radio Modes . 1 1.1.1 Packet Radio . 2 1.2 AMPRNet . 2 2 The European HAMNET 4 2.1 Structure . 4 2.1.1 Hardware . 5 2.2 Routing . 5 2.3 Services . 5 2.3.1 Domain Names . 5 2.3.2 Other Services . 6 2.4 Comparison to Other Large-scale Internetworks . 6 2.4.1 Mobile Networks . 6 2.4.2 The Internet . 8 3 Measurements and Metrics 9 3.1 Characteristics . 9 3.2 Existing Studies and Tools . 9 3.2.1 HAMNET Surveys . 10 3.3 Existing Measurement Tools . 10 3.3.1 Nagios . 10 3.3.2 RIPE ATLAS . 10 3.4 Passive Data Collection . 11 3.4.1 Structural Data . 11 3.4.2 Site Information . 11 3.5 Active Measurement System . 11 3.5.1 Coordinator . 13 3.5.2 Probes . 13 3.5.3 Measurements . 14 4 Measurement Results and Analysis 18 4.1 Passive Collection . 18 4.1.1 Census . 19 4.2 Network Trace . 20 4.2.1 ICMP Codes . 21 4.2.2 Errors . 22 4.2.3 Analysis . 23 4.3 Path Measurement . 24 4.3.1 DB0FC-DO4BZ Path........................... 24 4.3.2 DF0HSA-DB0ZM Path . 26 5 Conclusions 28 6 Future Work 29 6.1 Further Research . 29 6.2 Improving the HAMProbe System . 29 6.2.1 Volunteer Experience . 30 6.2.2 Measurements . 30 6.2.3 Administration . 30 6.2.4 Resource Management . 30 6.2.5 Testing . 31 6.3 Integration with Existing Systems . 31 Appendices A Routes 1 Introduction The International Telecommunication Union's Radio Regulations have, since their inception, included provisions for the amateur service, defined as: \A radiocommunication service for the purpose of self-training, intercommu- nication and technical investigations carried out by amateurs, that is, by duly authorized persons interested in radio technique solely with a personal aim and without pecuniary interest." [1] Amateur radio is, essentially, a hobby. The licensing requirements are usually im- plemented in a standardized exam, resulting in the issue of a certificate and a license, including the assignment of a personal call sign.1 Such duly authorized persons, called radio amateurs or Hams2, are further permitted to build, modify and operate radio equipment on the frequencies allocated to the amateur radio service, within the regulatory restrictions. 1.1 Radio Modes Different \modes" can be used to communicate via radio. Transmissions like voice or Slow scan television (SSTV) are commonly transmitted using the analog modes Ampli- tude Modulation (AM)/Single Sideband Modulation (SSB) and Frequency Modulation (FM). To extend the range of such communications, Hams operate repeater systems which can be "opened" by sending a pre-defined tone on an input frequency, and which will then \relay" the signal from the input frequency to an output frequency (usually above the input frequency by an offset). Radio contacts can also be conducted using digital modes. The prime example of a digital mode is, of course, Morse code, which is encoded by toggling a continuous carrier wave on and off at specific intervals (“on-off keying")3. Some other popular digital modes include Radioteletype (RTTY) and PSK31, which are used for text transmissions. 1These international regulations are implemented by the participating nations in national laws. As the author is licensed as a German radio amateur, the laws referenced will be those of the Federal Republic of Germany, specifically the Gesetz ¨uber den Amateurfunk (AFuG)[2] and Verordnung zum Gesetz ¨uber den Amateurfunk (AFuV)[3]. 2The origin of this term is not certain[4] 3This mode is also referred to as Continuous Wave (CW) 1 Digital modes are especially useful for automatic stations like mailboxes or digipeaters, where computer systems with a modem can perform services like storing messages or repeating without requiring a human operator's attention. The International Amateur Radio Union (IARU) band plans contain recommenda- tions for the use of amateur radio bands; specifically, which areas should be used for which types of radio mode. Nearly every band contains some frequencies explicitly rec- ommended for digital modes, and the 30 m band is exclusively digital[5]. New digital modes are still being developed today. A recent 2017-07-11 release of the Weak Signal Communication Software (WSJT-X) includes a new digital mode called FT8[6], which is specifically designed to enable low-power communications over long distances. 1.1.1 Packet Radio All the aforementioned digital modes require the communicating parties to informally "reserve" a frequency channel that is not already in use for the duration of their radio contact. Channel management is not explicitly part of these modes. To alleviate the difficulty of coordinating multiple communicating parties on a single channel, the concept of packet radio was developed. By not transmitting complete messages all at once or in real time, but by splitting them into small packets that can be sent in short bursts, multiple stations can share the same channel by alternating their transmissions.4 The first packet radio repeater in the United States was established in 1980.[7] A special protocol for packet radio called \AX.25" was developed for amateur radio by the Tucson Amateur Packet Radio Corporation, the latest version of which was published in 1997[8]. AX.25 includes mechanisms to detect and recover from collisions. The Linux kernel has included native support for this link-layer protocol since version 2.0[9]. AX.25 is still used today in the Automatic Packet Reporting System (APRS). 1.2 AMPRNet In July 1992, the American Registry for Internet Numbers (ARIN) allocated the IPv4 block 44.0.0.0/8 to the Amateur Radio Digital Communications (ARDC) organiza- tion[10], though other sources claim this address space was already allocated in the 1980s[11]. This block is today used world-wide for the Amateur Packet Radio Network 4Collision detection and avoidance schemes to prevent or handle more than one station transmitting at the same time are outside of the scope of this introduction. 2 (AMPRNet), also known as 44net. Subnets of this block are assigned to volunteer re- gional coordinators[12], who in turn manage allocation within their countries/regions. The amateur radio bands include (in ITU region 1) the 2:40 GHz{2:45 GHz range, which is typically also used for WiFi[13]. Unlike other WiFi users, amateur radio op- erators have the right to modify their transmitter hardware, including modifications to transmit with up to 75 W Peak envelope power (PEP), as opposed to the consumer hardware limit of 100 mW Equivalent isotropically radiated power (EIRP)5[13]. 5PEP measures the peak power output by a transmitter, regardless of antenna qualities. A station limited in EIRP may not radiate more power in any direction than the idealized isotropic radiator would at the same input power. As a result, when limited by PEP, one can always try to improve ones antenna; when limited by EIRP, improving the antenna leads to possibly having to turn down the transceiver power. 3 2 The European HAMNET The effort by radio amateurs to build a global AMPRNet using the 44.0.0.0/8 IPv4 address space is coordinated by the ARDC. In Germany, the relevant network resource management is coordinated by the German IP Coordination Team. This central Euro- pean regional subset of the AMPRNet is locally referred to as the Highspeed Amateur Radio Multimedia Network (HAMNET). This survey exclusively examines the HAMNET, the structure of which is described with excellent coverage in the HAMNET Database (HAMNETDB)[14]. The HAM- NETDB project collects and publishes information about HAMNET stations and their link topology and plays a central role in the administration of the HAMNET. It also provides a convenient map visualization. This database changes quite frequently as new sites are added or configurations are changed. A snapshot can be generated and downloaded at any point in time. Not all links are stored in the database; for a complete overview of all links as shown on the map, it is necessary to call a script provided by the HAMNETDB website1. The analyses in this survey are based on a database snapshot and link list generated on 17. September 2017. 2.1 Structure The link topology of any packet-switched network can be expressed as a graph, with routers as vertices, and their links (wired or wireless) as edges. The HAMNETDB currently contains some 1057 sites and 1040 links[14]. The primary goal of the HAMNET, of course, is to interconnect amateur radio sites by directional radio links[15]. Where radio links are not possible, due to unfitting terrain, location, lack of equipment or setting, or other difficulties, connections to other (even very remote) sites can be established by other means, such as Ethernet or virtual point- to-point connections (e.g. Virtual Private Networks (VPNs)). 1https://hamnetdb.net/mapelements.cgi 4 2.1.1 Hardware Theoretically, any IP-capable hardware that can connect to existing sites in the HAM- NET, via amateur radio or any other means, is able to join the network.
Load more

Recommended publications
  • IP Datagram ICMP Message Format ICMP Message Types
    ICMP Internet Control Message Protocol ICMP is a protocol used for exchanging control messages. CSCE 515: Two main categories Query message Computer Network Error message Programming Usage of an ICMP message is determined by type and code fields ------ IP, Ping, Traceroute ICMP uses IP to deliver messages. Wenyuan Xu ICMP messages are usually generated and processed by the IP software, not the user process. Department of Computer Science and Engineering University of South Carolina IP header ICMP Message 20 bytes CSCE515 – Computer Network Programming IP Datagram ICMP Message Format 1 byte 1 byte 1 byte 1 byte VERS HL Service Total Length Datagram ID FLAG Fragment Offset 0781516 31 TTL Protocol Header Checksum type code checksum Source Address Destination Address payload Options (if any) Data CSCE515 – Computer Network Programming CSCE515 – Computer Network Programming ICMP Message Types ICMP Address Mask Request and Reply intended for a diskless system to obtain its subnet mask. Echo Request Id and seq can be any values, and these values are Echo Response returned in the reply. Destination Unreachable Match replies with request Redirect 0781516 31 Time Exceeded type(17 or 18) code(0) checksum there are more ... identifier sequence number subnet mask CSCE515 – Computer Network Programming CSCE515 – Computer Network Programming ping Program ICMP Echo Request and Reply Available at /usr/sbin/ping Test whether another host is reachable Send ICMP echo_request to a network host -n option to set number of echo request to send
    [Show full text]
  • Transport Layer Chapter 6
    Transport Layer Chapter 6 • Transport Service • Elements of Transport Protocols • Congestion Control • Internet Protocols – UDP • Internet Protocols – TCP • Performance Issues • Delay-Tolerant Networking Revised: August 2011 CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011 The Transport Layer Responsible for delivering data across networks with the desired Application reliability or quality Transport Network Link Physical CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011 Transport Service • Services Provided to the Upper Layer » • Transport Service Primitives » • Berkeley Sockets » • Socket Example: Internet File Server » CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011 Services Provided to the Upper Layers (1) Transport layer adds reliability to the network layer • Offers connectionless (e.g., UDP) and connection- oriented (e.g, TCP) service to applications CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011 Services Provided to the Upper Layers (2) Transport layer sends segments in packets (in frames) Segment Segment CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice Hall and D. Wetherall, 2011 Transport Service Primitives (1) Primitives that applications might call to transport data for a simple connection-oriented service: • Client calls CONNECT, SEND, RECEIVE, DISCONNECT • Server calls LISTEN, RECEIVE, SEND, DISCONNECT Segment CN5E by Tanenbaum & Wetherall, © Pearson Education-Prentice
    [Show full text]
  • Evaluating Lora Physical As a Radio Link Technology for Use in a Remote-Controlled Electric Switch System for a Network Bridge
    Evaluating LoRa Physical as a Radio Link Technology for use in a Remote-Controlled Electric Switch System for a Network Bridge Radio-Node Abdullahi Aden Hassan / Rasmus Karlsson Källqvist KTH ROYAL INSTITUTE OF TECHNOLOGY ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Acknowledgments We would like to thank our academic mentor Anders Västberg for helping us with the process of writing and carrying through this degree project, answering all of our questions, and for proof reading this report. We would like to thank Amin Azari for showing genuine interest in our project and for answering some math questions we had when calculating the radio link budget, and for discovering that the formula in a book we were using had a printing error which was initially causing our results to be wrong. Thank you to fellow students Michael Henriksson and Sebastian Kullengren for a thorough opposition to this report and for much helpful feedback in keeping the text readable and scientific. Thank you to Björn Pehrson for representing AMPRNet Sweden and giving us the opportunity to work on this project, financing the system prototype and for giving helpful feedback. Finally, we would like to thank program director Bengt Molin for teaching us much of what we know of embedded systems and for lending us equipment used in the development of the hardware prototype. i Abstract This report explores the design of a system for remotely switching electronics on and off within a range of at least 15 km, to be used with battery driven radio nodes for outdoor Wi-Fi network bridging. The application of the network bridges are connecting to remote networks, should Internet infrastructure fail during an emergency.
    [Show full text]
  • Internet Protocol Suite
    InternetInternet ProtocolProtocol SuiteSuite Srinidhi Varadarajan InternetInternet ProtocolProtocol Suite:Suite: TransportTransport • TCP: Transmission Control Protocol • Byte stream transfer • Reliable, connection-oriented service • Point-to-point (one-to-one) service only • UDP: User Datagram Protocol • Unreliable (“best effort”) datagram service • Point-to-point, multicast (one-to-many), and • broadcast (one-to-all) InternetInternet ProtocolProtocol Suite:Suite: NetworkNetwork z IP: Internet Protocol – Unreliable service – Performs routing – Supported by routing protocols, • e.g. RIP, IS-IS, • OSPF, IGP, and BGP z ICMP: Internet Control Message Protocol – Used by IP (primarily) to exchange error and control messages with other nodes z IGMP: Internet Group Management Protocol – Used for controlling multicast (one-to-many transmission) for UDP datagrams InternetInternet ProtocolProtocol Suite:Suite: DataData LinkLink z ARP: Address Resolution Protocol – Translates from an IP (network) address to a network interface (hardware) address, e.g. IP address-to-Ethernet address or IP address-to- FDDI address z RARP: Reverse Address Resolution Protocol – Translates from a network interface (hardware) address to an IP (network) address AddressAddress ResolutionResolution ProtocolProtocol (ARP)(ARP) ARP Query What is the Ethernet Address of 130.245.20.2 Ethernet ARP Response IP Source 0A:03:23:65:09:FB IP Destination IP: 130.245.20.1 IP: 130.245.20.2 Ethernet: 0A:03:21:60:09:FA Ethernet: 0A:03:23:65:09:FB z Maps IP addresses to Ethernet Addresses
    [Show full text]
  • The Internet Protocol, Version 4 (Ipv4)
    Today’s Lecture I. IPv4 Overview The Internet Protocol, II. IP Fragmentation and Reassembly Version 4 (IPv4) III. IP and Routing IV. IPv4 Options Internet Protocols CSC / ECE 573 Fall, 2005 N.C. State University copyright 2005 Douglas S. Reeves 1 copyright 2005 Douglas S. Reeves 2 Internet Protocol v4 (RFC791) Functions • A universal intermediate layer • Routing IPv4 Overview • Fragmentation and reassembly copyright 2005 Douglas S. Reeves 3 copyright 2005 Douglas S. Reeves 4 “IP over Everything, Everything Over IP” IP = Basic Delivery Service • Everything over IP • IP over everything • Connectionless delivery simplifies router design – TCP, UDP – Dialup and operation – Appletalk – ISDN – Netbios • Unreliable, best-effort delivery. Packets may be… – SCSI – X.25 – ATM – Ethernet – lost (discarded) – X.25 – Wi-Fi – duplicated – SNA – FDDI – reordered – Sonet – ATM – Fibre Channel – Sonet – and/or corrupted – Frame Relay… – … – Remote Direct Memory Access – Ethernet • Even IP over IP! copyright 2005 Douglas S. Reeves 5 copyright 2005 Douglas S. Reeves 6 1 IPv4 Datagram Format IPv4 Header Contents 0 4 8 16 31 •Version (4 bits) header type of service • Functions version total length (in bytes) length (x4) prec | D T R C 0 •Header Length x4 (4) flags identification fragment offset (x8) 1. universal 0 DF MF s •Type of Service (8) e time-to-live (next) protocol t intermediate layer header checksum y b (hop count) identifier •Total Length (16) 0 2 2. routing source IP address •Identification (16) 3. fragmentation and destination IP address reassembly •Flags (3) s •Fragment Offset ×8 (13) e t 4. Options y IP options (if any) b •Time-to-Live (8) 0 4 ≤ •Protocol Identifier (8) s e t •Header Checksum (16) y b payload 5 •Source IP Address (32) 1 5 5 6 •Destination IP Address (32) ≤ •IP Options (≤ 320) copyright 2005 Douglas S.
    [Show full text]
  • New Gateways (PDF
    Packet Network Notice Rev: 28-Nov-2011 Date: Nov 28, 2011 From: Santa Clara County ARES/RACES Packet Committee Subject: Packet Network Update – New AMPRnet and E-mail gateways Attention: All ECs, AECs, MACs and other Santa Clara County Packet Users This Packet Network Notice contains important information which affects your ability to access and use the county packet backbone. This update covers the following topics: • New AMPRnet Gateway • New E-mail Gateway Please read this information thoroughly and pass along to any packet users in your local area. New AMPRnet Gateway The AMPRnet is an AMateur Packet Radio network consisting of packet radio BBSs located worldwide. Local networks of BBSs are interconnected to other local networks through gateways. These gateways use IP-in-IP tunnels to connect to each other. AMPRnet IP addresses are allocated from the IP address block of 44.0.0.0/8. Once a BBS or local network of BBSs is connected to AMPRnet, each of the BBSs can reach any other BBS on the AMPRnet, and vice-versa. For example, in the State of Michigan, each county has a local network of one or more BBSs. Each county is connected to all other counties (and to the rest of the world) with AMPRnet connections. Here in California, we can use AMPRnet connections to reach other counties which do not have a radio path to our network. We have just started to reach out to other counties to work on making those connections. There are two primary uses for this connectivity: 1) Messaging: Messages can now be addressed to anyone at any of the AMPRnet BBSs with a simple and standard Internet-style address format: [email protected].
    [Show full text]
  • Sistemas Informáticos Curso 2005-06 Sistema De Autoconfiguración Para
    Sistemas Informáticos Curso 2005-06 Sistema de Autoconfiguración para Redes Ad Hoc Miguel Ángel Tolosa Diosdado Adam Ameziane Dirigido por: Profª. Marta López Fernández Dpto. Sistemas Informáticos y Programación Grupo de Análisis, Seguridad y Sistemas (GASS) Facultad de Informática Universidad Complutense de Madrid AGRADECIMIENTOS: Queremos agradecer la dedicación de la profesora Marta López Fernández, Directora del presente Proyecto de Sistemas Informáticos, y del resto de integrantes del Grupo de Análisis, Seguridad y Sistemas (GASS) del Departamento de Sistemas Informáticos y Programación de la Universidad Complutense de Madrid, y de forma muy especial a Fabio Mesquita Buiati y a Javier García Villalba, Miembro y Director del citado Grupo, respectivamente, por el asesoramiento y las facilidades proporcionadas para el buen término de este Proyecto. 2 Índice RESUMEN ....................................................................................................................... 5 ABSTRACT ..................................................................................................................... 6 PALABRAS CLAVE....................................................................................................... 7 1-INTRODUCCIÓN....................................................................................................... 8 1.1- MOTIVACIÓN ......................................................................................................... 8 1.2 – OBJETIVO .............................................................................................................
    [Show full text]
  • The Original Version of This Chapter Was Revised: the Copyright Line Was Incorrect
    The original version of this chapter was revised: The copyright line was incorrect. This has been corrected. The Erratum to this chapter is available at DOI: 10.1007/978-0-387-35516-0_20 H. Ural et al. (eds.), Testing of Communicating Systems © IFIP International Federation for Information Processing 2000 114 TESTING OF COMMUNICATING SYSTEMS protocols in TTCN mainly by ETSI and ITU-T. Most of the telecom vendor companies use TTCN in their internal test procedures because of its usefulness in protocol testing. Tools exist supporting the writing and execution of TTCN test cases as well as generating them from formal specifications written in SDL (Specification Description Language) or MSC (Message Sequence Chart). Telecom service providers are also executing conformance testing on the products they buy to check if it fulfills the requirements described in the protocol standards. This is a main step assuring the interoperability of the heterogeneous products built in their network. In the datacom world this kind of strict testing is not applied though interoperability of products of different vendors is becoming to be as important as for telecom networks with the growing number of datacom product vendors and the growing reliability requirements. The interoperability events use ad hoc test scenarios, and no test results are really available for the potential customers to support their decision which product to buy. This paper presents an application of the conformance testing methodology on IPv6 testing. In section two we present the main features of IPv6. Section 3 summarizes ideas why conformance testing would be useful for the Internet protocols.
    [Show full text]
  • Mind the Uppercase Letters
    Integration of APRS Network with SDI Tomasz Kubik1,2, Wojciech Penar1 1 Wroclaw University of Technology 2 Wroclaw University of Environmental and Life Sciences Abstract. From the point of view of large information systems designers the most important thing is a certain abstraction enabling integration of heterogeneous solutions. Abstraction is associated with the standardization of protocols and interfaces of appropriate services. Behind this façade any device or sensor system may be hidden, even humans recording their measurements. This study presents selected topics and details related to two families of standards developed by OGC: OpenLS and SWE. It also dis- cusses the technical details of a solution built to intercept radio messages broadcast in the APRS network with telemetric information and weather conditions as payload. The basic assumptions and objectives of a prototype system that integrates elements of the APRS network and SWE are given. Keywords: SWE, OpenLS, APRS, SDI, web services 1. Introduction Modern measuring devices are no longer seen as tools for qualitative and quantitative measurements only. They have become parts of highly special- ized solutions, used for data acquisition and post-processing, offering hardware and software interfaces for communication. In the construction of these solutions the latest technologies from various fields are employed, including optics, precision mechanics, satellite and information technolo- gies. Thanks to the Internet and mobile technologies, several architectural and communication barriers caused by the wiring and placement of the sensors have been broken. Only recently the LBS (Location-Based Services) entered the field of IT. These are information services, available from mo- bile devices via mobile networks, giving possibility of utilization of a mobile This work was supported in part by the Polish Ministry of Science and Higher Edu- cation with funds for research for the years 2010-2013.
    [Show full text]
  • Linux Networking-HOWTO
    Linux Networking−HOWTO: Linux Networking−HOWTO: Table of Contents Linux Networking−HOWTO:............................................................................................................................1 Author: Joshua Drake poet@linuxports.com...........................................................................................1 1.Introduction...........................................................................................................................................1 2.Document History.................................................................................................................................1 3.How to use this HOWTO......................................................................................................................1 4.General Information about Linux Networking.....................................................................................1 5.Generic Network Configuration Information.......................................................................................1 6.Ethernet Information.............................................................................................................................2 7.IP Related Information..........................................................................................................................2 8.Advanced Networking with Kernel 2.2................................................................................................2 9.Using common PC hardware................................................................................................................2
    [Show full text]
  • 14. TCP/IP Protocol Suite Contents
    11/10/2010 14. TCP/IP Protocol Suite Contents a. TCP/IP – Internet – OSI b. Network level – IP protocol c. Addressing and sub-networks d. Other network-level protocols e. Transport level 1 11/10/2010 a. TCP/IP – Internet – OSI b. Network level – IP protocol 2 11/10/2010 Position of IPv4 in TCP/IP protocol suite IPv4 datagram format 3 11/10/2010 Service type or differentiated services The precedence subfield was part of version 4, but never used. 4 11/10/2010 Types of service Default types of service 5 11/10/2010 Values for codepoints The total length field defines the total length of the datagram including the header. 6 11/10/2010 Encapsulation of a small datagram in an Ethernet frame Protocol field and encapsulated data 7 11/10/2010 Protocol values Example 1 An IPv4 packet has arrived with the first 8 bits as shown: 01000010 Thereceiver discar ds the packtket. Why? Solution There is an error in this packet. The 4 leftmost bits (0100) show the version, which is correct. The next 4 bits (0010) show an invalid header length (2 × 4 = 8). The minimum number of bytes in the header must be 20. The packet has been corrupted in transmission. 8 11/10/2010 Example 2 In an IPv4 packet, the value of HLEN is 1000 in binary. How many bytes of options are being carried by this packet? Solution The HLEN value is 8, which means the total number of bytes in the header is 8 × 4, or 32 bytes. The first 20 bytes are the base header, the next 12 bytes are the options.
    [Show full text]
  • Ad Hoc Networks – Design and Performance Issues
    HELSINKI UNIVERSITY OF TECHNOLOGY Department of Electrical and Communications Engineering Networking Laboratory UNIVERSIDAD POLITECNICA´ DE MADRID E.T.S.I. Telecomunicaciones Juan Francisco Redondo Ant´on Ad Hoc Networks – design and performance issues Thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Telecommunications Engineering Espoo, May 2002 Supervisor: Professor Jorma Virtamo Abstract of Master’s Thesis Author: Juan Francisco Redondo Ant´on Thesis Title: Ad hoc networks – design and performance issues Date: May the 28th, 2002 Number of pages: 121 Faculty: Helsinki University of Technology Department: Department of Electrical and Communications Engineering Professorship: S.38 – Networking Laboratory Supervisor: Professor Jorma Virtamo The fast development wireless networks have been experiencing recently offers a set of different possibilities for mobile users, that are bringing us closer to voice and data communications “anytime and anywhere”. Some outstanding solutions in this field are Wireless Local Area Networks, that offer high-speed data rate in small areas, and Wireless Wide Area Networks, that allow a greater mobility for users. In some situations, like in military environment and emergency and rescue operations, the necessity of establishing dynamic communications with no reliance on any kind of infrastructure is essential. Then, the ease of quick deployment ad hoc networks provide becomes of great usefulness. Ad hoc networks are formed by mobile hosts that cooperate with each other in a distributed way for the transmissions of packets over wireless links, their routing, and to manage the network itself. Their features condition their design in several network layers, so that parameters like bandwidth or energy consumption, that appear critical in a multi-layer design, must be carefully taken into account.
    [Show full text]