GB2425688A - Routing method for ad hoc networks - Google Patents

Abstract

A routing method for an ad hoc network comprising two or more nodes, finds further routes between two nodes, and overcomes the link latency problem by separating loops into two link-disjoint routes. The method comprises: finding at least one first route for a request message sent between nodes via intermediate nodes, with the destination node sending a reply message back via the same intermediate nodes to determine a route; finding any further routes by sending a reply broadcast message with the reply message; finding one or more loop check nodes; sending a loop check message from at least one loop check node towards the originator node along known routes; and finding one or more path recovery nodes; sending a path recovery message from each path recovery node to neighbours not used as next hops to the destination node, until a node is reached which has a known route to the destination node.

Description

ROUTING METHOD FOR AD HOC NETWORKS

This invention relates to a routing method for an ad hoc network. In particular, it relates to a route recovery protocol for mobile ad hoc networks, which is used to discover routes.

Mobile ad hoc networks are a class of networks based on wireless technologies. Ad hoc networks are a permanent or temporary collection of nodes that can communicate with each other. A "node" is a device with a network interface that is participating in routing in the mobile ad hoc network. A node can be a large network (eg, a Local Area Network (LAN)) or a single device. Examples of devices that can act as nodes include mobile phones, laptop computers and personal digital assistants (PDAs). For a wireless network each node will have a transmitter and receiver so that each node can communicate with neighbouring nodes. The advent of accessible and compact short range communication systems such as the BluetoothTM system means it is now feasible for a wide range of devices to be configured to behave as nodes.

Ad hoc networks have no pre-existing infrastructure and there is no central entity to provide network administration services. Each mobile node operates as a router, forwarding packets for other mobile nodes in the network that may not be within direct wireless transmission range of each other. End-to-end communication may require the routing of information via several intermediate nodes.

Ad hoc networks are sometimes referred to as multi-hop networks, where a hop is a direct link between two nodes. If wireless communication is being used then two nodes are within one hop of each other if they lie within each other's transmission range.

Ad hoc networks may find use, for example, for emergency services coordinating their efforts, business associates sharing information during a meeting, and students using laptop computers to participate in an interactive lecture.

Routing protocols used in ad hoc networks can normally be classed as either "proactive" or "reactive". Proactive routing relies on flooding the whole network with route update information. These update transmissions occur periodically, for example, every 5 seconds. Proactive routing schemes are used for Internet communication. As much of the update information is the same from one update to the next, conventional proactive routing is seen to be too resource intensive for use in ad hoc networks.

In reactive routing schemes a node will only try to locate another node when ii is necessary. This avoids wastage of resources but increases delays in the routing.

The following terms are used in this document, but may be used differently elsewhere. An "originator node" is a node which originates a data packet, intended for a certain "destination node". A node is a "neighbour node" of another node if it is only one hop away, ie within direct transmission range. Likewise, a "2-hop neighbour node" is a node which is two hops away. If the destination node is not a neighbour node of the originator node, the data packet will have to traverse a multi-hop route consisting of "intermediate nodes".

Reactive routing can be summarised as a route discovery cycle. When a node needs a route to a destination node, it will originate some form of request packet, also called a request or request message. This request packet is re-broadcast by each node in the network until it reaches a node which is able to construct a reply for the originating node. Each node which receives the request can form a reverse' route to the origin by storing the address of the previous hop of the request as a next hop to the originator of the request.

A reply can be formed and sent by the destination node itself, or an intermediate node which has knowledge of a route to the destination, since in this latter case it is possible for the originator to route packets to this intermediate node to forward onto the destination. The reply is sent along the reverse' route which has been formed as a result of the request being propagated. Thus, each node which receives the reply can now create a forward' route to the destination of the request, using the node from which the reply was received.

However, reactive routing as currently defined only discovers one forward route or path. The routing table stored by each node only contains one next hop' for each possible destination node, which is typically the neighbour node which sent the request or reply with the lowest hop count. Thus, any break along that path, e.g. due to mobility, will cut any communications between the originator node and destination node. In order to re-establish the route, another route discovery cycle has to be performed by the originator node, as well as possibly by the destination node. Some routing protocols allow for the node upstream of the link break to attempt route discovery itself.

