WO2002084956A1 - Protocole de routage de reseaux ad hoc mobiles generaux - Google Patents

Protocole de routage de reseaux ad hoc mobiles generaux Download PDF

Info

Publication number
WO2002084956A1
WO2002084956A1 PCT/SG2001/000064 SG0100064W WO02084956A1 WO 2002084956 A1 WO2002084956 A1 WO 2002084956A1 SG 0100064 W SG0100064 W SG 0100064W WO 02084956 A1 WO02084956 A1 WO 02084956A1
Authority
WO
WIPO (PCT)
Prior art keywords
route
node
routing protocol
rreq
protocol according
Prior art date
Application number
PCT/SG2001/000064
Other languages
English (en)
Inventor
Luying Zhou
Radhakrishna Pillai Raghavan Pillai
Sek Yuen Pat Chan
Original Assignee
Kent Ridge Digital Labs
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Kent Ridge Digital Labs filed Critical Kent Ridge Digital Labs
Priority to PCT/SG2001/000064 priority Critical patent/WO2002084956A1/fr
Publication of WO2002084956A1 publication Critical patent/WO2002084956A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/26—Route discovery packet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/36—Backward learning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/246—Connectivity information discovery
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/248—Connectivity information update
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W40/00—Communication routing or communication path finding
    • H04W40/24—Connectivity information management, e.g. connectivity discovery or connectivity update
    • H04W40/28—Connectivity information management, e.g. connectivity discovery or connectivity update for reactive routing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/16—Discovering, processing access restriction or access information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W84/00—Network topologies
    • H04W84/18—Self-organising networks, e.g. ad-hoc networks or sensor networks

Definitions

  • the present invention relates to mobile ad hoc networks, and more particularly to a routing protocol for use in mobile ad hoc networks with symmetric and/or asymmetric links which uses route discovery and table lookup mechanisms.
  • a mobile ad hoc network is a collection of wireless mobile nodes dynamically forming a network without the use of any existing network infrastructure.
  • a MANET there is no predetermined topology or central controller, and the MANET does not rely on a pre-existing fixed infrastructure, such as a wireline backbone network or a base station.
  • the responsibilities for organizing and controlling the network are distributed among the nodes themselves.
  • the entire network is mobile, and the individual nodes are allowed to move at will relative to each other.
  • Each mobile node in the MANET operates not only as a host but also as a router, as some pairs of nodes may not be able to communicate directly with each other and may require other nodes to relay packets.
  • MANETs typically have one or more of the following characteristics:
  • Asymmetric (unidirectional) links An asymmetric link is caused by interference, differing radio or antenna capabilities, or adjustment of transmission and reception parameters such as power.
  • An asymmetric link allows transmission between nodes in one direction only, while a symmetric link allows bidirectional transmission between the linked nodes.
  • Nodes are unable to form a subnet or to have subnet addresses.
  • Energy-constrained operation Some or all of the nodes in a MANET may rely on batteries for energy. For these nodes, power conservation is a critical design criterion.
  • Mobile wireless networks are generally more prone to information and physical security threats than fixed, hardwired nets.
  • MANETs can be used in military, rescue, and emergency applications, where either there is no other wireless communication infrastructure present or such infrastructure cannot be used because of security, cost, or safety reasons. MANETs can also operate as robust and inexpensive alternatives or enhancements of cell- based mobile network infrastructures.
  • MANET technology may be used to extend the range of Wireless Local Area Network (WLAN) technology over multiple radio hops.
  • WLAN Wireless Local Area Network
  • WLAN technologies such as HiperLAN and IEEE802.i l.
  • People and vehicles can thus be inter-networked in areas without a pre-existing communication infrastructure, or when the use of such infrastructure further requires extension by wireless means.
  • technologies such as BluetoothTM (a radio interface using the 2.45GHz Industrial, Scientific, and Medical (ISM) frequency band, mainly used to offer short-range (-10 meters) data transmission via low-cost radio frequency modules and low power consumption) can be exploited in interesting ways to build embedded wireless networks.
  • BluetoothTM a radio interface using the 2.45GHz Industrial, Scientific, and Medical (ISM) frequency band, mainly used to offer short-range (-10 meters) data transmission via low-cost radio frequency modules and low power consumption
  • end user devices such as host computers or telephones
  • they are assigned addresses based on their location in a fixed network-addressing hierarchy and often assume an identity equivalent to their address.
  • This identity-location equivalence greatly simplifies routing in these systems, as a user's location does not change.
  • the routing infrastructure can move along with the end devices.
  • the infrastructure's routing topology can change, and the addressing within the topology can also change.
  • much of the fixed infrastructure's control technology is no longer useful.
  • the infrastructure's routing algorithms and, indeed, much of the networking suite must be reworked to function efficiently and effectively in this mobile environment.
  • the MANET working group http://www.ietf.org/html.charters/manet- charter.html
  • IETF-http://www.ietf.org/) Routing Area is chartered to provide improved mobile routing and interface definition standards for use within the Internet Protocol suite. In so doing, it hopes to lay the foundation for an open, flexible and extensible architecture for MANET technology.
  • the routing protocols proposed in the MANET working group are developed in the network layer, because an inter-network layer routing solution is important for the following exemplary reasons: end user and application pressure for seamless internetworking will continue regardless of the underlying infrastructure (fixed or mobile); the "physical media independence" features of the network layer are important to support mobile routing through heterogeneous wireless fabrics, i.e. where different wireless technologies are used at the physical layer; definition of some common routing approaches and interface definitions provides future flexibility, and also improves the cost effectiveness of deployed systems.
  • DSR Dynamic Routing Routing
  • AODV and DSR both use an on-demand routing approach.
  • the performance of on-demand routing approaches is superior to that of the table-driven routing approaches in ad hoc networks, as described in S.J. Lee et al, "A Simulation Study of Table-Driven and On-Demand Routing Protocols for Mobile Ad Hoc Networks," IEEE Network, v.13, no. 4, pp. 48-54, July/August, 1999.
  • On-demand routing when a route is needed, a routing protocol attempts to find a route for the current data communication session.
  • On-demand routing does not require each node to continuously evaluate and maintain all the routes to every other node in the network, as required with table-driven routing, thus avoiding the need to frequently exchange state information, reducing the amount of update traffic, and conserving limited resources.
  • AODV is based on a distance vector routing mechanism and uses a route table to find the next hop in the route.
  • AODV assumes symmetric links in the ad hoc network and hence cannot work properly in ad hoc networks having asymmetric links.
  • DSR is based on a source routing mechanism and can work in ad hoc network having asymmetric links.
  • DSR requires that the entire route map be carried with each data packet in order for the packet to reach its destination.
  • DSR does not involve the route table lookup required by AODV, it nevertheless involves heavy routing overhead in each data packet.
  • ad hoc network routing protocols such as AODV and Associativity-Based long-lived Routing (ABR)
  • ABR Associativity-Based long-lived Routing
  • Some existing ad hoc network routing protocols for example DSR and Cluster Based Routing Protocol (CBRP), take into consideration the case of networks having asymmetric links, but they require each data packet to carry the entire route map to enable routing, resulting in excessively high overhead in every packet.
  • the present invention provides an on-demand routing protocol based on both table look-up and route discovery mechanisms which is suitable for routing in mobile ad hoc networks with symmetric and/or asymmetric links.
  • the present invention includes a routing protocol for a mobile ad hoc network having a plurality of nodes interconnected by symmetric and/or asymmetric links, each node being associated uniquely with a corresponding route table.
  • the protocol comprises discovering a route for a data packet from a first node to a second node, routing the data packet through the discovered route based on information in each route table along the discovered route, and maintaining the route.
  • the first node is a requesting source node and the second node is a neighbor node to the first node, and the discovering a route comprises checking a neighbor list.
  • the discovering a route comprises checking a neighbor list, broadcasting a first route request packet (RREQ), and receiving a route reply packet (RREP).
  • the first RREQ is received and modified by an intermediate node.
  • the intermediate node checks a status of a flag in the first RREQ and adds a reverse route entry to the route table corresponding to the intermediate node when the flag indicates a reverse route exists to the first node.
  • the intermediate node broadcasts the modified first RREQ.
  • the second node forms the RREP and unicasts the RREP to a next hop node along the reverse route.
  • the next hop node modifies the RREP and builds a forward route entry in the route table corresponding to the reverse route.
  • the discovering a route comprises checking a neighbor list, broadcasting a first route request packet (RREQ), and receiving a route reply packet (RREP) including discovered route information.
  • the first RREQ is received and modified by an intermediate node.
  • the intermediate node checks a status of a flag in the first RREQ and broadcasts the modified first RREQ when the status of the flag indicates a reverse route to the first node does not exist.
  • the second node forms a RREP using the modified first RREQ and unicasts the RREP to a next hop node along an available route.
  • the first node unicasts an activating data packet including the discovered route information to a node along the discovered route after receiving the RREP.
  • the node builds a forward route entry in the route table corresponding to the node.
  • the discovering a route comprises checking a neighbor list, broadcasting a first route request packet (RREQ), and receiving a second RREQ including discovered route information.
  • the first RREQ is received and modified by an intermediate node.
  • the intermediate node checks a status of a flag in the first RREQ and broadcasts the modified first RREQ when the status of the flag indicates a reverse route to the first node does not exist.
  • the second node forms the second RREQ using the modified first RREQ and broadcasts the second RREQ.
  • the first node unicasts an activating data packet including the discovered route information to a node along the discovered route after receiving the second RREQ.
  • the node builds a forward route entry in the route table corresponding to the node.
  • the information includes a route entry.
  • the route entry includes a timer and the route entry is erased when the timer expires.
  • the timer is reset when the route entry is used to route the data packet.
  • the maintaining the discovered route comprises determining that a next hop node is unreachable, transmitting link failure information to at least one upstream node, and erasing at least one route entry.
  • the transmitting link failure information comprises unicasting an error packet to the at least one upstream node.
  • the at least one upstream node modifies the error packet and unicasts the modified error packet.
  • the transmitting link failure information comprises broadcasting an error packet.
  • the at least one upstream node modifies the error packet and broadcasts the modified error packet. In an embodiment or the routing protocol, the at least one upstream node erases the at least one route entry.
  • Figure la is a schematic diagram illustrating transmission of route request and route reply packets in an embodiment according to the present invention in an exemplary case where a reverse route exists.
  • Figure lb is a schematic diagram illustrating transmission of route request and route reply packets in an embodiment according to the present invention in an exemplary case where a reverse route does not exist.
  • Figure 2 shows an exemplary embodiment of the routing protocol according to the present invention.
  • Figure 3 is a schematic diagram illustrating route maintenance in an embodiment according to the present invention.
  • Figure 4 shows an exemplary embodiment of the route maintenance mechanism according to the present invention.
  • the present invention provides an on-demand routing protocol based on both table look-up and route discovery mechanisms which is suitable for routing in mobile ad hoc networks with symmetric and/or asymmetric links.
  • the routing protocol of the present invention can exploit available symmetric link features of a network to improve efficiency. Data packets are routed along a discovered route based on information in route tables at nodes along the discovered route, reducing data packet overhead in comparison to source routing mechanisms.
  • the routing protocol builds a route on demand and works efficiently in ad hoc networks with symmetric and/or asymmetric links between nodes.
  • Route information is recorded in a route discovery packet during a route discovery procedure.
  • link state information relating to symmetric or asymmetric links is used to evaluate available reverse routes.
  • a route reply message may be sent back to a source node via a reverse route, if one is available, or via some other route which needs to be found.
  • data packets are routed according to route tables kept at the nodes along the route.
  • reverse route indicates a route from the destination node to the source node of a source, destination node pair
  • forward route indicates a route from the source node to the destination node of the node pair.
  • format of reverse and forward route entries in the route tables is identical. Data packets do not need to carry the entire route map with them as is the case with the DSR protocol. Route maintenance may be carried out by transmitting link failure information along previously established routes that incorporate the failed link.
  • Each node in the network maintains a neighbor list that stores link state information indicating whether its neighbors can be heard and/or are reachable, that is whether the node can receive transmissions from or send transmissions to its neighbor nodes.
  • link state information indicating whether its neighbors can be heard and/or are reachable, that is whether the node can receive transmissions from or send transmissions to its neighbor nodes.
  • the format of its neighbor list may be as shown, for example, in Table I:
  • Node x indicates the Internet Protocol (IP) address of neighbor node x, where 1 x N.
  • Stat_x provides link state information, i.e. the status, of the link connecting the node and a neighbor node x.
  • Stat can take on one of three values: forward, reverse, or bidirectional.
  • Forward status indicates that the neighbor node x can receive packets sent by the node.
  • Reverse status indicates that packets sent by the neighbor node x can be received by the node.
  • Bidirectional status indicates that the neighbor node x can receive packets sent by the node and vice versa. If the status is bidirectional, then the link connecting the node to its neighbor node x is symmetric. Otherwise the link is asymmetric.
  • the neighbor list can be built and updated through various mechanisms such as promiscuous listening, beacon messaging, explicit 3 -way handshaking or through periodic Hello message exchanges, as is known in the art.
  • a transmission route In order for a data packet to be sent from a source node to a destination node, a transmission route must exist. If a node, by checking its neighbor list, determines that the destination node is a neighbor node, then it can send the data packet to the destination node directly. If the destination node is not a neighbor, then a route must be discovered before the data packet can be sent to the destination node.
  • the source node transmits a route discovery packet, referred to as a route request packet (RREQ), by broadcasting to its neighbor nodes.
  • RREQ route request packet
  • This RREQ will be rebroadcast again throughout the network by intermediate nodes and finally be received by the destination node.
  • Route nfo is a list of IP addresses of intermediate nodes along the RREQ propagation route, in the order in which the intermediate nodes receive the RREQ;
  • the Option field may contain discovered route map information for the case where the requested destination node needs to discover a route to the requesting source in order to send a reply packet, as described further below.
  • a node When a node receives a RREQ, it first checks the Src_addr and Reqjd values to avoid rebroadcasting duplicate RREQs. The node records Srcjxddr and Reqjd values for each RREQ for the purpose of comparing RREQs. A duplicate RREQ (a RREQ with Srcjxddr and Reqjd values identical to a previously received RREQ) is discarded by the node.
  • a node modifies the RREQ appropriately, as described in the following.
  • the node adds its own address to the sequence of addresses Route jnfo in the RREQ.
  • the node checks the Flag status. If Flag has been set to 1 , which means that no reverse route can be built from the upstream node (as determined from the last address in the Route jnfo field in the packet) to the requesting source node, then the Flag status is left unchanged. If Flag has been set to 0 and the link connecting the node and the upstream node is symmetric, signifying that a reverse route can be built from the node to the requesting source node, then the Flag status is left unchanged.
  • Flag has been set to 0 and the link connecting the node and the upstream node is asymmetric, signifying that the node can receive directly a packet sent by the upstream node while the upstream node cannot receive directly a packet sent by the node (i.e., the packet must travel from the node to the upstream node by a circuitous route), then the node will set Flag to 1. If Flag remains at 0, the node adds a reverse route entry to its route table.
  • Each node in the network is associated with its own route table.
  • An exemplary form of a route table is shown in Table II, where it is understood that the empty cells in the table are filled with valid values.
  • Each row in the route table is referred to hereinafter as a "route entry” or simply “entry.”
  • Table II contain the following data.
  • a reverse route is built from a current node to the requesting source node.
  • Destjxddr holds an address of the destination node to which the packet will be sent ultimately. Here, it is filled with the address of the requesting source node (Srcjxddr in the corresponding RREQ).
  • Nxt ipjiddr holds an address of the next hop node, to which the packet will be sent immediately.
  • Nxt ipjiddr contains the address of the upstream node, obtained from Route jnfo.
  • Up trjtddr holds an address of the upstream node from which the packet is received.
  • Up_strjxddr can be extended to form a list containing more than one upstream node address.
  • Up_strjxddr holds the address of the node to which the RREQ may be sent. (This field is filled later, when a corresponding forward route is built, and used in route maintenance in order for the node to be able to inform its upstream node of a failed link.)
  • Hop nt holds a number of hops from the current node to the destination node.
  • Hopjnt contains the hop count from the current node to the requesting source node, derived from Route info.
  • Time_stmp holds a time value.
  • Time_stmp contains the current time.
  • each entry or row in a route table is kept only for a short period of time in order to prevent a stale route from being used.
  • the Timejstmp in each entry is periodically compared with the current time, and if the difference is more than a given value, then the corresponding entry is deleted from the route table.
  • the current node After modifying the RREQ by adding the current node address in the Route jnfo field and adjusting the value of Flag in the RREQ, the current node broadcasts the modified RREQ.
  • a node If a node is the requested destination node, the node forms a route reply packet (RREP) and sends it back to the requesting source node. If a reverse route from the requested destination node to the requesting source node is available, the RREP will be sent along the reverse route. Otherwise, the RREP will be sent along an available route to the requesting source node, or the destination node will find a new route through the route discovery procedure and piggyback the discovered route information on another RREQ, as described in greater detail hereinafter.
  • RREP route reply packet
  • a circle indicates a node in a mobile ad hoc network
  • a dashed line or dashed arrow indicates a link between two nodes
  • a solid arrow represents a RREP and/or RREQ.
  • a route is established through the propagation of a RREQ 110 from source node 100 through intermediate node 102 to destination node 101. Since a reverse route exists, the destination node 101 unicasts a RREP 120 along the reverse route (through node 102) back to the source node 100. Each node along the reverse route, e.g. 102, examines the RREP 120, completes the reverse route entry by filling the immediate sender's address in the Up_strjxddr field in the reverse route entry in the route table, and builds a forward route entry in the route table leading to the requested destination node. Thus, the RREP 120 does not need to carry the entire route map.
  • the various fields in the RREP contain the following data: Destjxddr, the address of the requesting source node (Srcjxddr in the corresponding RREQ); Srcjxddr, the address of the requested destination node (Destjxddr in the corresponding RREQ); and Hopjnt, the hop count from the requested destination node, initially set to zero at the requested destination address.
  • the RREP is unicast to the node, e.g. 102 in Fig. la, having the address indicated in Nxt ipjiddr field in the reverse route entry.
  • next hop node (102 in this example) When the next hop node (102 in this example) receives the RREP, it gets the immediate sender's address (the address of node 101) and places it in the Up_strjxddr field in its corresponding reverse route entry. This Upjtrjxddr value will be used in the route maintenance procedure described below to inform upstream nodes of unavailable link status.
  • the next hop node (102 in this example) also builds a forward route entry in its route table leading to the requested destination node (node 101, in this example).
  • the forward route entry has the same format as a reverse route entry, as shown, for example, in Table III below, where it is understood that the empty cells in the table are to be filled with valid values.
  • the various fields in Table III contain the following data: Destjxddr, the address of the requested destination node (Srcjxddr in the RREP); Nxt ipjiddr, the address of the previous node (from which the RREP was received); Upjstrjxddr, the Nxtjipjiddr in the corresponding reverse route entry; Hopjnt, the hop count, obtained from the RREP; and Time_stmp, the current time.
  • a node which receives a RREP will modify the RREP by increasing the value of Hop nt by one and re-send the RREP to its next hop node along the reverse route.
  • Node 102 increases the value of Hop nt to 1 and re-sends RREP 120 to node 100, its next hop node along the reverse route.
  • the RREP finally reaches the requesting source node along the reverse route (node 100 in the example above), a forward route from the requesting source node to the requested destination node is discovered accordingly.
  • a reverse route does not exist, for example as shown in Figure lb
  • the first scenario another existing route is available and may be used.
  • the second scenario there is no available route, and the previously discovered route information can be piggybacked on another RREQ to the requesting source node.
  • another route is known and available, for example from requested destination node 151 to source node 150 through node 153
  • node 151 extracts Route jnfo from the RREQ 160, forms a RREP 170 in response to the RREQ, and unicasts it to the requesting source node along the available route through 153 to 150.
  • the RREP 170 in this case may have the format shown in (3) below, where the field Extracted Route jnfo contains information extracted from the Route jnfo field of the RREQ 160:
  • the destination node 151 inserts the appropriate Route jnfo value into the Option field in a RREQ 170 and sends it to the requesting source node 150 by broadcasting, that is, the discovered route map "piggybacks" on the RREQ 170.
  • the format of the RREQ 170 in this instance is the same as in (1) and is shown in (4) below:
  • the requesting source node 150 retrieves the information from the Option field in RREQ 170 having the format (4), it knows the entire route map leading to the requested destination node 151.
  • data packets can be routed to the destination node by using the Loose Source and Record Route option in IPv4 or the route header option in IPv6.
  • the Loose Source and Record Route option in IPv4 provides a means for the source of a packet to supply routing information to be used by intermediate nodes in forwarding the packet to the destination and to record the route information.
  • the route header option in IPv6 allows the source of a packet to list the intermediate nodes to be "visited" on the way to a packet's destination.)
  • the first data packet sent by the source node serves as an activating route packet to enable the nodes along the discovered route to build route entries in their route tables. This is in contrast to the scenario in which a reverse route exists ( Figure la), wherein, as previously described, the forward route is built along the discovered route as the RREP propagates from the requested destination node to the source node, and consequently no activating packet is required.
  • each intermediate node along the route e.g.
  • 152 in Figure lb is able to build a forward route entry in its route table.
  • the fields in the forward route entry such as Up_strjxddr, Nxtjipjiddr and Hp nt, can be filled by examining the route information carried in the option header of the data packet.
  • a forward route from the requesting source node, e.g. 150, through 152 to the requested destination node 151 can be established.
  • one of the routes in the RREQs may be chosen based on certain metrics (such as number of hops, signal strength, existence of reverse route, etc.).
  • route information is set in the route tables of the nodes along a route
  • subsequent data packets are routed to the destination node based on the data in the route tables held by each node without the need to carry the entire route map in the subsequent data packets.
  • a first node When a first node needs to communicate with a second (destination) node, it first checks whether a route to the second node exists in its routing table. If a route does not exist, the first node broadcasts a RREQ to find a route to the destination node. If a route does exist from the first node to the destination node, the first node sends a data packet to the intended destination node based on route table information held by intermediate nodes. Each intermediate node along the route forwards the packet based on its route table.
  • Figure 2 provides an overview of an exemplary embodiment of the protocol according to the present invention.
  • the requesting source node broadcasts a first RREQ.
  • a node receiving the first RREQ determines whether it is the requested destination node. If the receiving node is not the destination node, at 204 the receiving node verifies that the received first RREQ is not a duplicate, as described previously. At 206 the receiving node adds its own address to the first RREQ and at 208 checks the flag status to determine whether a reverse route to the requesting source node exists. If not, the receiving node broadcasts the modified first RREQ. If yes, the receiving node at 210 builds a reverse route entry in its route table and broadcasts the modified first RREQ.
  • the receiving node If the receiving node is the requested destination node, at 212 the receiving node forms a RREP and at 214 checks the flag status in the previously received first RREQ to determine whether a reverse route exists to the requesting source node. If yes, at 216 the destination node unicasts the RREP to its next hop node along the reverse route. At 218 the next hop node completes the reverse route entry in its route table, as described previously, and builds a forward route entry in its route table at 220. At 222 the next hop node determines whether it is the requesting source node. If yes, route discovery is complete (224). If not, the next hop node unicasts the modified RREP to the next hop node along the reverse route.
  • the destination node determines whether an available route exists the requesting source node. If yes, the destination node forms a RREP containing information regarding the discovered route, as described previously (228) and unicasts the data packet to a node along the available route (230). At 232, if the node receiving the data packet is not the requesting source node, the receiving node unicasts the RREP to another node along the route. If the requesting source node receives this RREP, it unicasts an activating data packet (242). At 244, a node receiving this activating packet determines whether it is the requested destination node. If the receiving node is not the destination node, at 246 the receiving node builds a forward route entry in its route table and unicasts the activating packet. If the receiving node is the destination node, route discovery is complete (248).
  • the destination node determines that an available route to the requesting source node does not exist, the destination node forms a second RREQ (236) containing information regarding the discovered route, as described previously, and broadcasts the second RREQ (238).
  • a node receiving the second RREQ determines whether it is the requesting source node by examining the RREQ, as described previously. If the receiving node is not the requesting source node, the receiving node rebroadcasts the second RREQ. If the requesting source node receives the second RREQ, it unicasts an activating data packet (242), which is treated as described in the preceeding paragraph and shown in Figure 2.
  • a current node When a current node notices, using, for example, one or more of the mechanisms listed previously for building up the neighbor list, that the next hop node along a route is unreachable, it must notify the upstream nodes using the route to update the route information held by each intermediate node in a timely manner. In this circumstance, the current node sends an error packet to the upstream node indicated by the corresponding route entry in its route table to inform the upstream node that the destination node is unreachable. Two different ways to send the error packet are considered below.
  • the current node unicasts an error packet to the upstream node.
  • the format of the error packet may be as shown in (5) below:
  • the various fields in the error packet having the format shown in (5) contain the following data: Destjxddr, the address of the upstream node in the relevant route; Srcjxddr, the address of the current node, which is forming the error packet; Route Destjxddr, the address of the destination node in the relevant route; and Type, an indication that the packet is a unicast route error packet.
  • the upstream node When the upstream node receives the error packet, it erases the route entry
  • Figure 3 diagrammatically illustrates the case where source node 300 has discovered a route to destination node 306 consisting of, in sequence, nodes 300, 301, 305, 302, and 306, while source node 303 has discovered a route to the same destination node 306 consisting of nodes 303,
  • a circle indicates a node in a mobile ad hoc network
  • a bold line with arrowheads at both ends indicates a symmetric link between two nodes
  • a regular line with an arrowhead at only one end indicates an asymmetric link between two nodes.
  • Tables IVa, IVb, and IVc are route tables built in nodes 301, 304, and 305, respectively, where valid entries in the Time_stmp fields are represented by the symbol *. (The exact values are not critical to this discussion.)
  • node 305 If node 305 notices the node 302 is unreachable, it informs the related upstream nodes about the broken link, that is, node 305 sends an error packet to nodes 301 and nodes 304 in the concerned routes.
  • Node 305 also sends an error packet (7) to node 301:
  • node 301 When node 301 receives the error packet (7), because the values in both the Nxtjipjiddr and Destjxddr fields in its route table (Table IVa), 305 and 306, respectively, match the Srcjxddr and Route JPestjxddr values in the error packet, node 301 erases the following route entry in Table IVa: (8)
  • Node 301 also sends an error packet (9) to node 300:
  • the source node 300 receives the error packet (9) and erases the relevant route entry in its route table.
  • the format of the broadcast error packet (10) may be as shown below:
  • the Destjxddr, Srcjxddr, and Route Destjxddr fields have the same significance in the error packet (10) as in the error packet (5).
  • the Err id field holds a sequence number set by the node corresponding to the Src addr. Errjd is combined with Src addr to prevent a node from broadcasting a duplicate error packet. (As a result no node will process the same error packet twice.)
  • the Type field indicates that the packet (10) is a broadcasting route error packet.
  • the upstream node When the upstream node receives the error packet (10), it erases the route entry in its own route table in which the values in the Nxt ipjiddr and Destjxddr fields match those in the Srcjxddr and Route Dest jxddr fields of the error packet (10), rebuilds the error packet by placing the address of an upstream node address in the Destjxddr field, placing its own node address in the Srcjxddr field, and choosing an Errjd, and rebroadcasts the rebuilt error packet.
  • node 305 notices that the node 302 is unreachable, it erases the following route entry in node 305: (11)
  • Node 305 also informs its upstream node 304 about the unavailable route to node 306. Since there is no available route to node 304 (the link from node 304 to node 305 being asymmetric), it will broadcast the error packet (12):
  • the error packet (12) is rebroadcast through nodes 301, 300, and 303 to reach node 304.
  • node 304 When node 304 receives the packet (12), because the Nxtjip addr and Destjxddr values in its route table (Table IVb), 305 and 306, respectively, match the Srcjxddr and Route _Dest jxddr values in the packet, it erases following route entry in Table IVb:
  • Node 304 also sends an error packet (14) to node 303:
  • Err_id changes each time the error packet is rebuilt. Finally, the source node 303 receives this error packet and is thereby informed of the defective route.
  • FIG 400 provides an overview of an exemplary embodiment of the route maintenance mechanism according to the present invention.
  • a node determines that a next hop node in a route is unreachable, as described previously.
  • the node determines whether a route is available to an upstream node in the route. If an available route exists at 402, then at 404, the node erases a route entry containing information regarding the failed link, forms an error packet (406), and unicasts the error packet to an upstream node along the available route (408).
  • the upstream node erases a route entry containing information regarding the failed link (410).
  • the upstream node determines by examining the error packet whether it is the requesting source node for the route containing the failed link (412).
  • the upstream node modifies the error packet, as described previously (414) and unicasts the modified error packet. If the upstream node is the source node, all nodes in the route have been alerted to the failed link, and route maintenance is complete (416).
  • the node forms an error packet (418) and broadcasts the error packet (420). If a node receiving the error packet is not the upstream node (422), it rebroadcasts the error packet (420). If the node is the upstream node, it erases a route entry containing information regarding the failed link (424). The upstream node determines by examining the received error packet whether it is the requesting source node for the route containing the failed link (426). If the receiving node is not the source node, it modifies the error packet (428) and broadcasts the modified error packet (420). If the upstream node is the source node, route maintenance is complete (430).
  • the routing protocol of the present invention has a number of advantages over the prior art.
  • the routing protocol according to the present invention is on-demand in nature and carries all the advantages of on-demand routing protocols compared to table driven protocols, since no periodic route table information exchange is required.
  • the routing protocol of the present invention is also capable of supporting ad hoc networks having asymmetric links. This functionality is achieved without adding packet overhead, as in the case of protocols relying on source routing mechanisms, such as DSR.
  • the present invention requires only minimal routing information in each data packet, as does AODV, but, unlike AODV, works properly in ad hoc networks having asymmetric links. It also provides reverse route formation with explicit link status.
  • node neighbor discovery eliminates the need to carry out route discovery in the case of destinations that are neighbors. Moreover, since a single pair of RREQ and RREPs may be used, modified as appropriate by intermediate nodes as the packets propagate through the network, a larger number of nodes are able to derive partial or complete route information, since explicit route and link status are known to the nodes. Furthermore, the route maintenance algorithm of the present invention minimizes the number of stale routes.

