scispace - formally typeset
Search or ask a question

Ad hoc On-Demand Distance Vector (AODV) Routing

TL;DR: A logging instrument contains a pulsed neutron source and a pair of radiation detectors spaced along the length of the instrument to provide an indication of formation porosity which is substantially independent of the formation salinity.
Abstract: The Ad hoc On-Demand Distance Vector (AODV) routing protocol is intended for use by mobile nodes in an ad hoc network. It offers quick adaptation to dynamic link conditions, low processing and memory overhead, low network utilization, and determines unicast routes to destinations within the ad hoc network. It uses destination sequence numbers to ensure loop freedom at all times (even in the face of anomalous delivery of routing control messages), avoiding problems (such as "counting to infinity") associated with classical distance vector protocols.

Content maybe subject to copyright    Report

Citations
More filters
Patent•
03 Apr 2009
TL;DR: In this article, improved capabilities are described for a mobile broadband routable internet (MBRI) providing for carrier-grade, networked, broadband, IP-routable communication among a plurality of mobile devices.
Abstract: In embodiments of the present invention improved capabilities are described for a mobile broadband routable internet (MBRI) providing for carrier-grade, networked, broadband, IP-routable communication among a plurality of mobile devices, where the mobile devices may represent a plurality of nodes that are linked together through a mobile ad-hoc network (MANET). Mobile devices may operate as peers in a peer-to-peer network, with full IP routing capabilities enabled within each mobile device, thereby allowing routing of IP-based traffic, including deployment of applications, to the mobile device without need for infrastructure conventionally required for mobile ad hoc networks, such as cellular telephony infrastructure. Full IP-routing to mobile devices may allow seamless integration to the fixed Internet, such as through fixed or mobile access points, such as for backhaul purposes. Thus, the MBRI may function as a standalone mobile Internet, without connection to the fixed Internet, or as an IP-routable extension of another network, whether it be the Internet, a local area network, a wide area network, a cellular network, a personal area network, or some other type of network that is capable of integration with an IP-based network.

434 citations

Patent•
21 Aug 2006
TL;DR: In this article, a method of providing network connectivity is presented, which can include introducing a new communication device within a communication range of a portable data collection device, the new communications device comprising a dynamic access module enabling the new communication devices to receive data packets from the portable Data Collection device and route payload data of the data packets to an access point.
Abstract: There is set forth herein a method of providing network connectivity. The method can include introducing a new communication device within a communication range of a portable data collection device, the new communication device comprising a dynamic access module enabling the new communication device to receive data packets from the portable data collection device and route payload data of the data packets to an access point. In one aspect the new communication device can receive data packets from the portable data collection device and route payload data of the data packets to the access point if the new communication device determines that it is in range of both of said access point and the portable data collection device. There is set forth herein a system having a dynamic access module.

432 citations

Journal Article•DOI•
Madanlal Musuvathi1, David Y. W. Park1, Andy Chou1, Dawson Engler1, David L. Dill1 •
09 Dec 2002
TL;DR: A new model checker, CMC, which checks C and C++ implementations directly, eliminating the need for a separate abstract description of the system behavior, and reduces missed errors as well as time-wasting false error reports resulting from inconsistencies between the abstract description and the actual implementation.
Abstract: Many system errors do not emerge unless some intricate sequence of events occurs. In practice, this means that most systems have errors that only trigger after days or weeks of execution. Model checking [4] is an effective way to find such subtle errors. It takes a simplified description of the code and exhaustively tests it on all inputs, using techniques to explore vast state spaces efficiently. Unfortunately, while model checking systems code would be wonderful, it is almost never done in practice: building models is just too hard. It can take significantly more time to write a model than it did to write the code. Furthermore, by checking an abstraction of the code rather than the code itself, it is easy to miss errors.The paper's first contribution is a new model checker, CMC, which checks C and C++ implementations directly, eliminating the need for a separate abstract description of the system behavior. This has two major advantages: it reduces the effort to use model checking, and it reduces missed errors as well as time-wasting false error reports resulting from inconsistencies between the abstract description and the actual implementation. In addition, changes in the implementation can be checked immediately without updating a high-level description.The paper's second contribution is demonstrating that CMC works well on real code by applying it to three implementations of the Ad-hoc On-demand Distance Vector (AODV) networking protocol [7]. We found 34 distinct errors (roughly one bug per 328 lines of code), including a bug in the AODV specification itself. Given our experience building systems, it appears that the approach will work well in other contexts, and especially well for other networking protocols.

432 citations

