WO2012165938A1

WO2012165938A1 - Neighbour discovery-based routing method for wireless networks

Info

Publication number: WO2012165938A1
Application number: PCT/MY2012/000108
Authority: WO
Inventors: Reza Khoshdelniat; Gopinath Rao Sinniah; Zeldi Suryady KAMALURRADAT
Original assignee: Mimos Berhad
Priority date: 2011-05-27
Filing date: 2012-05-25
Publication date: 2012-12-06
Also published as: MY157257A

Abstract

A method of routing communication on-the-go in a wireless mobile network comprising of a plurality of mobile sensor nodes is disclosed. The method comprises enabling each node to gather information on its neighbouring nodes and store the information in the nodes' Neighbour List Table comprising neighbouring nodes' addresses, hop distance and intermediate neighbours' address. The information gathered may then be shared amongst neighbouring nodes. Using the gathered and/or shared information, a route to a destination node is determined. The route determining step is considered within a predetermined maximum number of hops through the neighbouring nodes. If communication link to the destination is broken, the gathered and/or shared information may be optionally updated. Next, a message received at said each node is determined whether it is destined for itself or to be onwardly routed to next neighbouring node. After this determination, the message is sent to the destination or intermediate node.

Description

Neighbour Discovery-based

Routing Method for Wireless Networks

TECHNICAL FIELD

This invention relates generally to wireless communication networks, particularly wireless networks comprising mobile sensor nodes. More specifically, it concerns a method for routing communications through a plurality of mobile sensor nodes dynamically forming a network by discovery of neighbouring nodes.

BACKGROUND ART

In a static network, the sensor nodes do not move and their positions are static within the network. Routing protocols for static networks are thus designed to create a communication route between nodes having fixed positions and the gateway. The created route remains unchanged for the duration of network's operation. In a wireless sensor network, however, the sensor nodes may be static or mobile. Thus, a route established between sensor nodes to a destination may no longer be optimum or efficient, or may not even work as the nodes changes their positions. Moreover, as the direction and speed of movement of the nodes can be unpredictable, the routing protocols designed for static networks, which may be classified as (i) hierarchy-based, (ii) location-based and (iii) cluster-based routings, are not applicable for mobile network communication.

Various protocols have been designed to enable communication routing for mobile wireless sensor networks which general concept of allowing IPv6 packets to be sent to and received from PANs (Personal Area Networks) is commonly abbreviated to 6L0WPAN or IPv6 over Low-Power Wireless Personal Area Networks. FIGURE 1 (Prior Art) shows a simplified schematic diagram of a typical 6L0WPAN network. The field deployment of IPv6 low power wireless private area network (6L0WPAN) is well-known and actively pursued such that an IEEE standard, i.e. IEEE 802.15.4, has been established therefor. Commercially available platforms includes Arch Rock's (U.S.A.) PhyNet (release 2007) implementation - which includes its proprietary sensor node, router and server, Sensinode's (Finland) NanoMesh multihop forwarding algorithm using its proprietary Nanostack API which includes neighbour and routing tables, and Jennie's (U.K.) JenNet are readily available.

Other examples of protocols for 6L0WPAN include LOAD (acronym from 6L0WPAN Ad hoc On-Demand Distance Vector such as that described by Vladimir Iliev (2007) DYMO-low (from Dynamic MANET On-demand for 6L0WPAN) such as that proposed by Iliyan Zarov (2007)², and LoWMob such as that described by Gargi Bag (2009)³. Conventional routing protocols designed for mobile networks can be categorized as host-based, network-based and hybrid between the two. In a host- based routing protocol, the mobile sensor nodes are responsible for the routing of the packets. Complex computation and heavy processing are required for routing and forwarding the message by the mobile nodes. In network-based routing protocol, the mobile sensor nodes are not involved with the routing of the packets. Instead, certain static sensor nodes are deployed in the network as cluster heads or mobility support points which form the basis for routing the packets from the sensor nodes to the destination.

The network-based protocols' advantage is that the sensor nodes are not involved with the routing and as such they need not consume power for the message routing and transmission computations. However, as explained above, extra sensor nodes need to be deployed in the form of mobility support points which involves additional costs. Host-based network, on the other hand, do not require extra sensor nodes to be deployed as mobility support points but since its sensor nodes are involved with the routing computations and message transmissions, they will consume extra power. In addition, present mobile wireless sensor networks have several other disadvantages. For one, they require Boarder Nodes (BN) in order to detect new nodes moving into the PAN. These nodes do not monitor the network environment and do not participate in the message routing. As such, deploying extra sensors around the PAN will only increase the cost of deployment. Another disadvantage is that location-based routing protocols require knowledge of the nodes' location. In order to detect the location of the nodes, Global Positioning System (GPS) sensing may be required.

Installing a GPS transceiver on each of the sensor nodes may be required, thus increasing costs as well as power consumption. Alternative geo-positioning methods might include triangulation method or based on the rate of change of radio frequency channel called "motion-inferred link metric" proposed in U.S. Application No. 2008/0291843 (Harris Corp). All these methods require extra message transmission and computation burden on each of the sensor nodes.

On demand or ad hoc discovery of neighbouring nodes has been proposed in U.S. Patent No. 7,349,360 (Gaton Corp.) for ad hoc, low-rate wireless personal area network (LRWPAN). In this patent, a simple, low-cost incremental source routing is employed. Discovery is limited to immediate neighbours or single hop. Upstream and downstream routing methods are separately provided with downstream routing relayed by a network coordinator (NC) while the network devices (NDs) merely function as repeaters. U.S. Patent No. 7,330,694 (Samsung Electronics) teaches another ad hoc route discovery method for mobile networks using conventional Ad hoc On demand Distance Vector (AODV) protocol, especially with its route request, reply and error (RREQ, RREP and RERR) messages. Only upon the route path discovery of a leg is completed would the original RREP be transmitted. For purposes of clarity, in this specification, "message" is to be understood as the "data message" which comprises the data or payload to be transmitted through the network. This is to be distinguished from the "protocol messages", where necessary, such as RREQ, RREP, RERR and like messages. Hence, "message" is to be understood contextually as either protocol or data message, or one in which both are combined.

Multi-hop sensor networks have also been proposed such as by Microsoft in its U.S. Patent No. 6,990,080 which directional topology is based on cone spatial coverage which includes a number of phases, thereby increasing complexity of the routing protocol and the need for more computation. Moreover, this prior art method also provides for control over optimal transmission power and coverage independently of positional information. It should also be noted that for multi-hop topology having a higher number of hops, such as 5-hop string route discovery tried by Zarov (2007, pages 14—16), the performance has been found to be unreliable.

SUMMARY OF INVENTION

It would be desirable that a new routing for wireless mobile network be provided which avoids the aforesaid prior art methods of completing route discovery before the message is transmitted according to the charted route. In a dynamically mobile network, some or all of the sensor nodes could have moved from their positions when the route discovery is completed and the message begins to be routed. Thus, the charted route's string of hops could have been broken or may no longer be the most efficient one.

It would also be desirable to have a routing method which does not rely on the positional information of the sensor nodes such as its GPS coordinates. It is further desirable that the route discovery could be carried out on on-the-fly or on-the-go basis. Such impromptu route decision-making does not thus require route discovery to be completed before sending a message to its destination. Our proposed method also endeavours to use a reactive algorithm so as to reduce processing and message transmission rate in order to save power consumption.

In accordance with a general embodiment of our invention, there is provided a method of routing communication on-the-go in a wireless mobile network comprising of a plurality of mobile sensor nodes, wherein the method comprises of the following steps:

(a) enabling each node to gather information on its neighbouring nodes;

(b) sharing said information gathered by said each node with said neighbouring nodes;

(c) using said gathered and/or shared information to determine a route for communicating message to a destination node;

(d) optionally updating said gathered and/or shared information if communication link to said destination is broken; (e) determining whether a message received at said each node is destined for itself or to be onwardly routed to a next neighbouring node;

(f) sending a message to said node via the determined route;

whereby said route determining step is considered for a predetermined maximum number of hops through said neighbouring nodes.

In one aspect of the invention, step (c) of our aforesaid method, i.e. the step of determining a route for communicating the message may be based on each node being aware of neighbouring nodes that are at least 2 hops away from said each node. The maximum number of hops may be determined by the formula:

MaxHop≥^- wherein:

R is the average coverage range of the transmitter on the sensor nodes; and dmax is the maximum distance that can happen between two sensor nodes in the network field.

In a second aspect, step (a) of our afore-described method, i.e. enabling each node to gather information on its neighbouring nodes, said step includes creating a Neighbour List Table (NLT ) on each node, said NLT comprising at least of (a) a "Neighbour" field wherein neighbouring nodes' ID and/or address may be stored; (b) a "Hop" field wherein the distance to a specific neighbour in number of hops may be stored; and (c) a "Next Hop" field wherein the intermediate neighbour node's ID and/or address. In a third aspect, the neighbouring nodes are discovered by broadcasting a neighbour discovery request message by each node in the network and replying with a neighbour discovery reply message. Preferably, the neighbour discovery request and reply messages are received from neighbouring nodes and their respective ID and/or address are recorded in the NLT, and the number of hops which is one for direct neighbours in the "Hop" field of said NLT.

In a third aspect of our method, the sending of message to a destination node comprising the steps of searching within the NLT for the destination node ID and/or address, sending the message to the destination node if said destination node is a direct neighbour and then awaiting acknowledgement message (ACK), retrying for K times resending the message to the destination node if ACK is not received, sending the message to the intermediate node if the destination node is an indirect neighbour and awaiting for ACK to be received, retrying for K times to send the message to the intermediate node if ACK is not received from the intermediate node, performing an NLT update if the ACK is not received and then resending the message, broadcasting the message to the direct neighbours in NLT if the ID and/or address of the destination node is not in the NLT.

In a fourth aspect, the data message received by a node is determined as to whether it is destined for the node itself or to be routed to another node as destination node includes the steps of determining if the number of hops the received message travelled has reached the threshold MaxHop, routing the data message to the destined node if the destined node is in the NLT; and discarding the data message if the destined node is not in the NLT and the number of hops the message has travelled has reached the MaxHop threshold.

In a fifth aspect, the sending of a received data message at a node to the destination node comprises of the steps of:

(a) sending an ACK to the sender of the message;

(b) determining whether the destination node ID and/or address is within the NLT;

(c) sending the data message to the direct neighbour if the destined node is in the NLT and is a direct neighbour, and awaiting receipt of ACK;

(d) retrying for f times to send the data message if ACK is not received;

(e) sending the data message to the intermediate neighbour if the destined node is an indirect neighbour and awaiting receipt of ACK;

(f) retrying for K times to send the data message to the intermediate node if the acknowledgement message is not received from the intermediate node;

(g) performing NLT update if ACK is not received, and resending the data message; and

(h) broadcasting the data message to the direct neighbours in NLT if the ID and/or address of the destination node is not in the NLT. In a sixth aspect of our invention, the NLT table is updated upon a link to a neighbouring node is broken, said update includes performing neighbour discovery by broadcasting the data message to the direct neighbours in the NLT if the ID and/or address of the destined node is- not in the NLT.

LIST OF ACCOMPANYING DRAWINGS

The advantages and various features of our invention may be better understood by referring to the accompanying drawings, which are listed in the following, in conjunction with the detailed description below as exemplary and non- limiting embodiments of our method.

FIGURE 1 (Prior Art) shows a simplified schematic diagram of a typical 6L0WPAN wireless sensor network.

FIGURE 2 illustrates an example of a mobile wireless sensor network wherein a plurality of sensor nodes is shown to be in connection with each nodes' immediate neighbour.

FIGURE 3 exemplifies a mobile wireless sensor network wherein a message is to be routed from a Source Node 6 to Destination Node (Gateway).

FIGURE 4 is a graphical representation of certain parameters embodied in the calculation of MaxHop or maximum number of hops according to our invention.

FIGURE 5 embodies a simplified schematic diagram of the general process flow of our method. FIGURE 6 shows a detailed logic flowchart of the method which is schematically divided into neighbour discovery/NLT sharing and message routing stages. DETAIL DESCRIPTION OF EMBODIMENTS

We have now proposed a method for routing messages in mobile wireless sensor networks that is based on neighbour discovery. Our proposed routing method for mobile wireless network is based on the assumption that the network is a trusted and secured communications network and that security is not an issue.

Broadly speaking, our invention comprises a method for routing communications on-the-fly in a wireless mobile network which may comprises of a plurality of mobile sensor nodes. As an overview, our method first enables each of the sensor nodes to gather information on its neighbouring nodes and to share the gathered information with each other. As would be explained later, this sharing would again be carried out as an updating exercise upon a link forming part of a route to the destination node being broken. Based on the information gathered or shared, our method then proceeds to determine a route for communicating a message to a destination node. If it is detected that a link forming part of the determined route has been broken (e.g. when a mobile node moves away), the information on the neighbouring nodes are again gathered, updated, and shared. Next, each node receiving a message will determine whether a message received is destined for itself or to be onwardly routed to a next neighbouring node.

For ease of reference, we have in the following described the details of our proposed routing protocol in 3 main stages or phases, i.e. (i) neighbour discovery phase, (ii) Neighbour List Table (NLT) sharing phase, and (iii) message routing phase. The information gathered on the neighbouring nodes may preferably be organised and structured into a table form and named Neighbour List Table (NLT) to be stored at each node. The NLT preferably comprises at least of the following fields: (a) a "Node" field wherein neighbouring nodes' ID and/or address may be stored - the address stored may be a direct or indirect neighbour;

(b) a "Hops" field wherein the distance to a specific neighbour in number of hops may be stored; and

(c) a "Next Hop" field wherein the intermediate neighbour node's ID and/or address. Neighbour Discovery Phase

Our method requires each sensor node to perform a neighbour discovery in order to discover the presence of its neighbours. FIGURE 2 illustrates an example of a mobile wireless sensor network comprising a plurality of sensor nodes whereby each of the nodes is shown to be in connection with its immediate neighbours by straight lines, i.e. the nodes that are in each other's coverage range are shown to be in connection with a straight line in between the nodes.

The neighbouring nodes discovery process starts by each node broadcasting a neighbour discovery request. The nodes will first perform neighbour discovery via the following process. This includes having each node broadcasts a neighbour discovery request (NDREQ) message. Any node that receives the NDREQ message will then reply back with a neighbour discovery reply (NDREP) message. The nodes that receive the NDREQ and NDREP will add the address of their neighbours into a Neighbour List Table (NLT). The ID and/or address here refer to a unique identifier of the sensor node rather than the geo-positional information of the node. Examples of such unique identifier may be the MAC address or IP address as such identifiers are unique and does not change within a single PAN even when the location or position of the node changes.

Accordingly, addresses of the sensor nodes comprising such unique identifiers are included in the NDREP and/or NDREQ to be added to the NLT by the nodes receiving the discovery requests. The NLT for the nodes in the network of FIG. 2 is shown in Table 1 below.

Table 1

NLT of the nodes after neighbour discovery

7 7 7 7 7 1 7

8 8 8 8 8 8

9 9 9 9 9 9

A A A A A A

B B B B B B

G G 1 G G G G

As shown in FIGURE 2 and TABLE 1, node 1 will discover node 2 as its neighbour and will add node 2 to its neighbour hst; and correspondingly, node 2 will add node 1 to its NLT. Node 2 will add node G, 5 and 3 to its NLT as well, and node 5 and 3 will add node 2 to their NLT. The same process continues for all the other nodes. If a node receives a neighbour discovery message from another node which it already has the unique identifier or address in the NLT hst as a direct neighbour, it will discard the neighbour discovery message. This is performed to avoid redundant neighbour discovery and message transmission in the network.

After the neighbour discovery phase, the sensors will share their NLT with their neighbours. Thereafter, each node will have information about neighbour nodes that are two hops away. By knowing the nodes that are at least two hops away, the nodes have a better ability to route the packets to their destinations. From the table structure in TABLE 1 above (as well as TABLE 2) below), the NLT size is simple and does not take up much memory overhead for the sensor nodes. Moreover, as will be seen from the detailed description of the NLT updating below, each time a sensor node performs an NLT update, the new neighbour list will replace the old list and thus there is no additional memory consumption as well. NLT Sharing

After the neighbour discovery is performed, the nodes will start the second phase which is sharing their NLT with their neighbours. Each node will broadcast the NLT information to its neighbouring nodes by sending its NLT to the nodes Hsted in its NLT as well as receiving NLT information from neighbouring nodes. Node 2 will send its NLT to node 1, which will then have the knowledge that nodes G, 5 and 3 are two hops away. Therefore, node 1 knows that in order to send a packet to nodes G, 3 and 5 the packet must be sent to node 2 and node 2 will forward it to them. When the nodes share their NLT, the NLT will include information about nodes which are two hops away.

The NLT table for the nodes in FIGURE 2 after NLT sharing is shown in

Table 2

Neighbour Discovery 2 PI:

NLT table of the nodes after NLT sharing

Node 7 Node 8 Node 9 Node A Node B

Node Hops Next Node Hops Next Node Hops Next Node Hops Next Node Hops Next

1 1 1 1 1

2 2 5 2 2 2 2

3 2 5 3 3 3 3

4 4 4 4 4

5 1 5 2 7 5 5 5

6 2 5 6 6 6 6

8 1 7 1 7 2 8 7 2 8 7

9 2 8 9 1 8 1 8 1 8 2 A

A 2 8 A 1 A 2 8 9 2 8 9

In Table 2, the "Node" field indicates all the nodes that may be direct or indirect neighbours to the Node under consideration. The "Hops" field defines the number of hops distance to the neighbouring node which is a direct neighbour. The "Next" field defines the intermediate neighbour between the node and its indirect neighbour which is two hops away. Each node will record the path to other nodes with the least hops. If one node such as node A has a direct link with node B, then node A will record node B in its NLT which is 1 hop away. If during NLT sharing, node A receives a NLT which defines another path to node B which is 2 hops away, then node A will not consider that path since it is longer than the initial record which is one hop away. If a node receives a NLT sharing message from a node which has a unique identifier, ID or address that is already in the NLT list as a direct neighbour, it may discard the NLT sharing message. This is done to avoid redundant NLT sharing and message transmission in the network.