Abstract

L'invention concerne un protocole de routage sur demande fondé sur des mécanismes de consultation de table et de recherche de route pour le routage dans les réseaux ad hoc mobiles avec des liens symétriques et/ou asymétriques. Le protocole de routage établie une route sur demande et enregistre les informations relatives à la route dans un paquet de recherche de route au cours de la procédure de recherche de route. Pendant cette procédure, des informations sur l'état des liens relatives aux liens symétriques ou asymétriques sont utilisées afin d'évaluer les routes inverses disponibles. Lorsqu'une route vers la destination est découverte, un message de réponse de route est renvoyé vers la source par une route inverse, si elle est disponible, ou par n'importe quelle autre route qui doit être découverte. Une fois que la route aval est établie, des paquets de données sont acheminés selon les tables de routage conservées dans des noeuds le long de la route, sans transporter toute la carte des routes. La maintenance des routes est assurée grâce à la transmission d'informations sur des liens défectueux le long des routes préalablement établies au moyen des liens défectueux.
PCT/SG2001/000064 2001-04-16 2001-04-16 Protocole de routage de reseaux ad hoc mobiles generaux WO2002084956A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/SG2001/000064 WO2002084956A1 (fr) 2001-04-16 2001-04-16 Protocole de routage de reseaux ad hoc mobiles generaux

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/SG2001/000064 WO2002084956A1 (fr) 2001-04-16 2001-04-16 Protocole de routage de reseaux ad hoc mobiles generaux