The overhead associated with reactive routing is therefore as follows.

The initial route request is typically re-broadcast throughout a large proportion of the entire network. The majority of these nodes will not receive the reply, and thus will not form part of any useful route. This overhead is present for every route discovery cycle after a link break occurs.

In order to overcome this, various multipath routing protocols have been developed. Multiple routes are also regarded as desirable by those seeking Quality of Service (QoS) guarantees; they allow load balancing, and they enhance the availability of a communication path between the originator and destination (which is appealing from a security viewpoint).

The majority of these multipath routing protocols use the fact that the request is re-broadcast throughout the network, and to enable a node to use the multiple copies of the request it may receive to create several next hops to the originator node. If a node receives a reply, then the reply can be sent to all these recorded next hops'. With multiple route discovery protocols, the formation of loops is a significant risk, so each protocol uses mechanisms to prevent loops from occurring.

Both single and rnultipath routing protocols do not take into account the possibility of non-uniform link latencies which may affect both types of protocols. Differing link latencies may prevent the shortest route from being discovered by a single route discovery protocol, and may also prevent all the routes from being discovered by a multipath routing protocol.

Single route discovery protocols typically look for the route with the shortest number of hops. Using hop count as an indication of route bandwidth and throughput is common in conventional routing protocols for wired networks, and in reactive routing protocols for ad hoc networks. Hop count works well with wired networks because of the high bandwidth associated with wired communication, and also because of the use of proactive routing, where every node will periodically receive route updates. The main cause of delay in such networks is typically the processing of the packet by each node, and so the route with the lowest number of hops is usually the optimum route. However, with wireless communications the differing link latencies can have an effect on whether or not the optimum route is discovered.

Consider the situation shown in Figure 1, where node A needs a route to node Z, and the arrows indicate the propagation of a request. Suppose that, during propagation of the request, the link between nodes B and C is very slow due to the large volume of traffic passing between the two neighbour nodes, at the time at which node B receives the request. In this example, node C receives two requests from nodes B and D. When C rebroadcasts the request, both B and D will ignore the request as they have already processed it.

In this case the route discovered is (A, B, E, F, G, H, Z} with a hop count of 6. However, the shortest route in terms of the number of hops is actually (A, B, C, D, H, Z} with a hop count of 5. Therefore, varying link latencies can prevent the shortest route from being discovered by single route discovery protocols.

With multipath routing protocols, variable link latencies will also affect reactive route discovery. One major objective of the route discovery phase of a multipath routing protocol is to discover as many different routes as possible. Discovering the optimum route is no longer a primary objective, although it is still important. Figure 2 shows the ideal scenario. If the latencies of each link are the same, then two possible routes can be discovered, namely {A, B, C, D, G, Z} and (A, B, E, F, G, Z}. The logical loop (B, C, D, G, F, E} has been divided into two link- disjoint routes.

We now define some terminology relating to the handling of a request by a particular loop in a network. The true loop entry node is the first node in the loop which receives the request, and thus this node rebroadcasts it in both directions round the loop. The true loop exit node is the node which, in the ideal scenario, will receive more than one request and will eventually form part of the route. In Figure 2 node B is the true loop entry node and node G is the true loop exit node. Afrilse ioop exit node is one which receives more than one request but will not form part of the eventual route. This is illustrated in Figure 3.

In Figure 3 the route (B, C, D, G} has lower latency than {B, F, F, G}.

As a result node F receives two requests, and only one of the two possible paths is discovered. Using our terminology, the propagation of the request does not converge on the true loop exit node G, but instead converges on node F, a false loop exit node. In this example, any of nodes C, D, E or F can potentially be false loop exit nodes, depending on the latency of each link involved.

Figure 4 shows that even if all link latencies are the same, certain topologies can introduce the same effects in a multipath routing protocol.

In this example, node F has become the true loop exit node but it will not receive the two requests if each link's latency is the same. Instead node G becomes a false loop exit node, and as a consequence only one route is discovered.

Small modifications to single route discovery protocols can overcome the link latency problem highlighted above. The Ad hoc On-demand Distance Vector (AODV) routing protocol is a reactive protocol which attempts to find the route with the shortest hop count. Therefore it suffers from the problem highlighted in Figure 1. The key reason for this is that a node will never forward a route request if it has already received the very same request. Each route request contains a RREQ ID value which is a counter maintained by the originator node. Thus each node keeps a cache to store RREQ ID values from received route requests which have been broadcast by that originator. This mechanism is then used to discard duplicate route requests which the node has processed within a given period. This is to ensure route requests propagate away from the originator node.

When a node rebroadcasts a route request to its neighbour, and subsequently when the downstream neighbour rebroadcasts the route request, the node can ignore the route request when it finds the matching {originator node, RREQ ID} pair in its cache.

The use of the RREQ ID value means that different link latencies will prevent the shortest path from being discovered as described above.

Thus, the simple modification to AODV is to simply remove the RREQ ID mechanism. This is because the mechanism is actually redundant.

When a node rebroadcasts a route request, it will have a hop count of x.

When the neighbour receives and rebroadcasts the route request, it will have a hop count of x + 1. Therefore, if the node adheres to the AODV protocol, it will ignore and drop the request because it has a higher hop count.

Figure 5 shows the use of the modified AODV protocol, where the route {B, E, F, G, H, D, C} has a slightly faster throughput than the route (B, C}. Hence, node C is a false loop exit node which receives two route requests. It receives the first from node D and creates a reverse route to node A with a hop count of 7. Node C then receives the same route request but from node B. By removing the RREQ ID mechanism, node C processes the second route request. As the route request from node B has a lower hop count of 2, node C records node B as the next hop to the originator node A with the new hop count. It is now essential that node C rebroadcasts the route request so that node D will receive and process it, otherwise node C will never get any packets to forward to node A. Node D will perform the same processes and record a new route using node C as the next hop. When node D rebroadcasts the route request, it will have a hop count of 3. Subsequently node H will use node D as a next hop to node A, and node Z will use node H as a next hop to A. Node Z should also send a route reply which will be unicast along the new, shorter, reverse route. This introduces an overhead as a request can be received twice by the same node, but it discovers the shortest route.

The invention provides for a different way of overcoming the link latency problem by discovering further routes, even if a single route discovery protocol is used.

According to a first aspect of the present invention, we provide a routing method for an ad hoc network comprising two or more nodes, the method comprising: finding at least one first route for a request message sent from an originator node to a destination node via one or more intermediate nodes, with the destination node sending a reply message back via the same intermediate nodes to determine a route from the originator node to the destination node; finding any further routes by sending a reply broadcast message with the reply message, such that every intermediate node sends the reply message only to neighbours on the route, but rebroadcasts the reply broadcast message to all neighbours, until each reply broadcast message has travelled a predetermined number of hops; finding one or more loop check nodes, as any node that received at least two request messages from at least two different neighbours, no reply messages but a reply broadcast message; sending a ioop check message from at least one ioop check node towards the originator node along known routes; finding one or more path recovery nodes, as any node receiving at least two copies of a loop check message from two different neighbours, and which uses at least one but not all of these neighbours as a next hop to the destination node; and sending a path recovery message from each path recovery node to neighbours not used as next hops to the destination node, until a node is reached which has a known route to the destination node.

The routing method is able to overcome the link latency problem by separating loops into two link-disjoint routes, and thus finding further routes from the originator node to the destination node. The method consists essentially of two stages, firstly finding loops by finding the loop check nodes using the reply broadcast messages, using the loop check messages to confirm the presence ofa ioop, and secondly finding the path discovery nodes on the loop and sending the path discovery messages to determine any new routes.

Preferably, the predetermined number of hops for a reply broadcast message from each node is between two and four, in order to minimise traffic on the network. The number could be set to one, or more than four if required.

Preferably, each loop check message is also set to travel a predetermined maximum number of hops. This ensures that the method does not discover very disparate routes. If the nodes in the network are fairly mobile, the number may be set low, so that routes are discovered only from small loops.

The method may also include the step of a delay before a node sends a loop check message. The delay is conveniently variable and may be predetermined according to the type of network.

The invention works using the reactive routing protocols described above, and in fact these must be modified for the invention to operate. For both single and multipath routing protocols, each node must keep a separate record of first routes and further routes. This is preferably achieved by keeping separate route tables, but alternatively could be achieved by adding an extra field to the existing route table which contains a flag indicating if the route is a first route or a further route.