Message Routing

To distinguish between request messages (such as NDREQ) and payload messages, i.e. the message to be routed to a destination node, we shall refer to the latter as "packet" where appropriate. Upon completing the NLT sharing phase, the nodes are ready to route the packets to their destination. Prior to sending a packet, the source node will check whether the destination node is listed in its NLT. This is done by searching within the NLT for the destination node ID and/or address.

If the destination node is in its NLT and is a direct neighbour, i.e. one hop away, the source node will forward the packet to the destination node and await for an acknowledgement that the packet has been received. Upon receiving the packet, the neighbouring node (which in this case is also the destination node) will then send an acknowledgement message (ACK) to the source node that the packet has been delivered successfully. The source node may preferably be set to wait a predetermined period of time (time-out) before resending the packet or message. Preferably still, the source node may also be set to retry sending for a predetermined number of times (K times) if ACK is not received. A break may be considered as detected when the source node broadcasts a data message and does not receive an acknowledge message (ACK) from the neighbours. Alternatively, when the node sends a unicast data message to its neighbor and does not receive an ACK.

If ACK is not received from the intermediate node within the preset time-out, the message will then be sent to the intermediate node and similarly will await the receipt of ACK from that intermediate node. The source node may also be set to retry sending for a predetermined K times if ACK is not received. If the attempt to transmit to the intermediate node is also determined to have failed, then an NLT update will need to be performed and the message be attempted to be transmitted again. The message will be broadcast to the direct neighbours in the NLT if the ID and/or address of the destination node is not in the NLT. If the destination node is found to be two hops away in the source node's NLT, the source node will send the packet to the intermediate node listed in the NLT. The intermediate node will then send a acknowledgement message (ACK) to assure the source node that the packet has been successfully delivered. If the source node cannot find the destination node in its NLT, it will broadcast the destination node address to its neighbours. The neighbours to the source node will send ACK to the source node to acknowledge receipt of the request and each of these neighbour nodes will then check their respective NLT if it has the destination node address. Each message has a sequence ID. When a node receives a message, it will record the sequence ID and the source address associated to the sequence ID. if the node receives another message with the same sequence ID and the same source address, it means that the message has been resent or replayed so it will discard the message.

If a node receives a message with the same sequence ID, it will discard the message in order to avoid repeating the message and thus prevent it from flooding the network. If the neighbour nodes are unable to find the destination node address in their NLT, then each one of these neighbouring nodes will in turn broadcast the message comprising the destination node address to their neighbours as well and receives ACK from their neighbours accordingly. This process is thus repeated such that the message is propagated through the nodes of the network until the destination node is found in the NLT of one of the nodes. When a neighbour node finds the destination node address in its NLT, they will forward the packet to the destination node, thus completing the route. MaxHop

An important feature of our invention in respect of determining a route for message transmission is based on each node being aware of its neighbouring nodes that are at least 2 hops away. The maximum number of hops that may be considered by our method is determined by MaxHop number, i.e. the maximum number of hops that a message may be broadcasted before it reaches a node which has the destination node address in its NLT.

By way of example in FIGURE 3, if Node 6 wants to send a message to the gateway G, as the destination, the number of hops that a complete route would take is 4, i.e. from Node 6 to 5, 2, 7 and then to G. Node 6 checks its own NLT and found that it does not have node G in its NLT. Hence, it will broadcast the message to its neighbour nodes which includes Node 5. Node 5 receives the message and, upon not finding Node G in its NLT, will then broadcast the message to its neighbours, Nodes 2, 4 and 8.