Book•
01 Jan 2010
TL;DR: Interconnecting Smart Objects with IP is the first book that takes a holistic approach to the revolutionary area of IP-based smart objects, offering an in-depth examination of relevant IP protocols to build large scale smart object networks in support of a myriad of new services.
Abstract: Smart object technology, sometimes called the Internet of Things, is having a profound impact on our day-to-day lives. Interconnecting Smart Objects with IP is the first book that takes a holistic approach to the revolutionary area of IP-based smart objects. Smart objects are the intersection of networked embedded systems, wireless sensor networks, ubiquitous and pervasive computing, mobile telephony and telemetry, and mobile computer networking. This book consists of three parts, Part I focuses on the architecture of smart objects networking, Part II covers the hardware, software, and protocols for smart objects, and Part III provides case studies on how and where smart objects are being used today and in the future. The book covers the fundamentals of IP communication for smart objects, IPv6, and web services, as well as several newly specified low-power IP standards such as the IETF 6LoWPAN adaptation layer and the RPL routing protocol. This book contains essential information not only for the technical reader but also for policy makers and decision makers in the area of smart objects both for private IP networks and the Internet. Shows in detail how connecting smart objects impacts our lives with practical implementation examples and case studies Provides an in depth understanding of the technological and architectural aspects underlying smart objects technology Offers an in-depth examination of relevant IP protocols to build large scale smart object networks in support of a myriad of new services Table of Contents Part I: The Architecture Chapter 1: What are Smart objects? Chapter 2: The IP protocol architecture Chapter 3: Why IP for smart objects? Chapter 4: IPv6 for Smart Object Networks and The Internet of Things Chapter 5: Routing Chapter 6: Transport Protocols Chapter 7: Service Discovery Chapter 8: Security for Smart Objects Chapter 9: Web services For Smart Objects Chapter 10: Connectivity models for smart object networks Part II: The Technology Chapter 11: What is a Smart Object? Chapter 12: Low power link layer for smart objects networks Chapter 13: uIP A Lightweight IP Stack Chapter 14: Standardization Chapter 15: IPv6 for Smart Object Networks - A Technology Refresher Chapter 16: The 6LoWPAN Adaptation Layer Chapter 17: RPL Routing in Smart Object Networks Chapter 18: The IPSO Alliance Chapter 19: Non IP Technology Part III: The Applications Chapter 20: Smart Grid Chapter 21: Industrial Automation Chapter 22: Smart Cities and Urban Networks Chapter 23: Home Automation Chapter 24: Building Automation Chapter 25: Structural Health Monitoring Chapter 26: Container Tracking

429 citations

Proceedings Article•
01 Jan 2003
Abstract: Smart sensors are small wireless computing devices that sense information such as light and humidity at extremely high resolutions. A smart sensor query-processing architecture using database technology can facilitate deployment of sensor networks. Smart-sensor technology enables a broad range of ubiquitous computing applications. Their low cost, small size, and untethered nature lets them sense information at previously unobtainable resolutions. We discuss about query processing in sensor networks.

426 citations

References
More filters
01 Mar 1997
TL;DR: This document defines these words as they should be interpreted in IETF documents as well as providing guidelines for authors to incorporate this phrase near the beginning of their document.
Abstract: In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:

3,501 citations

12 Nov 2001
TL;DR: In this article, a logging instrument contains a pulsed neutron source and a pair of radiation detectors spaced along the length of the instrument to provide an indication of formation porosity which is substantially independent of the formation salinity.
Abstract: A logging instrument contains a pulsed neutron source and a pair of radiation detectors spaced along the length of the instrument. The radiation detectors are gated differently from each other to provide an indication of formation porosity which is substantially independent of the formation salinity. In the preferred embodiment, the electrical signals indicative of radiation detected by the long-spaced detector are gated for almost the entire interval between neutron pulses and the short-spaced signals are gated for a significantly smaller time interval which commences soon after the termination of a given neutron burst. The signals from the two detectors are combined in a ratio circuit for determination of porosity.

574 citations

01 Jan 1998
TL;DR: In this article, the authors discuss issues that should be considered in formulating a policy for assigning values to a name space and provide guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.
Abstract: Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA). In order for the IANA to manage a given name space prudently, it needs guidelines describing the conditions under which new values can be assigned. If the IANA is expected to play a role in the management of a name space, the IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a name space and provides guidelines to document authors on the specific text that must be included in documents that place demands on the IANA.

536 citations

01 Oct 1998
TL;DR: Many protocols make use of identifiers consisting of constants and other well-known values that must be administered by a central authority to insure that such quantities have consistent values and interpretations in different implementations.
Abstract: Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication algorithm for IPSec). To insure that such quantities have consistent values and interpretations in different implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).

334 citations

01 Jun 2004
TL;DR: This document defines terms for mobility related terminology out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks.
Abstract: There is a need for common definitions of terminology in the work to be done around IP mobility. This document defines terms for mobility related terminology. The document originated out of work done in the Seamoby Working Group but has broader applicability for terminology used in IETF-wide discourse on technology for mobility and IP networks. Other working groups dealing with mobility may want to take advantage of this terminology. This memo provides information for the Internet community.

207 citations


"Ad hoc On-Demand Distance Vector (A..." refers methods in this paper

  • ...This section defines other terminology used with AODV that is not already defined in [3]....

    [...]