CN110445713B - Flooding routing method based on standby path - Google Patents
Flooding routing method based on standby path Download PDFInfo
- Publication number
- CN110445713B CN110445713B CN201910687580.9A CN201910687580A CN110445713B CN 110445713 B CN110445713 B CN 110445713B CN 201910687580 A CN201910687580 A CN 201910687580A CN 110445713 B CN110445713 B CN 110445713B
- Authority
- CN
- China
- Prior art keywords
- node
- data packet
- routing
- packet
- real
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/22—Alternate routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/32—Flooding
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
The invention discloses a flooding routing method based on a standby path, which comprises the following steps: before a source node sends a data packet each time, sending a Go packet; the relay node and the destination node both store a priority queue of a Go packet arriving at the node; the destination node marks the last hop node of the Go packet which arrives fastest as the fastest arrival node, and returns a Back packet to respond to the source node; estimating waittime from the Go packet; after the destination node passes waittime, if the real data packet is not received, the destination node judges whether a standby next-to-fast arrival node exists in the priority queue or not, and pops up the used fastest arrival node in the priority queue; and if the source node receives the Back packet, the source node sends a real data packet according to the shortest path. The invention can effectively reduce the energy consumption of the network, improve the survival time of the whole network, effectively avoid the problem of routing holes, improve the delivery rate of data packets and avoid the phenomena of 'implosion' and 'overlapping' of messages caused by the traditional flooding routing algorithm.
Description
Technical Field
The invention relates to the field of underwater acoustic communication, in particular to a flooding routing method based on a standby path.
Background
When the traditional flooding routing algorithm is applied to the underwater acoustic network, after a source node sends a data packet, each node which can receive the data packet on the network topology needs to forward, so that an 'implosion' phenomenon can be generated in the underwater acoustic network when each data packet is sent, namely, a large number of useless data packets are filled. The data packets arriving at the destination node may also generate an "overlap" phenomenon, i.e., multiple relay nodes forward the same data packet to the destination node. This will cause a large amount of consumption of network resources and a large amount of Signal to Interference Noise, which reduces the Signal to Interference plus Noise Ratio (SINR), and is likely to cause packet loss.
From the perspective of the underwater sensor network routing protocol, the existing communication hole problem may be the most challenging problem. The holes are caused by many reasons, such as sparse topology, temporary obstacles and unreliable nodes, and the routing holes can significantly reduce the performance of the network. The hole problem is more challenging because of the dynamics of the operating environment, when and where holes may occur is unpredictable. Flooding routing is a simple and easy conventional routing protocol. Flooding routing can overcome the hole problem of underwater routing, however, the "implosion" and "overlap" of messages will result in large interference power and large energy consumption. In order to overcome the defects, the method needs to be improved to be suitable for the underwater complex environment, the high mobility of the underwater nodes causes high dynamic network topology, strong and unreliable network topology, and the resources such as storage of underwater hardware equipment and energy are limited in special scenes.
A typical On-Demand Routing Dynamic Source Routing protocol (Dynamic Source Routing, DSR) and an Ad Hoc On-Demand Distance Vector Routing protocol (AODV) in a traditional Ad Hoc wireless network use a Routing maintenance mechanism, the data volume stored by an underwater hardware node is increased along with the increase of the network topology complexity and the network load, and due to the particularity of the underwater node, the situations of storage and energy resource exhaustion are easy to occur, so that the probability of a Routing hole is increased, and the life cycle of the network is reduced.
When detecting an invalid path, the DSR routing protocol needs to send error information to the source node by flooding to inform the source node to delete the corresponding invalid path, which additionally increases the resource consumption of the network. DSR routing needs to store dynamic indefinite length complete ordered routing information from source node to destination node, and adds the indefinite length complete ordered routing information to real data packet header for transmission, if network topology is complicated, the indefinite length complete ordered routing information (header) will occupy large amount of effective data storage space in data packet. Resulting in compression of the real data storage space that can be really transmitted, and a significant reduction in the efficiency of protocol transmission.
The relay node of the AODV route only records the adjacent node information of the routing request sent for the first time, and the same routing request arriving at the next time is directly deleted. For the complex underwater environment, the high dynamic property of the network topology caused by high node mobility, and the strong unreliability of the network topology, the stored first arrival path information is easy to fail due to the reasons of node mobility, node energy exhaustion, communication channel obstruction and the like, so that the problem of routing holes is caused, and the network load and energy consumption are increased in the process of re-establishing the route. Therefore, AODV routing is only applicable to symmetrically linked networks.
Therefore, aiming at the defects of the existing wireless routing protocol obtained by the investigation, in order to more effectively apply the simple and easy traditional flooding routing to the underwater acoustic communication network, it is necessary to design an underwater communication network routing algorithm which can effectively avoid the phenomenon of 'implosion' and 'overlapping' of messages caused by the flooding routing, can also effectively reduce the energy consumption of the network, improve the survival time of the whole network, and finally can effectively avoid the problem of routing holes.
Disclosure of Invention
The invention aims to provide a flooding routing method based on a standby path. The underwater communication network routing method can effectively avoid the phenomena of 'implosion' and 'overlapping' of messages caused by flooding routing, can effectively reduce the energy consumption of an underwater acoustic network, improves the survival time of the whole network, and can effectively avoid the problem of routing holes.
The purpose of the invention is realized by the following technical scheme:
a flooding routing method based on backup paths comprises the following steps:
before a source node sends a real data packet each time, a Go routing data packet is sent;
the relay node and the destination node both store a priority queue of Go routing data packets arriving at the node;
the destination node marks the last hop node of the Go path-finding data packet which arrives fastest as the fastest arrival node, and returns a Back path-finding data packet which is as small as the fastest arrival node to respond to the source node; estimating the time waittingtime (waiting time of a destination node) required for receiving the real data packet according to the Go routing data packet;
in the process of transmitting the Back way finding data packet to the source node, the source node and the relay node both store a priority queue of the Back way finding data packet reaching the node;
after the destination node passes waittime, if the real data packet is not received, the destination node judges whether a standby next-to-fast arrival node exists in the priority queue or not, and pops up the used fastest arrival node in the priority queue;
if the source node receives the Back routing data packet, the real data packet is sent according to the shortest path, after the relay node receives the real data packet, whether the relay node is the fastest arrival node or not is judged, and only the fastest arrival node is qualified to forward the real data packet.
In the invention, after the route searching process is finished, two priority queues are stored in the node, one is a priority queue of a Go route searching data packet and is used for filling a node field which is the fastest to reach when a destination node and a relay node send or forward Back route searching data; the other is a priority queue of Back way finding data packets, which is used for filling a field of a frame head which reaches a node most quickly when a source node and a relay node send or forward a real data packet; the field of the fastest arrival node is used for judging whether the received relay node is the fastest arrival node or not, and the relay node only has forwarding qualification if the received relay node is the fastest arrival node.
Specifically, the sizes of the priority queues of the Go path finding data packets of the relay node and the destination node and the sizes of the priority queues of the Back path finding data packets of the relay node and the source node are preset according to the state of an underwater environment:
if the underwater environment is severe and the water flow is turbulent, the mobility of the underwater nodes is strong, and the path established by the early-stage routing data packet has a high probability of being unusable, the length of the priority queue needs to be increased; otherwise the length of the priority queue is reduced.
Specifically, the process of storing Back route-seeking data packet priority queues by the source node and the relay node is similar to the process of storing Go route-seeking data packet priority queues reaching the node by the relay node and the destination node, wherein the priority reached first is higher, and the priority queue is closer to the front. The main difference between the forwarding processes of the Back routing data packet and the Go routing data packet is that the relay node judges whether the Back routing data packet is qualified to be forwarded, and the Go routing data packet is flooded and is forwarded.
Specifically, when the Back routing data packet is sent by using the standby second-time fast arrival node, if the destination node receives the real data packet, the state of waiting for receiving the real data packet is stopped.
Specifically, setting the system time of the sensor node to be synchronous (within 1 s), waittime calculation formula:
Twait＝TBack+Treal_pkt+Tbias
wherein, TBackThe fastest packet receiving time from the destination node to the source node of the Back routing data packet is represented, and the total time T from the packet sending to the packet receiving of the Go routing data packet can be consideredGoAre equal; t isreal_pktRepresents the time T from the source node to the destination node for receiving the real data packet most quicklybiasIndicating an offset that is positive and is set to allow for a certain delay delta and time error.
TBackThe calculation method comprises the following steps:
according to the time when the destination node receives the data packet which reaches the Go path searching fastest and the source sending time carried in the packet structure, the difference is calculated to obtain the total time T from the packet sending to the packet receiving of the Go path searching data packetGoTo obtain TBack。
Treal_pktThe calculation formula of (2) is as follows:
Treal_pkt＝Tp+Tsend_real
wherein, TpFor underwater propagation delays, Tsend_realIs the transmission delay of the real data packet. Since the Go path-finding data packet arriving at the destination node at the fastest speed and the Back path-finding data packet arriving at the source node at the fastest speed are identical to the passing node sequence of the real data packet (only the Back path-finding data packet is opposite in direction), the propagation delay T is considered to bepAre equal.
TpThe calculation formula is as follows:
Tp＝TGo-Tsend_Go
wherein, Tsend_GoFor the transmission delay of the Go path-finding data packet, the number n of times of forwarding the Go path-finding data packet can be known by using a TTL value carried by the Go path-finding data packet, and the length of the Go path-finding data packet is divided by a transmission rate and multiplied by n to obtain Tsend_Go(ii) a T is obtained by dividing the length value of the real data packet by the sending ratesend_real。
Specifically, in the step of judging whether a standby next-time-fast arrival node exists in the priority queue, if the standby next-time-fast arrival node exists, the standby next-time-fast arrival node is used for sending a Back route searching data packet;
if the standby next-time fast arrival node is used up, a Failed data packet is sent in a flooding mode to inform the source node of resending the Go route searching data packet and reestablishing the route;
the fastest arriving node that has been used is popped up, regardless of whether there is a spare second-fastest arriving node in the team.
Specifically, if the source node receives a plurality of identical Back data packets, the Back data packets arriving later are discarded; and if the source node does not receive the Back routing data packet but receives the Failed data packet, the source node resends the Go routing data packet to establish a route.
Specifically, the method for the relay node to determine whether the relay node is the fastest arrival node includes:
after receiving the real data packet, the relay node firstly judges whether the relay node is the fastest arrival node according to the fastest arrival node address stored in the real data packet: if not, discarding and not forwarding; if yes, filling a new next fastest arrival node address into the real data packet according to the Back path searching data packet priority queue, and then forwarding.
In the invention, the Back way-finding data packet and the real data packet forwarding principle are similar. The relay nodes need to judge whether the fastest arrival node address in the packet is the relay node address of the relay node, and if not, the relay node does not forward the packet; if yes, filling a new next fastest arrival node address in the packet, replacing the original address, and then forwarding.
The forwarding principle of Back way finding data packet and real data packet mainly has two differences: (1) the address of the next fastest arrival node of the Back way finding data packet is based on a Go way finding data packet priority queue, and the address of the next fastest arrival node of the real data packet is based on a Back way finding data packet priority queue; (2) in the Back route searching data packet forwarding process, the source node and the relay node can also store a previous hop address to the Back route searching data packet priority queue, but the real data packet forwarding process cannot.
Compared with the prior art, the invention has the following beneficial effects:
1. aiming at the particularity of an underwater environment, a route holding mechanism is not adopted, and the design concept of a priority queue with fixed length is adopted in both FastArrivalPrioryQueue design in which a node stores a node which arrives fastest and NodeArrivalPackage design in which a node stores an arriving data packet. When new data is received, the new data is compared with all elements in the priority queue with fixed length, the data with lower priority is automatically discarded according to the priority comparison result, the length of the priority queue is maintained unchanged, all nodes are guaranteed to store the data with fixed length, and the condition that the underwater hardware nodes are exhausted of storage resources along with the fact that the network topology complexity is too high and the network load is increased due to the adoption of a route keeping and routing mechanism is avoided.
2. Because the invention adopts the priority queue to automatically discard the data information with lower priority, the invention does not need to inform the source node to delete the corresponding invalid path by sending error information to the source node (flooding) when the invalid path is monitored like DSR routing protocol, thereby achieving the effects of reducing network load and saving network energy consumption.
3. The invention adopts the frame structure design with fixed length, and records the last hop information reverse routing of the data which reaches the node at the fastest speed through the priority queue, so that the complete and ordered routing information from the source node to the destination node is not required to be known. And the routing packet head part added into the real data packet only occupies fixed 12 bytes, the occupied bytes are less, and the size of the packet head cannot be increased along with the increase of the complexity of the network topology, so that the efficiency of transmitting the real data packet by the protocol is ensured.
4. The invention adopts the priority queue to store the data information of the fastest arriving node with fixed size, can complete data transmission by adopting the standby second fastest arriving node when the fastest arriving node can not be used, avoids the problem of routing holes, is suitable for the asymmetrically-linked network, can fully utilize the information collected by one-time routing, greatly increases the probability of completing data transmission only by one-time routing, and avoids the problems of increasing network load and energy consumption caused by repeated routing reconstruction.
Drawings
Fig. 1 is a flow chart of a backup path based flooding routing method.
Fig. 2 is a frame structure diagram of Failed packets in the present embodiment.
Fig. 3 is a frame structure diagram of the way finding packet in the present embodiment.
Fig. 4 is a frame structure diagram of a real packet in the present embodiment.
Detailed Description
The present invention will be described in further detail with reference to examples and drawings, but the present invention is not limited thereto.
Examples
Fig. 1 is a flowchart of a flooding routing method based on backup paths, which includes the steps of:
s1, before the source node sends a real data packet each time, a Go routing data packet is sent;
s2, the relay node and the destination node store a priority queue of the route searching data packet reaching the Go node;
specifically, the sizes of the priority queues of the Go path finding data packets of the relay node and the destination node and the sizes of the priority queues of the Back path finding data packets of the relay node and the source node are preset according to the state of an underwater environment:
if the underwater environment is severe and the water flow is turbulent, the mobility of the underwater nodes is strong, and the path established by the early-stage routing data packet has a high probability of being unusable, the length of the priority queue needs to be increased; otherwise the length of the priority queue is reduced.
In the process of storing the Back route-seeking data packet priority queue by the source node and the relay node and the process of storing the Go route-seeking data packet priority queue by the relay node and the destination node, the priority reached first is higher, and the priority queue is closer to the front.
S3, the destination node marks the last hop node of the Go route searching data packet which arrives fastest as the fastest arrival node, and returns a Back route searching data packet which is as small as the fastest arrival node to respond to the source node; estimating the time waittingtime (waiting time of a destination node) required for receiving the real data packet according to the Go routing data packet;
specifically, when the Back routing data packet is sent by using the standby second-time fast arrival node, if the destination node receives the real data packet, the state of waiting for receiving the real data packet is stopped.
Setting the system time of the sensor nodes to be synchronous (within 1 s), waittime calculation formula:
Twait＝TBack+Treal_pkt+Tbias
wherein, TBackThe fastest packet receiving time from the destination node to the source node of the Back routing data packet is represented, and the total time T from the packet sending to the packet receiving of the Go routing data packet can be consideredGoAre equal; t isreal_pktRepresents the time T from the source node to the destination node for receiving the real data packet most quicklybiasIndicating an offset that is positive and is set to allow for a certain delay delta and time error.
TBackThe calculation method comprises the following steps:
according to the time when the destination node receives the data packet which reaches the Go path searching fastest and the source sending time carried in the packet structure, the difference is calculated to obtain the total time T from the packet sending to the packet receiving of the Go path searching data packetGoTo obtain TBack。
Treal_pktThe calculation formula of (2) is as follows:
Treal_pkt＝Tp+Tsend_real
wherein, TpFor underwater propagation delays, Tsend_realIs the transmission delay of the real data packet. Since the Go path-finding data packet arriving at the destination node at the fastest speed and the Back path-finding data packet arriving at the source node at the fastest speed are identical to the passing node sequence of the real data packet (only the Back path-finding data packet is opposite in direction), the propagation delay T is considered to bepAre equal.
TpThe calculation formula is as follows:
Tp＝TGo-Tsend_Go
wherein, Tsend_GoFor the transmission delay of the Go path-finding data packet, the number n of times of forwarding the Go path-finding data packet can be known by using a TTL value carried by the Go path-finding data packet, and the length of the Go path-finding data packet is divided by a transmission rate and multiplied by n to obtain Tsend_Go(ii) a T is obtained by dividing the length value of the real data packet by the sending ratesend_real。
S4, after the destination node passes waittingTime, if the destination node does not receive the real data packet, the destination node judges whether a standby next-to-soon-arriving node exists in the priority queue or not, and pops up the used fastest-arriving node in the priority queue;
if a standby sub-fast arrival node exists, the standby sub-fast arrival node is used for sending a Back path searching data packet;
if the standby next-time fast arrival node is used up, a Failed data packet is sent in a flooding mode to inform the source node of resending the Go route searching data packet and reestablishing the route;
the fastest arriving node that has been used is popped up, regardless of whether there is a spare second-fastest arriving node in the team.
Fig. 2 is a frame structure diagram of Failed data packet, where the data packet UID identifies the unique identifier of the data packet in the network, the source node address identifies the address of the source node in the underwater acoustic network, the destination node address identifies the address of the destination node in the underwater acoustic network, and the data packet type identifies the type of the data packet, where 0: go data packets; 1: a Back data packet; 2: a real data packet; 3: failed packets. TTL is the lifetime value of the packet, i.e. the maximum number of hops the packet is forwarded, and is initially 255.
S5, if the source node receives the Back routing data packet, the real data packet is sent according to the shortest path, after the relay node receives the real data packet, the relay node firstly judges whether the relay node is the fastest arrival node, and only the fastest arrival node is qualified to forward the real data packet.
Specifically, if the source node receives a plurality of identical Back data packets, the Back data packets arriving later are discarded; and if the source node does not receive the Back routing data packet but receives the Failed data packet, the source node resends the Go routing data packet to establish a route.
The method for the relay node to judge whether the relay node is the fastest arrival node comprises the following steps:
after receiving the real data packet, the relay node firstly judges whether the relay node is the fastest arrival node according to the fastest arrival node address stored in the real data packet: if not, discarding and not forwarding; if yes, filling a new next fastest arrival node address into the real data packet according to the Back path searching data packet priority queue, and then forwarding.
As shown in fig. 3, a frame structure diagram of a routing data packet is shown, where a previous hop node address records a previous hop node address of a node receiving the routing data packet, before each node sends the routing data packet, an address of the node is added to the previous hop node address in the routing data packet, the fastest arrival node address represents an address of a fastest arrival node, the size of a real data packet identifies the size of the real data packet to be sent by a source node, and is used to estimate a transmission delay of the real data packet sent by the source node to a destination node, and a source sending time records a time of sending a Go routing data packet by the source node, and is used to estimate a propagation delay of the real data packet sent by the source node to the destination node.
As shown in fig. 4, the frame structure of the real data packet is shown, the frame header part is the frame structure of the routing data packet, and the data part stores the real data.
The core class design of an improved flooding routing algorithm based on a backup path in an underwater acoustic network is as follows:
(1) node stores FastArrivalPrioryQueue class design of fastest arriving node
(2) NodeArrivalPackage class design for node storage arrival data packet
The above embodiments are preferred embodiments of the present invention, but the present invention is not limited to the above embodiments, and any other changes, modifications, substitutions, combinations, and simplifications which do not depart from the spirit and principle of the present invention should be construed as equivalents thereof, and all such changes, modifications, substitutions, combinations, and simplifications are intended to be included in the scope of the present invention.
Claims (10)
1. A flooding routing method based on backup paths is characterized by comprising the following steps:
before a source node sends a real data packet each time, a Go routing data packet is sent;
the relay node and the destination node both store a priority queue of Go routing data packets arriving at the relay node and the destination node;
the destination node marks the last hop node of the Go routing data packet which arrives fastest as the fastest arrival node, and returns a Back routing data packet to respond to the source node; estimating the time waittingtime required for receiving the real data packet according to the Go routing data packet;
in the process of transmitting the Back way finding data packet to the source node, the source node and the relay node both store a priority queue of the Back way finding data packet reaching the source node and the relay node;
after the destination node passes waittime, if the real data packet is not received, the destination node judges whether a standby next-to-fast arrival node exists in the priority queue or not, and pops up the used fastest arrival node in the priority queue;
if the source node receives the Back routing data packet, the real data packet is sent according to the shortest path, after the relay node receives the real data packet, whether the relay node is the fastest arrival node or not is judged, and only the fastest arrival node is qualified to forward the real data packet.
2. The flooding routing method based on backup path as claimed in claim 1, wherein the sizes of the priority queues of Go routing packets of the relay node and the destination node and the sizes of the priority queues of Back routing packets of the relay node and the source node are preset according to the state of underwater environment:
if the underwater environment is severe and the water flow is turbulent, the mobility of the underwater nodes is strong, and the path established by the early-stage routing data packet has a high probability of being unusable, the length of the priority queue needs to be increased; otherwise the length of the priority queue is reduced.
3. The flooding routing method according to claim 1, wherein in the procedure of the source node and the relay node storing Back routing packet priority queues and the procedure of the relay node and the destination node storing Go routing packet priority queues, the routing packet priority that reaches the priority queues is higher before the priority queues get closer.
4. The backup path based flooding routing method of claim 1, wherein when the Back routing packet is sent by using the backup sub-fast arrival node, if the destination node receives the real packet, the state waiting for receiving the real packet is stopped.
5. The flooding routing method based on backup path as claimed in claim 1, wherein the system time of the sensor node is set to be synchronous, waittime calculation formula:
Twait＝TBack+Treal_pkt+Tbias
wherein, TBackThe fastest packet receiving time of a Back routing data packet from a destination node to a source node and the total time T of a Go routing data packet from packet sending to packet receiving are shownGoAre equal; t isreal_pktRepresents the time T from the source node to the destination node for receiving the real data packet most quicklybiasIndicating a bias that takes a positive value.
6. The backup path-based flooding routing method of claim 5, wherein T isBackThe calculation method comprises the following steps:
according to the time when the destination node receives the data packet which reaches the Go path searching fastest and the source sending time carried in the packet structure, the difference is calculated to obtain the total time T from the packet sending to the packet receiving of the Go path searching data packetGoTo obtain TBack；
Treal_pktThe calculation formula of (2) is as follows:
Treal_pkt＝Tp+Tsend_real
wherein, TpFor underwater propagation delays, Tsend_realIs the transmission delay of the real data packet.
7. The backup path-based flooding routing method of claim 6, wherein T ispThe calculation formula is as follows:
Tp＝TGo-Tsend_Go
wherein, Tsend_GoFor the transmission delay of the Go path-finding data packet, the number n of times of forwarding the Go path-finding data packet can be known by using a TTL value carried by the Go path-finding data packet, and the length of the Go path-finding data packet is divided by a transmission rate and multiplied by n to obtain Tsend_Go(ii) a T is obtained by dividing the length value of the real data packet by the sending ratesend_real。
8. The flooding routing method according to claim 1, wherein in the step of determining whether there is a standby next-to-fast-arrival node in the priority queue, if there is a standby next-to-fast-arrival node, the destination node sends Back routing packet using the standby next-to-fast-arrival node;
if the standby next-time fast arrival node is used up, a Failed data packet is sent in a flooding mode to inform the source node of resending the Go route searching data packet and reestablishing the route;
regardless of whether there is a spare next-to-soon-arriving node in the priority queue, the fastest-arriving node that has been used is popped up.
9. The backup path based flooding routing method of claim 1, wherein if the source node receives a plurality of identical Back packets, it discards the Back packets that arrive later; and if the source node does not receive the Back routing data packet but receives the Failed data packet, the source node resends the Go routing data packet to establish a route.
10. The flooding routing method based on backup path according to claim 1, wherein the method for the relay node to determine whether it is the fastest arrival node is:
after receiving the real data packet, the relay node firstly judges whether the relay node is the fastest arrival node according to the fastest arrival node address stored in the real data packet: if not, discarding and not forwarding; if yes, filling a new next fastest arrival node address into the real data packet according to the Back path searching data packet priority queue, and then forwarding.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910687580.9A CN110445713B (en) | 2019-07-29 | 2019-07-29 | Flooding routing method based on standby path |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201910687580.9A CN110445713B (en) | 2019-07-29 | 2019-07-29 | Flooding routing method based on standby path |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110445713A CN110445713A (en) | 2019-11-12 |
| CN110445713B true CN110445713B (en) | 2020-12-22 |
Family
ID=68431900
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201910687580.9A Active CN110445713B (en) | 2019-07-29 | 2019-07-29 | Flooding routing method based on standby path |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110445713B (en) |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103607747B (en) * | 2013-12-10 | 2017-03-08 | 东南大学 | A kind of based on the cluster of Power Control between virtual backbone Routing Protocol method |
| CN103856399B (en) * | 2014-03-17 | 2017-02-01 | 山东大学 | Ad Hoc backup route algorithm based on stability |
| CN106332299B (en) * | 2016-08-20 | 2019-10-18 | 华南理工大学 | Competitive channel underwater acoustic network multi-node parallel communication means comprising movement node |
| CN107682434B (en) * | 2017-09-30 | 2020-11-06 | 深圳市智慧海洋科技有限公司 | Underwater sensor network architecture and implementation method thereof |
| CN107919950B (en) * | 2017-10-10 | 2020-06-19 | 华南理工大学 | Conflict-free competition channel underwater acoustic network parallel communication method |
-
2019
- 2019-07-29 CN CN201910687580.9A patent/CN110445713B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN110445713A (en) | 2019-11-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| Tran et al. | Congestion adaptive routing in mobile ad hoc networks | |
| KR101410701B1 (en) | Method and system for loop-free ad-hoc routing | |
| Johnson et al. | RFC 4728: The dynamic source routing protocol (DSR) for mobile ad hoc networks for IPv4 | |
| JP2006217597A (en) | Routing method and apparatus for reducing loss of packet | |
| AU2018442113B2 (en) | Model based path selection in a bluetooth low energy, BLE, mesh network | |
| CN107846706B (en) | Congestion-avoiding code-aware wireless mesh network multi-path routing method | |
| WO2016090978A1 (en) | Traffic switching method and device | |
| WO2009115020A1 (en) | Network route establishing and data transmitting method and network node | |
| CN113490251B (en) | Mobile ad hoc network route construction method based on flooding constraint and multi-metric function | |
| US7957380B2 (en) | Support of unidirectional link in IS-IS without IP encapsulation and in presence of unidirectional return path | |
| WO2020156340A1 (en) | Data transmission method and apparatus | |
| Li et al. | Node-disjointness-based multipath routing for mobile ad hoc networks | |
| US11558282B2 (en) | System and method for interior gateway protocol (IGP) fast convergence | |
| EP3157211A1 (en) | Isis-based flooding method and device | |
| CN109041156A (en) | Wireless route method with hop-by-hop affirmation mechanism | |
| CN117580125A (en) | Underwater sensor network routing protocol system based on weighted link quality | |
| Acharya et al. | DCMA: A label switching MAC for efficient packet forwarding in multihop wireless networks | |
| CN110445713B (en) | Flooding routing method based on standby path | |
| Mallapur et al. | Multi-constraints reliable multicast routing protocol for group communications in MANETs | |
| Srivastava et al. | A novel multi metric QoS routing protocol for MANET | |
| WO2022042386A1 (en) | Method for controlling message sending, network device and system | |
| Aissani et al. | Optimizations and performance study of the dynamic source routing protocol | |
| KR100659350B1 (en) | Congestion window adjustment method for TCP over ad-hoc networks | |
| US7450512B1 (en) | Recirculating retransmission queuing system and method | |
| Nikose et al. | A comparative analysis and design study of cross layer scheme based algorithm to increase the Qos performances in wireless communication |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |