The invention pertains to packet routing over Mobile Ad Hoc Networks (MANETs).
A MANET is a highly dynamic and constantly evolving network in which a collection of wireless mobile nodes form a network without any fixed infrastructure. A MANET is useful in a situation in which it is economically or physically impractical to provide a fixed infrastructure, such as for emergency workers during a hurricane or for soldiers on a battlefield. Such conditions provide no opportunity for a permanent infrastructure, which makes the mobile aspect of a MANET ideal. Efficient routing over MANETs has been a focus of research in recent years.
Quality of service (QoS) requirements of MANETs have also been a focus of research in the data networking community as interest in real-time applications over minimal infrastructure networks, such as MANETs, has increased. One specific application where QoS is of particular concern is voice over IP (VoIP). VoIP is essentially telephone service over the Internet, i.e., utilizing a data network connection to make real time telephone calls. In the two above situations, utilizing a MANET to carry VoIP data flows is beneficial as it provides contact to soldiers or emergency workers who may be far from a fixed contact point. By utilizing nodes in the MANET, the VoIP data flow can be routed to its destination despite the lack of a permanent communication infrastructure.
One popular routing protocol for MANETs is the Optimized Link State Routing (OLSR) protocol. OLSR is explained in “Optimized Link State Routing Protocol (OLSR)” by Clausen & Jacquet, RFC 3626, published October 2003, and available on the internet at “http://ietf.org/rfc/rfc3626.txt”. In a MANET, a link is any outgoing path from an individual node to another node. OLSR is a proactive routing protocol that propagates partial link state information through a MANET to support hop-by-hop packet forwarding based on the “min-hop” criterion. “Min-hop” essentially means minimum hop, or selecting a route based on the fewest hops between source and destination, regardless of the quality of the links used for each hop. Note that as long as a link is considered alive, as determined, for example, by the reception of a minimum number of hello messages in some time period, the OLSR protocol advertises it and uses it in the construction of routing tables, regardless of the quality of that link. Thus, during some topology changes, for instance, a link may go through long periods of low link quality before being considered “dead.” Any source node utilizing this advertised weak link in its routing tables risks packet delays and packet losses, both of which cause degradation to the data flow. In the above case where a MANET is used to carry a VoIP data flow, excessive packet delays and packet losses may cause an individual VoIP data flow to be completely lost.
The basic algorithm underlying routing table calculations in OLSR attempts to minimize path lengths between source-destination pairs by selecting routes with the smallest number of hops between source and destination nodes without concern for link quality. What is needed is a method of determining any desired service requirements for a data flow being forwarded in a MANET before determining a route to use for forwarding the data flow.
The present invention provides a method of improving on the OLSR routing protocol to not only look for a “min-hop” route, but to look for paths with good delay characteristics for non-real time (or best effort) traffic (e.g., email attachments) as well as good link quality characteristics for real time traffic (e.g., streaming audio or video). The present invention modifies the routing table calculation of the OLSR protocol to utilize a calculated delay metric to evaluate links in the routing table and choose an appropriate route based upon the QoS level required by a data flow being forwarded along the chosen route.
In order to determine which criteria to use when selecting a route, the data flow being forwarded must first be analyzed to determine a minimum QoS level that must be maintained along the selected route. By utilizing extension headers (such as those defined by IP version 6), desired service parameters (e.g., necessary bandwidth, acceptable delays) are included in the first packet of the data flow. By analyzing these parameters, a source node can determine a route with intermediate nodes that have adequate resources to deliver the data flow. Once the route is determined by the source node, the data flow is forwarded along the route to a destination node.
In one embodiment of the present invention, the service requirements for a particular data flow are determined, as well as the type of the data flow, i.e., best-effort traffic or real-time traffic. Once the requirements of the data flow are determined, a source node uses routing tables to select a route to a destination node that will satisfy the service requirements.
For best effort traffic, a route is selected that will minimize the hops between the source node and the destination node. For real-time traffic, the desired service requirements are written into an extension header of the first packet of the data flow. The first packet is delivered to the Internet Protocol (IP) layer of the source node where the extension header is read. The desired service requirements are analyzed, and a route cache is checked. The route cache stores routes previously used to forward data flows to certain nodes. If a route exists in the route cache that will satisfy the desired service requirements, the route is inserted into an additional extension header in the first packet of the data flow, and the packet (along with the rest of the data flow) is forwarded along the chosen route.
If a route does not exist in the route cache, the source node utilizes the network routing tables to construct a new route, which as before is inserted in an additional extension header in the first packet, and the packet is forwarded along the route. The new route is also stored in the route cache for later use.
MANETs are highly dynamic, with frequent topology changes as nodes move into or out of the transmission range of other nodes.
A MANET predominantly comprises mobile devices, e.g., 115a, 115b and 115c as shown in
In a realistic MANET, hundreds or thousands of nodes may be present. A remote node may have numerous links to use to connect to another node, or an Internet Gateway such as 105 in
At step 204, each of the now organized nodes advertises its link-state information. By using standard OLSR mechanisms, e.g., hello messages and topology control (TC) messages, link-state information is propagated through the MANET. The hello messages and TC messages are augmented to carry additional information such as available link bandwidth, signal-to-noise (SNR) and delay information for each link. Once the nodes advertise their link-state information, the process proceeds to step 206.
At step 206, each node constructs an initial routing table based upon the information contained in the hello messages. The standard OLSR routing tables are augmented to include the additional information contained in the hello and TC messages, specifically the link-state information. Once the nodes have created the initial routing table, the process proceeds to step 208.
At step 208, additional nodes can join the MANET. When a new node joins the MANET, the process returns to step 204 where the process repeats resulting in updated routing tables at each node in the MANET.
Once the MANET is configured, each node utilizes the routing tables to forward data from one node to another.
Once a source node has determined the type of data being sent as well as any accompanying service requirements, the process moves to step 304. Here, the source node determines a route to the destination node. First, the source node looks into its route cache where all routes previously used by the source node for forwarding packets are stored. If a route exists in the route cache that satisfies the desired service requirements, the source node selects that route. If no such route exists in the route cache, the source node creates a new route to the destination node based upon the information stored in the routing tables for the MANET created in step 206 of
At step 306, the source node formats the initial packet of the data to be sent. An extension header is added to the packet which includes the desired service requirements. A second extension header is added which includes the entire route determined by the source node to be used in forwarding the data to the destination node. Once the packet is formatted, the process proceeds to step 308.
At step 308, the source node forwards the packets of the data flow along the determined route to the destination node.
The embodiment shown in
It should be clear to persons familiar with the related arts that the processes, procedures and/or steps of the invention described herein can be performed by a programmed computing device running software designed to cause the computing device to perform the processes, procedures and/or steps described herein. These processes, procedures and/or steps also could be performed by other forms of circuitry including, but not limited to, application-specific integrated circuits, logic circuits and state machines.
The embodiments shown above are merely shown by way of example. One of ordinary skill in the art will recognize additional embodiments and advantages not fully illustrated above. For example, different desired service requirements can be selected to identify a particular data flow. Accordingly, the breadth and scope of the present invention should be defined only in accordance with the following claims and their equivalents.