The protocols must also be modified to accommodate the reply broadcast messages, and to ensure that these are sent and handled correctly.

According to a second aspect of the invention, we provide an ad hoc network comprising two or more nodes and operating according to the routing method of the first aspect of the invention.

According to a third aspect of the invention, we provide a node of an ad hoc network operating according to the routing method of the first aspect of the invention.

According to a fourth aspect of the invention we provide software encoded in a machine-readable medium for implementing the method of the first aspect of the invention, or the operation of a node according to the third aspect of the invention.

Various embodiments of the invention will now be described by way of example only, with reference to the accompanying drawings, in which; Figures 1 to 5 are schematic illustrations of the propagation of messages through an ad hoc network in accordance with known protocols; Figure 6 to 9 are schematic illustrations of the operation of the method according to the invention.

The Figures show packets (also known as messages) travelling in a mobile ad hoc network, which comprises a permanent or temporary collection of nodes that can communicate with each other. Such networks operate with routing protocols which determine how the messages travel and by what routes, and the nodes need to maintain tables of the available routes. The protocols need to be able to determine new routes if a known route is broken, for example because a node moves out of range.

The present invention provides a method of making discovery of routes from loops easier, and requires modification of existing route discovery protocols to be able to operate. It will therefore be convenient to start by describing the operation of the existing protocols and the necessary modifications.

The basic routing protocol can be either a single or multipath reactive routing protocol. These protocols operate to discover first routes by sending a request message from an originator node to a destination node via one or more intermediate nodes with the destination node sending a reply message back via the same intermediate nodes to determine a route from the originator node to the destination node. The inventive method includes a further stage - from now on called the Path From Loop Recovery or PFLR protocol - using reply broadcast messages which are used to discover potential loops, with the existence of a loop then being checked by loop check messages, and further routes discovered if possible.

Each type of basic protocol must be modified as follows. Each node must keep a record of first routes (those discovered before the use of the PFLR protocol) and further routes (those discovered afterwards). Separate route tables are kept, or an extra field is added to the existing routing table which contains a flag indicating if the route is a first route.

Each node must also maintain a mechanism to suppress duplicate packets.

One such mechanism is a Control Packet Table as described in Table 1.

The Control Packet Table is used to record the details of every control packet or message which has been sent. This enables a node to reject and drop messages which it has already sent itself.

Table 1 A Control Packet Table entry Packet type The type of control packet that was sent.

Packet originator The address of the packet originator.

Packet sequence number The freshness number from the packet.

Neighbour sent to The neighbour to which the packet was sent Lifetime How long the entry should be kept before deletion.

Each node must also maintain a Reply Broadcast table as in Table 2.

Table 2 A Reply Broadcast Table entry Previous hop The address of the neighbour from which the reply ____________________ broadcast was received.

Sequence number This is the freshness number taken from the corresponding reply broadcast packet.

Number of hops This is the number of hops the neighbour is from the from route optimum route.

Lifetime How long the entry should be kept before deletion.

For reply broadcasts, the destination node replies according to the protocol rules, except that additional reply broadcast messages are sent when a reply message is unicast. The reply broadcast contains exactly the same fields and information as the reply with the addition of two extra

fields described in Table 3.

Table 3 Additional fields of a reply broadcast packet Reply destination This is the originator node of the corresponding request. This is necessary as the destination field of the reply would be replaced by the IP broadcast ____________________ address.

Number of hops This is the number of hops the reply broadcast has from route travelled.

Thus, the reply will be unicast along the reverse route. Every node which unicasts a reply will also broadcast a reply broadcast, incrementing the number of hops from route count. Each neighbouring node which receives the reply broadcast will record the details of the reply broadcast in its reply broadcast table. These neighbours will also rebroadcast the reply broadcast message, if the number of hops from route count is less than a predetermined number of hops defined for the network. This is variable, and can be set as a parameter for the network. Typically, it will be set at two. Therefore, all nodes within the predetermined number of hops of the reverse route will receive a reply broadcast. In order to prevent 1hop loops from forming the node must record the details of the rebroadcast reply in the Control Packet Table.

The AODV protocol is modified to accept the first two route requests it receives. The first route request can be recorded and processed as usual.

If a node receives a second route request, it must first check if the second request was received from a different neighbour to the first request and not from a neighbour to which the node has already sent a route request.

If this is true, then the node should process the route request and use the previous hop, the sending neighbour, as a second next hop to the originator. The node must not rebroadcast the second route request. The node can now mark in its memory that it should run the PFLR protocol, as described below.

In order to allow nodes to accept two route requests, any mechanisms such as the RREQ ID have to be removed or modified. However, the nodes may now be vulnerable to accepting a route request being rebroadcast by its neighbour, a request which the node sent itself, i.e. create a 2-hop loop between two neighbour nodes. Thus, a node must not accept a request from a neighbour node when the node itself has already rebroadcast the request. This information can be maintained in the Control Packet Table, recording what route requests have been sent by recording the originator id of the request, and whatever mechanism is used to guarantee freshness, e.g. sequence numbers.

The final modification is to be made to the delivery of data packets, and not the route discovery phase. When a node receives a packet for forwarding and it has two routes, it can only forward the packet to the neighbour from which the packet was not received. This is a split horizon check present in routing protocols for conventional wired networks, to prevent the packet circulating in a 2-hop loop between two neighbours.

If a multipath routing protocol does not already implement the rules as stated above, then it must be modified to do so. Typically, most reactive multiple route discovery protocols do have mechanisms covering these rules. Thus the protocol must have a mechanism to ensure that route requests are propagated away from the originator node, i.e. prevent I hop loops from forming when a neighbour rebroadcasts a route request.

Further, a node should only attempt the PFLR protocol if multiple route requests from the same route discovery cycle have been received.

Once a node has been marked to attempt loop discovery, then it must do so after a predetermined period. Once this period has expired, the node must meet the loop discovery preconditions before it can continue, and send a loop check message, in accordance with the PFLR protocol. These preconditions are: 1. The node has received two or more request messages from two different neighbours.

2. The node has not been the target of a unicast reply, i.e. the node does not have a forward route to the destination node.

3. The node has received a reply broadcast message.

The first precondition is logical. If the node has a forward route then it must be a true loop exit node, so the ioop has already been discovered as two routes. The third check is an optimisation. Without it, every node in the network which receives two or more request messages will perform loop discovery, even those nodes which are so far away that they will never form any meaningful routes between the originator and destination nodes. The PFLR protocol will only be useful when at least two nodes in the loop form part of the initially discovered route If the loop discovery preconditions are true, then the node may proceed and originate a loop check message. It is then known as a loop check originator node. The loop check message must contain the following information: Table 4 The contents of a loop check message Originator address The node in question.

Destination address The address of the originator of the request.

Freshness number This should be taken from the request message which caused the loop discovery, and may take the form of a nonce, sequence number etc. The loop check originator node must then unicast the loop check message to all routes for the destination, i.e. the originator node. All nodes must only use routes which were discovered before any additional routes have been added from previous cycles of the PFLR protocol.

All nodes which receive the ioop check must use it to create a reverse route to the loop check originator. This creates extra routes, although their usefulness will depend on the network traffic.

When a node receives a loop check message it should record its details in a separate PFLR Table. Each tuple in this table contains the following

fields:

Table 5 A PLFR table entry Loop check originator address The address of the loop check originator ___________________________ node.

Sequence number This is the freshness number taken from ________________________________ the corresponding request message.

Previous Hops A list of neighbours from which the loop check was received.

Lifetime How long the entry should be kept ____________________________ before deletion.

If the ioop check is the first copy received by a node, then the Previous hops' list is updated. The loop check can then be forwarded only if two conditions are met: 1. The hop count has not exceeded a loop check maximum hop value, which is a parameter that can be set.

2. If the node is due to originate its own ioop check messages, then the node must delay forwarding the loop check until it has sent its own loop check messages.

Again, the ioop check message must only be unicast on routes, towards the originator node, and discovered before the PFLR protocol was used.

For any subsequent duplicate loop check messages received from the same originator, the node has to perform the following steps: I. If the loop check message was received from the same neighbour before, as recorded in Previous hop', then the loop check message can be ignored and dropped. 2. If the ioop check message was received from a different neighbour to

that recorded in the Previous hops' list, then the neighbour's address can be appended. The intermediate node can now check the path recovery pre-condition described below. If this has been met, then the node can initiate the second stage of the protocol - path recovery. If the pre-conditions are not met then the node drops the loop check message.

Any subsequent copies of the same loop check message received after the node has initiated the path recovery stage are ignored and dropped.

Those messages are received from routes that are too slow to be considered. The loop check destination node (the originator node) does not forward the loop check once it has received it, but the node must still process the message details as above.

The path recovery preconditions which must be met before a node can begin the path recovery stage are: 1. The node has received the same loop check message from two or more neighbours.

2. The node uses at least one but not all of the loop check previous hops, as a next hop to the destination node, from the original route discovery cycle. The other previous hops not used as a next hop, will be termed as path recovery next hops.

This precondition is only met by a loop entry node which is part of a loop that forms part of the route discovered in the base route discovery protocol. Therefore, a loop entry node which has received no replies from any of the loop check previous hops must be part of loops that are not involved in the base protocol discovered route, and thus there will be no gain from path recovery. If a loop entry node has received route replies from all loop check previous hops, then it is clear that the loops have already been divided into two routes each. In this case the loop check message should not have been originated in the first place, so this could be an indication of an active attack.

A loop entry node which meets the preconditions outlined above must originate a path recovery message. The path recovery message must contain the following information: Table 6 The contents of a path recovery message Originator address The loop entry node in question.

Destination address The address of the loop check originator _________________________ node.

Freshness number This should be taken from the loop ___________________________ check message.

As some of the node's previous hops, from which a loop check message has been received, are a next hop to the request destination, and some of the previous hops are not, the node must unicast the path recovery message to all previous hops which are not a next hop, which will be termed path recovery next hops. The node must also record each path reco'ery next hop, as a next hop to the request destination (i.e. create forward routes).

There are four types of nodes which can receive the path recovery message and process it as follows: 1. Type 1 nodes These are the intermediate nodes on the loop after the loop entry node, and before the ioop check originator node. All of these nodes can identify themselves as they will have received the path recovery message from a neighbour which is not recorded as a next hop to the loop check originator node. These nodes must unicast the path recovery message to all recorded routes to the loop check originator node, and use the next hops to create forward routes to the request destination node. These nodes already have the correct route to the request originator node so there is no need to create any additional reverse routes.

2. Loop check originator node The loop check originator node can identify itself using its own address in the path recovery message destination field. The ioop check originator node will examine all of its routes to the request originator node. A subset of the next hop neighbours will have also sent the loop check originator node a reply broadcast. From this subset the loop check originator node must select those neighbours or neighbour closest to the optimum route. This can be checked in the Reply Broadcast Table, where the node can select all entries matching the lowest hop count that the node has recorded. However, the node must exclude the route, which uses the path recovery's previous hop as a next hop, from this search. The selected neighbours form a subset we will call the path recovery neighbour set. The loop check originator node must unicast the path recovery message to all neighbours in the path recovery neighbour set, and the node must also use the neighbours as next hops to create forward routes to the request destination node. Finally, the node must delete the route or routes to the request originator node which use neighbours from the path recovery neighbour set as the next hop.

3. Type 2 nodes These are the intermediate nodes in the loop in between the loop check originator node and the true loop exit node. They can identify themselves when the following two conditions are both true. Firstly, they do not meet the condition that Type 1 nodes have, i.e. they have received the path recovery message from a neighbour which used is a next hop to the loop check originator node. Secondly, a type 2 node will have also received the corresponding reply broadcast message. These nodes will perform similar steps to the loop check originator node - to create forward routes to the request destination using the neighbours from their own path recovery neighbour set; to forward the path recovery message to these neighbours; to delete all routes to the request originator node which uses these neighbours as a next hop. In addition, type 2 nodes must also create a route to the request originator node, using the path recovery's previous hop as a next hop.

4. True ioop exit node This node can identify itself because it will already have a route to the request destination node as a result of the original route discovery. When this node receives the path recovery message, it will use the previous hop to create an additional reverse route to the request originator node. The node then drops the path recovery message. This signals the end of the current PFLR cycle.