Upon receiving the message, Nodes 2, 4 and 8 will check their own NLT for the destination node G. Node 2 then finds node G's address in its NLT and sends the packet to Node 7 which will forward the packet to the destination node G to complete the route. In this example of FIG. 3, if MaxHop is set to 2, then upon the packet reaching Node 5, it will not be forwarded anymore as it takes more than 2 hops to discover destination node G. Therefore, the MaxHop number should be calculated appropriately based on the field size and the coverage range of the nodes' wireless transmitters.

FIGURE 4 shows a graphical representation of parameters embodied in the calculation of MaxHop or maximum number of hops allowed for a message to be sent or travel through nodes until it reaches a node that has the destination node address in its NLT. By ensuring that a message will not be sent via a number of sensor nodes more than the predetermined MaxHop number, message flooding of the network may be prevented. In order to calculate the optimized MaxHop, the following formula may be used:

MaxHop >

R

wherein:

R is the average coverage range of the transmitter on the sensor nodes; and dmax is the maximum distance that can happen between two sensor nodes in the network field. In short, upon receiving a message, the node will determine whether it is destined for itself or to be routed to another node as destination. The manner in which the node makes such determination includes firstly determining if the number of hops through which the received message has travelled has reached the threshold MaxHop number. Next, the message is routed to the destination node if the destination node is in the NLT of the said node under consideration. The message is discarded if the destination node is not in the NLT and the number of hops the message has travelled has reached the MaxHop threshold.

The general process flow of our proposed neighbour discovery-based routing is shown schematically in FIGURE 5. A detailed logic flowchart of our method is shown in FIGURE 6 which roughly divides our invention into 2 main stages, i.e. (i) Neighbour Discovery and NLT sharing at the upper half, and (ii) Message Routing at the lower half of the flowchart diagram. Updating NLT

Whilst there is provision in our routing protocol to update the NLT, further explanation of the updating should now be provided. As the sensor nodes may move in a mobile wireless sensor network, the links between some of the nodes may break as the nodes move. When a link breaks, that link can no longer be used to route the message to the destination node. Hence, the mobile node should update its NLT to reflect the new situation of its neighbours. In order to update the NLT, the node will perform the process of neighbour discovery and then share the NLT with the new neighbour nodes. This is done by broadcasting the message to the direct neighbours in the NLT if the ID and/or address of the destined node is not in the NLT. Upon receiving the NLT information from neighbouring nodes and updating the number of hops distance in the "Hop" field and adding the ID and or address of the intermediate neighbour node to the "Next Hop" field in the NLT.

The NLT updating in our proposed protocol is reactive, i.e. updating is only carried out in the event that a link to the destination node or an intermediate node is broken. As such, being a reactive process, the NLT updating saves on power consumption, computation and message overhead. This reactive mode is in contrast with conventional proactive method whereby the sensors will update their NLT periodically regardless of whether the link to the neighbours is broken or not.

An advantageous feature of our proposed method is, whilst a mobile sensor node might lose its connection with some of its neighbours, as long as the particular connection to route the specific packet to the specific destination node is still working, it is not necessary to update the NLT. This is because that the links that are being broken are not going to be used for that specific route and it therefore makes no impact on the routing of the specific packet. Accordingly, having a demand-based or NLT update reduces traffic and increases the efficiency of the routing algorithm.

Apart from the afore-described advantages of routing on-the-go, minimal memory requirement, low power consumption and setting of maximum hops to limit broadcast of redundant messages, our proposed routing method also requires less number of transmissions compares to conventional methods such as DYMO-LoW, LOAD, LoWMOB and DLoWMOB. Although our present neighbour discovery-based routing method has been specifically designed for wireless mobile network, it is apparent to a skilled person that it is also applicable to static wireless sensor networks with minimal or no modifications.

These variations, modifications, alternatives or equivalents may not have been specifically mentioned herein but which a person having ordinary skill in the art would recognize and be able to adapt, vary, modify or improvise thereon based on the working principle or concept disclosed herein. Moreover, there may be many other optional, alternative or additional features which may be used in conjunction with the aforesaid wireless transmission features to complement, enhance or improve their respective functions which, though not specifically described here, are to be understood as encompassed within the scope and letter of the claims hereinafter.

_***

LIST OF NON-PATENT REFERENCES

¹ Vladimir Iliev, "Mesh Routing for Low-Power Mobile Ad-Hoc Wireless Sensor Networks Using LOAD', Guided Research Paper, Jacobs University Bremen,

Germany, 15 May 2007.

² Iliyan Zarov, "Mesh Routing for Low-Power Mobile Ad-hoc Wireless Sensor Networks Using DYMO-low" , Guided Research Paper, Jacobs University Bremen, Germany, 15 May 2007.

³ Gargi Bag, "LoWMob: Intra-PAN Mobility Support Schemes for 6L0WPAN', Sensors 2009, www.mdpi.com/ journal/sensors. 23 July 2009.

Claims

1 A method of routing communication on-the-go in a wireless mobile network comprising of a plurality of mobile sensor nodes, said method comprising:

(a) enabling each node to gather information on its neighbouring nodes;

(d) optionally updating said gathered and/or shared information if communication link to said destination is broken;

(e) determining whether a message received at said each node is destined for itself or to be onwardly routed to a next neighbouring node;

(f) sending a message to said node via the determined route;

2 A method of routing communication on-the-go in a wireless mobile network according to Claim 1 wherein the step (c) of determining a route for communicating the message is based on each node being aware of neighbouring nodes that are at least 2 hops away from said each node.

3 A method of routing communication in a wireless network according to Claim 2 the maximum number of hops is determined by the following formula:

wherein:

4 A method of routing communication in a wireless network according to Claim 1 wherein the step (a) of enabling each node to gather information on its neighbouring nodes includes creating a Neighbour List Table (NLT ) on each node, said NLT comprising at least of

(a) a "Neighbour" field wherein neighbouring nodes' ID and/or address may be stored;

(b) a "Hop" field wherein the distance to a specific neighbour in number of hops may be stored; and

(c) a "Next Hop" field wherein the intermediate neighbour node's ID and/or address.

5 A method of routing communication in a wireless network according to Claim 4 wherein the neighbouring nodes are discovered by broadcasting a neighbour discovery request message by each node in the network and replying with a neighbour discovery reply message;

and wherein the neighbour discovery request and reply messages are received from neighbouring nodes and their respective ID and/or address are recorded in the NLT, and the number of hops which is one for direct neighbours in the "Hop" field of said NLT.

6 A method of routing communication in a wireless network according to Claim 4 wherein the sharing neighbouring nodes' information with other neighbouring nodes comprising the steps of

broadcasting the NLT information to the neighbouring nodes and performing the NLT sharing, and

receiving the NLT information from neighbouring nodes and updating the number of hops distance in the "Hop" field and adding the ID and/or address of the intermediate neighbour node to the "Next Hop" field in the NLT.

7 A method of routing communication in a wireless network according to Claim 4 wherein the sending of message to a destination node comprising the steps of:

(a) searching within the NLT for the destination node ID and/or address;

(b) sending the message to the destination node if said destination node is a direct neighbour and then awaiting acknowledgement message (ACK);

(c) retrying for K times resending the message to the destination node if ACK is not received; (d) sending the message to the intermediate node if the destination node is an indirect neighbour and awaiting for ACK to be received;

(e) retrying for K times to send the message to the intermediate node if ACK is not received from the intermediate node;

(f) performing an NLT update if the ACK is not received and then resending the message;

(g) broadcasting the message to the direct neighbours in NLT if the ID and/or address of the destination node is not in the NLT.

8 A method of routing communication in a wireless network according to Claim 4 wherein the received data message is determined as to whether it is destined for itself or to be routed to another node as destination node includes

determining if the number of hops the received message travelled has reached the threshold MaxHop;

routing the message to the destined node if the destined node is in the NLT; and

discarding the message if the destined node is not in the NLT and the number of hops the message has travelled has reached the MaxHop threshold.

9 A method of routing communication in a wireless network according to Claim 4 wherein the sending of a received data message at a node to the destination node comprises of

(a) sending an ACK to the sender of the message;

(d) retrying for K times to send the data message if ACK is not received;

(g) performing NLT update if ACK is not received, and resending the data message; and (h) broadcasting the data message to the direct neighbours in NLT if the ID and/or address of the destination node is not in the NLT.

10 A method of routing communication in a wireless network according to Claim 4 wherein the NLT table is updated upon a link to a neighbouring node is broken, said update includes performing neighbour discovery by broadcasting the data message to the direct neighbours in the NLT if the ID and/or address of the destined node is not in the NLT.

^■k k-