IP Library › Granted Patent US 12,376,000
Granted Patent B2
US 12,376,000 · App. 17/846,712 · Granted Jul 29, 2025

Multipath geographic routing protocol

Inventor: Paulo Mendes (Munich, DE)
Assignee: Airbus (S.A.S.)
H04W40/246H04W40/06H04W40/20H04W48/16H04W48/20H04W84/18H04W88/08
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 12,376,000
App. No.
17/846,712
Granted
Jul 29, 2025
Kind
B2
Abstract

Systems and methods for routing data packets in mobile ad-hoc networks. An interest packet is sent from a data consumer to a data producer via multiple intermediate routing devices. The interest packet is transmitted from one routing device to the next routing device based on the geographic position of the routing devices and the interest message carries information about the links and network nodes it passes when being transmitted. The data packet is transmitted from the data producer to the data consumer the same path in the reverse order. In case one of the intermediate nodes is not available anymore, due to the mobile nature of the ad-hoc network, an opportunistic forwarding strategy is applied.

Claims (57)

1. A method for routing data packets between a first end device and a second end device via a mobile ad-hoc network that comprises multiple routing devices that are communicatively interconnected with each other, the method comprising:

generating, by the first end device, a data request message;

sending the data request message to a first routing device;

forwarding, by the first routing device the data request message to at least two neighbor routing devices by using a first opportunistic forwarding mechanism, wherein the data request message is forwarded to each of the at least two neighbor routing devices via different routes through the mobile ad-hoc network;

providing, by the second end device and in response to the data request message, a requested data packet to a second routing device;

forwarding, by the second routing device, the requested data packet via the mobile ad-hoc network to the first end device by using a source based forwarding mechanism;

determining, by the second routing device, if the source based forwarding mechanism fails in forwarding the requested data packet to the first end device; and

in response to the source based forwarding mechanism failing to forward the requested data packet to the first end device, using a second opportunistic forwarding mechanism for forwarding the requested data packet to the first end device;

wherein forwarding, by the first routing device, the data request message to at least two neighbor routing devices by using a first opportunistic forwarding mechanism comprising:

generating a source tuple identifying the first end device;

generating a destination tuple identifying the second end device;

defining a path quality tuple identifying a minimum bandwidth and a minimum accumulative transmission latency in a data transmission path;

defining a path vector identifying a list of all nodes crossed by the data request message; and

adding the source tuple, the destination tuple, the path quality tuple, and the path vector to a header of the data request message; and

wherein the method further comprises:

in response to the requested data packet being available in the content store, adding the path quality tuple and the path vector tuple contained in the header of the data request message to a local vector associated with the source tuple contained in the data request message to identify the first end device; and

in response to the path quality tuple contained in the header of the data request message meeting the path quality required for transmitting the requested data packet, formatting the requested data packet to be transmitted to the first end device based on the information stored in the header of the data request message.

2. The method of claim 1 , further comprising:

determining, by the first routing device, if a requested data packet is available in a content store of the first routing device;

when the requested data packet is available in the content store, forwarding the requested data packet to the first end device by using the source based forwarding mechanism;

when the requested data packet is not available in the content store, continuing the method with forwarding the data request message to at least two neighbor routing devices.

3. The method of claim 2 , further comprising storing, by the first routing device, the requested data packet in the content store of the first routing device.

4. The method of claim 1 , wherein the forwarding, by using the source based forwarding mechanism, comprises forwarding a requested data packet based on a list of next hops that is stored in a header of the requested data packet.

5. The method of claim 1 , wherein the first opportunistic forwarding mechanism and/or the second opportunistic forwarding mechanism is or are configured to forward the data request message and the data packet, respectively, based on a correlation of a destination location, the location of a current network node, and the location of neighbors of the current network node.

6. The method of claim 1 , further comprising providing a data identifier identifying the requested data packet.

7. The method of claim 1 , wherein the source tuple includes at least a geolocation of the source, and optionally a direction value and a speed value; and

wherein the destination tuple includes at least a geolocation of the destination, and optionally a direction value and a speed value.

8. The method of claim 1 , wherein the method comprises:

when the requested data packet is not available in the content store:

determining if the destination tuple contains a geolocation, a direction value, and a speed value, and if so, updating the geolocation in the destination tuple based on the direction value and the speed value, and forwarding the data request message towards a current geolocation of the second end device;

when a distance of the first routing device to the second end device is higher than a predetermined hop count value, forwarding, by the first routing device, the data request message to a plurality of routing devices that are closer to the geolocation of the second end device;

when the distance of the first routing device to the second end device is smaller than the predetermined hop count value, broadcasting the data request message to all neighbors of the first routing device.

9. The method of claim 1 , wherein the forwarding, by the second routing device, the requested data packet via the mobile ad-hoc network to the first end device by using a source based forwarding mechanism comprises:

generating a source tuple identifying the second end device;

generating a destination tuple identifying the first end device;

defining a path vector identifying a list of all nodes that define a path of the requested data packet through the mobile ad-hoc network; and