Publications (1)

Publication Number Publication Date
WO2002084956A1 true WO2002084956A1 (fr) 2002-10-24

Family

ID=20428925

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/SG2001/000064 WO2002084956A1 (fr) 2001-04-16 2001-04-16 Protocole de routage de reseaux ad hoc mobiles generaux

Country Status (1)

Country Link
WO (1) WO2002084956A1 (fr)

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004045166A1 (fr) * 2002-11-13 2004-05-27 Telenor Asa Procede de routage de messages en provenance d'un noeud d'origine vers un noeud de destination dans un reseau dynamique
EP1475926A2 (fr) * 2003-05-05 2004-11-10 Samsung Electronics Co., Ltd. Procédé et système pour l'établissement d'une route optimale dans un réseau local personnel sans fil (WPAN)
WO2005043836A1 (fr) * 2003-10-31 2005-05-12 Siemens Aktiengesellschaft Procede pour determiner un chemin dans un systeme de communication radio local
WO2005062552A1 (fr) * 2003-12-23 2005-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Systeme ad hoc predictif
EP1580942A2 (fr) * 2004-03-12 2005-09-28 Lucent Technologies Inc. L'assurance d'intégrité des trajets pour un protocole tunnel
WO2005107179A1 (fr) * 2004-04-30 2005-11-10 Daimlerchrysler Ag Reseau de communication de donnees a gestion de communication decentralisee
WO2006026049A1 (fr) * 2004-08-31 2006-03-09 Intel Corporation Procede et dispositif pour mettre en place une communication multipoint-a-multipoint dans un reseau maille sans fil
WO2007127174A2 (fr) * 2006-04-24 2007-11-08 Marvell World Trade Ltd. Architecture maillée 802.11 améliorée
US7453864B2 (en) 2003-04-30 2008-11-18 Harris Corporation Predictive route maintenance in a mobile ad hoc network
WO2011012062A1 (fr) * 2009-07-27 2011-02-03 华为技术有限公司 Procédé, dispositif et système permettant de sélectionner une découverte d'itinéraire
WO2011023482A1 (fr) * 2009-08-31 2011-03-03 Siemens Aktiengesellschaft Procédé et dispositif pour trouver un chemin dans un réseau
US8036224B2 (en) 2003-12-23 2011-10-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for efficient routing in Ad Hoc networks
US8218550B2 (en) 2003-12-23 2012-07-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for routing traffic in ad hoc networks
KR20190017906A (ko) * 2016-07-16 2019-02-20 소니 주식회사 방향성 송신들을 가지는 무선 네트워크들에서의 데이터 패킷들의 라우팅
US11184832B2 (en) 2020-01-30 2021-11-23 Mage Networks Inc. Routing method and device of mobile ad-hoc networks

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987011A (en) * 1996-08-30 1999-11-16 Chai-Keong Toh Routing method for Ad-Hoc mobile networks

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987011A (en) * 1996-08-30 1999-11-16 Chai-Keong Toh Routing method for Ad-Hoc mobile networks

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
DONKYUN K. ET AL.: "A new dynamic routing protocol using dual paths to support asymmetric links in mobile ad hoc networks", 2000, PROCEEDINGS OF THE 9TH INTERNATIONAL CONFERENCE ON COMPUTER COMMUNICATIONS AND NETWORKS, NEW YORK: IEEE *
PERKINS C. ET AL.: "Ad-hoc on-demand distance vector routing", 1999, PROCEEDINGS OF THE 2ND IEEE WORKSHOP ON MOBILE COMPUTING SYSTEMS AND APPLICATIONS, NEW YORK: IEEE *
RAMANUJAN R. ET AL.: "Source-initiated adaptive routing algorithm (SARA) for autonomous wireless local area networks", 1998, PROCEEDINGS OF THE 23RD ANNUAL CONFERENCE ON LOCAL COMPUTER NETWORKS, NEW YORK: IEEE *

Cited By (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004045166A1 (fr) * 2002-11-13 2004-05-27 Telenor Asa Procede de routage de messages en provenance d'un noeud d'origine vers un noeud de destination dans un reseau dynamique
US7453864B2 (en) 2003-04-30 2008-11-18 Harris Corporation Predictive route maintenance in a mobile ad hoc network
EP1475926A2 (fr) * 2003-05-05 2004-11-10 Samsung Electronics Co., Ltd. Procédé et système pour l'établissement d'une route optimale dans un réseau local personnel sans fil (WPAN)
EP1475926A3 (fr) * 2003-05-05 2007-02-28 Samsung Electronics Co., Ltd. Procédé et système pour l'établissement d'une route optimale dans un réseau local personnel sans fil (WPAN)
WO2005043836A1 (fr) * 2003-10-31 2005-05-12 Siemens Aktiengesellschaft Procede pour determiner un chemin dans un systeme de communication radio local
AU2004307246B2 (en) * 2003-10-31 2009-03-26 Nokia Solutions And Networks Gmbh & Co. Kg Method for determining a routing in a local radio communications system
KR101097212B1 (ko) 2003-10-31 2011-12-21 노키아 지멘스 네트웍스 게엠베하 운트 코. 카게 로컬 무선 통신 시스템에서 라우팅을 결정하기 위한 방법
US8260202B2 (en) 2003-10-31 2012-09-04 Nokia Siemens Networks Gmbh & Co. Kg Method for determining a path in a local radio communication
WO2005062552A1 (fr) * 2003-12-23 2005-07-07 Telefonaktiebolaget Lm Ericsson (Publ) Systeme ad hoc predictif
US8036224B2 (en) 2003-12-23 2011-10-11 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for efficient routing in Ad Hoc networks
US8553560B2 (en) 2003-12-23 2013-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Predictive ad-hoc network routing
US8218550B2 (en) 2003-12-23 2012-07-10 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for routing traffic in ad hoc networks
EP1580942A2 (fr) * 2004-03-12 2005-09-28 Lucent Technologies Inc. L'assurance d'intégrité des trajets pour un protocole tunnel
US7414997B2 (en) 2004-03-12 2008-08-19 Lucent Technologies Inc. GPRS tunneling protocol path integrity protocol
EP1580942A3 (fr) * 2004-03-12 2005-10-12 Lucent Technologies Inc. L'assurance d'intégrité des trajets pour un protocole tunnel
WO2005107179A1 (fr) * 2004-04-30 2005-11-10 Daimlerchrysler Ag Reseau de communication de donnees a gestion de communication decentralisee
GB2430840A (en) * 2004-08-31 2007-04-04 Intel Corp Method and apparatus for implementing all-to-all communication in a wireless mesh network
GB2430840B (en) * 2004-08-31 2009-03-18 Intel Corp Method and apparatus for implementing all-to-all communication in a wireless mesh network
WO2006026049A1 (fr) * 2004-08-31 2006-03-09 Intel Corporation Procede et dispositif pour mettre en place une communication multipoint-a-multipoint dans un reseau maille sans fil
DE112005002026B4 (de) * 2004-08-31 2011-02-24 Intel Corporation, Santa Clara Verfahren und Vorrichtung zum Implementieren einer All-to-all-Kommunikation in einem drahtlosen Maschennetzwerk
CN101010918B (zh) * 2004-08-31 2012-12-26 英特尔公司 在无线网格网络中实现全部到全部通信的方法和装置
US7471668B2 (en) 2004-08-31 2008-12-30 Intel Corporation Method and apparatus for implementing all-to-all communication in a wireless mesh network
WO2007127174A2 (fr) * 2006-04-24 2007-11-08 Marvell World Trade Ltd. Architecture maillée 802.11 améliorée
US9479428B2 (en) 2006-04-24 2016-10-25 Marvell World Trade Ltd. Cumulative route metrics for wireless mesh network routing
WO2007127174A3 (fr) * 2006-04-24 2008-04-10 Marvell World Trade Ltd Architecture maillée 802.11 améliorée
CN101479999A (zh) * 2006-04-24 2009-07-08 马维尔国际贸易有限公司 改进的802.11网格体系结构
US8014370B2 (en) 2006-04-24 2011-09-06 Marvell World Trade Ltd. 802.11 mesh architecture
US8738013B2 (en) 2006-04-24 2014-05-27 Marvell World Trade Ltd. 802.11 mesh architecture
CN101479999B (zh) * 2006-04-24 2014-05-28 马维尔国际贸易有限公司 一种无线网络设备及用于无线网络设备的方法
WO2011012062A1 (fr) * 2009-07-27 2011-02-03 华为技术有限公司 Procédé, dispositif et système permettant de sélectionner une découverte d'itinéraire
US9055522B2 (en) 2009-07-27 2015-06-09 Huawei Technologies Co., Ltd. Method, device, and system for selecting route discovery
WO2011023482A1 (fr) * 2009-08-31 2011-03-03 Siemens Aktiengesellschaft Procédé et dispositif pour trouver un chemin dans un réseau
KR20190017906A (ko) * 2016-07-16 2019-02-20 소니 주식회사 방향성 송신들을 가지는 무선 네트워크들에서의 데이터 패킷들의 라우팅
JP2019526212A (ja) * 2016-07-16 2019-09-12 ソニー株式会社 無線ネットワークにおける指向性送信によるデータパケットのルーティング
KR102139017B1 (ko) 2016-07-16 2020-07-28 소니 주식회사 방향성 송신들을 가지는 무선 네트워크들에서의 데이터 패킷들의 라우팅
US11184832B2 (en) 2020-01-30 2021-11-23 Mage Networks Inc. Routing method and device of mobile ad-hoc networks

Similar Documents

Publication Publication Date Title
Misra Routing protocols for ad hoc mobile wireless networks
Rahman et al. A simulation based performance comparison of routing protocol on Mobile Ad-hoc Network (proactive, reactive and hybrid)
KR101423331B1 (ko) 하드웨어 주소를 기반으로 한 이동 애드 혹 네트워크라우팅 시스템, 방법 및 컴퓨터 판독 가능한 매체
Yadav et al. Performance comparison and analysis of table-driven and on-demand routing protocols for mobile ad-hoc networks
US20020145978A1 (en) Mrp-based hybrid routing for mobile ad hoc networks
Fujiwara et al. An inter-domain routing for heterogeneous mobile ad hoc networks using packet conversion and address sharing
Devi et al. Mobile ad hoc networks and routing protocols in IoT enabled
WO2002084956A1 (fr) Protocole de routage de reseaux ad hoc mobiles generaux
Gupta et al. Comparison of various routing algorithms for VANETS
Bendale et al. Study of various routing protocols in mobile ad-hoc networks
KR100458207B1 (ko) Ａｄ―ｈｏｃ 네트워크의 요구기반 경로 탐색 방법
Lee et al. A new taxonomy of routing algorithms for wireless mobile ad hoc networks: the component approach
Gangwar et al. Mobile ad hoc network routing protocols: a detailed performance examination of AODV, DSR and DSDV
Chintawar et al. Performance analysis of ad-hoc on demand multipath distance vector routing protocol with accessibility and link breakage prediction
Suryawanshi et al. Survey on Various Routing Protocols in Ad-hoc Networks
WO2002043335A1 (fr) Procede et systeme de pontage de reseaux mobiles ad hoc
Lanjwar et al. Performance analysis of routing protocols for battlefield monitoring system
Singh et al. Routing protocols for WMNS: a survey
Rao et al. An elliptical routing protocol for wireless mesh networks: Performance analysis
Sreevani et al. Network Security Based Authenticated Routing Protocol
Ramana et al. Design and performance evaluation of meghadoot-A hybrid wireless network architecture
Dwivedi et al. A Review of Routing Protocols & Techniques for Mobile Ad-Hoc Networks
Agrawal et al. Simulation Based Performance Comparison of Adhoc Routing Protocols
Anand Survey on Geographical Routing Protocols in Network-Centric Warfare Paradigm
El Ghandour et al. COMPARATIVE EVALUATION OF MOBILE AD HOC NETWORK (MANET) PROTOCOLS ROUTING

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 69(1) EPC

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP