Patent Application
20070286139
The present invention will become more fully understood from the detailed description given herein below and the accompanying drawings which are given by way of illustration only, wherein like reference numerals designate corresponding parts in the various drawings, and wherein:
As discussed in the Background of the Invention section, conventional Ad-hoc On-demand Distance Vector (AODV) networks may not be capable of routing a data packet from a AODV node without an Internet connection to an Internet destination entity, nor can a conventional Internet source entity send a data packet to an AODV node not directly connected to the Internet. Accordingly, example embodiments of the present invention, as will now be described, are directed to an addressing scheme which allows for a routing of Internet messaging to and/or from any desired AODV node(s) within an AODV network through an AODV node within the AODV network having an Internet connection.
In the example embodiment of
In step S500, each of nodes 1, 2, 3, 4 and 5 are assigned an internal address for use in routing within the AODV network 400. Table 1 (below) illustrates an example set of internal addresses for each of nodes 1 through 5.
For example, referring to step S500 of
After the internal addresses are assigned, a spoofing reserve address (SRA) is assigned to identify the AODV network 400 of
After the SRA is assigned, the address resolution protocol (ARP) table and the system routing table are updated. The ARP table is stored at each node within the AODV network 400, and the system routing table is managed by the operating system (e.g. Windows® 2000 professional/server, XP, etc.). Each computer associated with the AODV network 400 and the Internet 430 includes a local system routing table. In a first example, referring to internal devices (e.g., a computer, a mobile phone, internal routers, etc.), the system routing table may only contain some route in the Intranet (e.g., and not to other networks). In an alternative example, referring to border routers (e.g. routers sit on the edge of a network), the system routing table may also include routes to other networks. In our example, all the nodes within the ad hoc network form a subnet, their system routing tables may only contain local routes; while the system routing table of gateway nodes may have non-local routes.
Accordingly, the system routing table may be used by the OS to determine how to route the data packets. At the same time, there is an AODV routing table which is used by AODV routing protocol. AODV nodes typically use AODV the routing table to update the system routing table. However, node 2 includes a module referred to as a network address translator (NAT). The NAT, which is not present in AODV nodes without Internet connectivity, is used to generate a temporary IP address and/or Transport layer port for internal nodes to communicate with external node, e.g. the web server on the Internet 430. The ARP is a TCP/IP protocol used to convert an IP address into a physical address, such as an Ethernet address. Generally, a node (e.g., node 2), wishing to obtain a physical address, broadcasts an ARP request onto the TCP/IP network (e.g., the Internet 430). The node on the network (e.g., the Internet 430) that has the address in the request then replies with its physical hardware address.
In step S510, the ARP table at each node within the AODV network 400 is updated to notify the OS of the MAC address of SRA with an entry as follows:
Also in step S510, the routing table at each node in the AODV network 400 is updated, to allow packets addressed for Internet destinations to be forwarded to the Internet 430, with an entry as follows:
Node 2 receives a data packet in step S515. The data packet received at node 2 in step S515 may be either (i) sent from a node (e.g., node 1, 3, 4, etc., or may originate from node 2 itself) within the AODV network 400 and destined for another node within the AODV network 400; (ii) sent from a node (e.g., node 1, 3, 4, etc., or may originate from node 2 itself) within the AODV network 400 and destined for an internet destination within the Internet 430; or (iii) sent from an Internet source via the Internet 430 and destined for a node within the AODV network 400. Node 2 includes a data packet capture module configured to receive and analyze data packets received in accordance with any of (i), (ii) or (iii). The data packet includes a destination address field, which denotes the intended destination entity. In step S520, node 2 analyzes the data packet to determine whether the destination address indicated by the destination address field of the data packet is known to be within the AODV network 400
An example will now be given regarding how node 2 may determine whether the destination node indicated by the destination address is “known” to be within the AODV network 400. Each node in the AODV network 400 has a local IP address and subnet mask. The subnet mask is used to identify the local IP and the external IP address. For example, a computer may have the IP address 135.252.20.29, the subnet mask 255.255.255.0. Accordingly, an IP address such as 135.252.20.XXX may be used as a subnet IP, and can be reached directly, otherwise, a gateway will help to route the packet to destination. The IP address obtainment may be performed manual or automatically, as is well-known in the art.
If the destination address is known to be with in the AODV network 400, node 2 forwards the data packet to the destination node using a conventional AODV routing process (e.g., see conventional
In step S530, node 2 forwards the received data packet to the Internet 430. At this time, node 2 will not run the AODV route discovery procedure because the IP address is known to be an outside IP address and the data packet has already forwarded to node 2. If the destination of an incoming packets is within the Internet, the data packet is captured by the NAT module (e.g. which may be included within Windows® server) on node 2, which generates and assigns a temporary external IP address and/or transport layer port for the incoming packet. The packet is forwarded to the network interface (e.g. an ethernet card) connected to the Internet 430. If node 2 wants to send a packet to the Internet, the packet is processed in the same way as a incoming packet.
In step S600, node 4 determines whether to send a data packet to a destination out-of-network with respect to the AODV network 400, such as an Internet destination entity within the Internet 430. If node 4 determines to send the data to an out-of-network destination, the process advances to step S605. If the AODV module captures packets which are destined to an external network (e.g., Internet 430), these packets are buffered. The AODV module initiates a gateway finding procedure to find the gateway to the external network. The gateway finding procedure is similar to the RREQ/RREP procedure with the exception that the destination IP address is set to 0.0.0.0, such that only the gateway can reply to the RREQ. After the gateway is found, node 4 will update the local routing table and forward the buffered packets.
In step S610, node 4 forwards the data packet to node 2 (e.g., after passing through intermediate node 1) using well-known “internal” AODV routing protocols, for example, those described above with respect to
Node 2 receives and processes the data packet in accordance with the above-described process of
In step S700, an Internet entity (e.g., a computer, a mobile telephone, etc.) connected to the Internet 430 determines whether to send or reply to a data packet to one or more nodes within the AODV network 400. In an example, the Internet entity may determine to send a data packet to the AODV network 400 in response to a request for information or other type of data packet received from one or more nodes within the AODV network 400. If the Internet entity determines to send the data packet to the AODV network 400 (e.g., in response to a request for information sent by one or more of the nodes within the AODV network 400), the Internet entity sends the data packet(s) to the gateway the same way as sending packet to any other destinations using well-known Internet routing protocols in step S705. Upon receiving the packet, the NAT module on node 2 captures the packet and routes the received packet to a designated destination AODV node. Accordingly, in step S710, (1) the data packet is routed to node 2 with well-known Internet routing protocols, (2) the routed data packet is processed by the NAT module at the node 2. The NAT module processing includes converting he IP address in the packet header to a corresponding AODV IP address (e.g. 10.0.0.4). The NAT IP address conversion table is generated when AODV node initiate the connection to the external network (e.g., Internet 430). Next, in step S710, (3) the OS at the Node 2 searches the system routing table and find the route to the destination node (e.g. node 4). This route is generated when node 4 initiate the gateway finding procedure.
Node 2 receives and processes the data packet in accordance with the above-described process of
Accordingly, it will be appreciated that AODV nodes without direct Internet connections may effectively become Internet-connected (e.g., for uploads of data packets to the Internet and/or downloads of data packets from the Internet), so long as at least one node within an AODV network has an Internet connection, with the above-described example AODV routing protocols.
Example embodiments of the present invention being thus described, it will be obvious that the same may be varied in many ways. For example, while particular AODV internal addresses (e.g., 10.0.0.1, 10.0.0.2, etc.), subnet masks (e.g. 255.255.255.0), IP addresses (e.g., 10.255.255.254) and MAC addresses (e.g., 00-40-96-54-CF-|OCi|) are given above, it is understood that these are intended to represent examples only and other example embodiments of the present invention may be configured for any appropriate address designation. Also, while the AODV network 400 illustrates five (5) nodes and one (1) node (i.e., node 2) having a connection to the Internet 430, it is understood that other example embodiments of the present invention may be directed to AODV networks having any number of nodes and also with any number of nodes having Internet connections.
Further, while example embodiments of the present invention are described above as being applied within an AODV routing protocol, it is understood that other example embodiments may be directed to any type of routing protocols for Mobile Ad-Hoc Network (MANET), and is not necessarily limited to AODV.
Such variations are not to be regarded as a departure from the example embodiments of the invention, and all such modifications are intended to be included within the scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 200610091682.7 | Jun 2006 | CN | national |