adding the source tuple, the destination tuple, and the path vector to a header of the requested data packet.

10. The method of claim 9 ,

wherein, when the path vector in the header of the requested data packet is not null, forwarding the requested data packet to the next routing device in the path vector;

when forwarding to the next routing device in the path vector fails, deleting the path vector in the header of the requested data packet and forwarding the requested data packet following an opportunistic forwarding mechanism.

11. A routing device for routing data packets between a first end device and a second end device via a mobile ad-hoc network,

wherein the routing device is configured to:

receive, from the first end device, a data request message;

forward the data request message to at least two neighbor routing devices via different routes through the mobile ad-hoc network and by using a first opportunistic forwarding mechanism;

receive, from the second end device or a neighbor routing device, a requested data packet;

forward the requested data packet to the first end device by using a source based forwarding mechanism;

determine if the source based forwarding mechanism fails in forwarding the requested data packet to the first end device;

use a second opportunistic forwarding mechanism to forward the requested data packet to the first end device in response to the source based forwarding mechanism failing to forward the requested data packet to the first end device;

wherein forwarding the data request message to at least two neighbor routing devices includes the routing device being configured to use a first opportunistic forwarding mechanism, including the routing device being configured to:

generate a source tuple identifying the first end device;

generate a destination tuple identifying the second end device;

define a path quality tuple identifying a minimum bandwidth and a minimum accumulative transmission latency in a data transmission path;

define a path vector identifying a list of all nodes crossed by the data request message; and

add the source tuple, the destination tuple, the path quality tuple, and the path vector to a header of the data request message; and

wherein the routing device is further configured to:

in response to the requested data packet being available in the content store, add the path quality tuple and the path vector tuple contained in the header of the data request message to a local vector associated with the source tuple contained in the data request message to identify the first end device; and

in response to the path quality tuple contained in the header of the data request message meeting the path quality required for transmitting the requested data packet, format the requested data packet to be transmitted to the first end device based on the information stored in the header of the data request message.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Aug 1, 2022
From: MENDES, PAULO
To: AIRBUS (S.A.S.)
Reel/Frame 060688/0251 →
Priority Claims (1)
EP 21181232 · Jun 23, 2021 · regional
Continuity (1)
Related Publication 20220417829A1 · Dec 29, 2022
References Cited (24)
US 8238317B2 · Yang et al. · 2012 [cited by applicant]
US 9832705B1 · Newton et al. · 2017 [cited by applicant]
US 10411978B1 · Ball · 2019 [cited by examiner]
US 12034821B2 · Wang · 2024 [cited by examiner]
US 20040004967A1 · Nakatsugawa · 2004 [cited by examiner]
US 20040264372A1 · Huang · 2004 [cited by examiner]
US 20050122955A1 · Lin · 2005 [cited by examiner]
US 20070195702A1 · Yuen · 2007 [cited by examiner]
US 20140025775A1 · Lee et al. · 2014 [cited by applicant]
US 20190141495A1 · Jha · 2019 [cited by examiner]
US 20220182334A1 · Kang · 2022 [cited by examiner]
US 20220417829A1 · Mendes · 2022 [cited by examiner]
US 20240340773A1 · Milheiro Mendes · 2024 [cited by examiner]
WO WO2017063866A1 · 2017 [cited by applicant]
Yan Zhang et al, “Wireless Mesh Networking,” Jan. 1, 2007, Auerbach Publications, p. 120. [cited by applicant]
Wang ZW et al, “Vector address routing protocol for MANET,” Signal Processing, 2008. ICSP 2008. 9th International Conference on IEEE, Piscataway, NJ, Oct. 26, 2008. pp. 2640-2644. [cited by applicant]
Ahlgren B. et al, “A survey of information-centric networking,” IEEE Communications Magazine, IEEE Service Center, Piscataway, US, vol. 50, No. 7, Jul. 1, 2012. [cited by applicant]
Dannewitz, Christian et al, “Network of Information (NetInf)—An information-centric networking architecture,” Computer Communications, Elsevier Science Publishers BV, Amsterdam, NL, vol. 36, No. 7, Jan. 27, 2013. [cited by applicant]
Wang Xiaonan et al, “Vehicular Content-Centric Networking Framework,” IEEE Systems Journal, IEEE, US. vol. 13, No. 1. Mar. 1, 2019, pp. 519-529. [cited by applicant]
Arafat Muhammad Yeasir et al, “Routing Protocols for Unmanned Aerial Vehicle Networks: A Survey,” IEEE Access, vol. 7, Jul. 25, 2019, pp. 99694-99720. [cited by applicant]
Anonymous, “How Switches Forward Frames Explained,” www.computernetworkingnotes.com, Feb. 25, 2021, pp. 1-4. [cited by applicant]
European Search Report for U.S. Appl. No. 21/181,275 dated Nov. 3, 2021. [cited by applicant]
European Search Report for U.S. Appl. No. 21/181,278 dated Dec. 2, 2021. [cited by applicant]
European Search Report for U.S. Appl. No. 21/181,232 dated Dec. 3, 2021. [cited by applicant]