The PFLR protocol is illustrated in Figures 6 to 9. Figure 6 shows node A using a reactive route discovery protocol to find a route to node Z. The number of hops from route count parameter is set as 2. Here, node F is a false loop exit node and receives two copies of the request message and a reply broadcast message. Hence node F will initiate the PFLR protocol and originate and transmit loop check messages along all reverse routes to node A, the originator of the request. This is shown in Figure 7. Node B, the true loop entry node, receives two copies of node F's loop check message (the order is inconsequential). Thus node B originates and transmits a path recovery message, which is propagated as in Figure 8.

Node B chooses the previous hop which is not a next hop to node Z, the destination discovered in the initial route discovery, which in this case is node E. Node B also creates a forward route to node Z using node E as a next hop.

Node E is a type 1 node and thus forwards the path recovery message towards node F. Node F, the ioop check originator node, forwards the path recovery message to node G, creating a forward route to node Z using node G as the next hop (the other route node F has to node A).

Node F can then delete its route to node A which uses node G as the next hop. Node G is a type 2 node so it will forward the path recovery message to node H, the recorded next hop to node A. Node G will also create a forward route to node Z using node H as a next hop, and a reverse route to node A, using node F as the next hop. Finally node G will delete its route which uses node H as a next hop to node A. Node H, the true loop exit node, receives the path recovery message and creates a route to node A using the previous hop, node G. Node H then drops the path recovery message.

The end result from the PFLR protocol is that there are now two paths, between nodes B and H, as shown in Figure 9.

If a node receives a request message from a route discovery cycle which is more recent than the PFLR information that the node has stored, then the node must disregard all information from the old route discovery cycle and reset itself for the new route discovery cycle.

Claims (14)

1. I. A routing method for an ad hoc network comprising two or more nodes, the method comprising: S finding at least one first route for a request message sent from an originator node to a destination node via one or more intermediate nodes, with the destination node sending a reply message back via the same intermediate nodes to determine a route from the originator node to the destination node; finding any further routes by sending a reply broadcast message with the reply message, such that every intermediate node sends the reply message only to neighbours on the route, but rebroadcasts the reply broadcast message to all neighbours, until each reply broadcast message has travelled a predetermined number of hops; finding one or more loop check nodes, as any node that received at least two request messages from at least two different neighbours, no reply messages but a reply broadcast message; sending a loop check message from at least one loop check node towards the originator node along known routes; finding one or more path recovery nodes, as any node receiving at least two copies of a ioop check message from two different neighbours, and which uses at least one but not all of these neighbours as a next hop to the destination node; and sending a path recovery message from each path recovery node to neighbours not used as next hops to the destination node, until a node is reached which has a known route to the destination node.
2. 2. A routing method as claimed in claim 1, in which the predetermined number of hops for a reply broadcast message from each node is between two and four.
3. 3. A routing method as claimed in claim 1, in which the predetermined number of hops for a reply broadcast message from each node is greater than four.
4. 4. A routing method as claimed in claim 1, in which the predetermined number of hops for a reply broadcast message from each node is one.
5. 5. A routing method as claimed in any preceding claim, in which each loop check message is set to travel a predetermined maximum number of hops.
6. 6. A routing method as claimed in any preceding claim, including the step of a delay before a node sends a ioop check message.
7. 7. A routing method as claimed in claim 6, in which the delay is variable.
8. 8. A routing method as claimed in any preceding claim, in which each node keeps a separate record of first routes and further routes.
9. 9. A routing method as claimed in claim 8, in which each node keeps a route table of first routes, separate from a route table of further routes.
10. 10. A routing method as claimed in claim 8, in which the route table for each node has a field containing a flag indicating if the route is a first route or a further route.
11. 11. An ad hoc network comprising two or more nodes and operating according to the routing method of the first aspect of the invention. /
12. 12. A node of an ad hoc network operating according to the routing method of the first aspect of the invention.
13. 13. Software encoded in a machine-readable medium for implementing the method of the first aspect of the invention.
14. 14. Software encoded in a machine-readable medium for implementing the operation of a node according to the third aspect of the invention.