WO2006031587A2 - Reducing latency when transmitting acknowledgements in mesh networks - Google Patents

Reducing latency when transmitting acknowledgements in mesh networks Download PDF

Info

Publication number
WO2006031587A2
WO2006031587A2 PCT/US2005/031974 US2005031974W WO2006031587A2 WO 2006031587 A2 WO2006031587 A2 WO 2006031587A2 US 2005031974 W US2005031974 W US 2005031974W WO 2006031587 A2 WO2006031587 A2 WO 2006031587A2
Authority
WO
WIPO (PCT)
Prior art keywords
node
data packet
ack
packet
data
Prior art date
Application number
PCT/US2005/031974
Other languages
French (fr)
Other versions
WO2006031587A3 (en
Inventor
Maged Zaki
Original Assignee
Interdigital Technology Corporation
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Interdigital Technology Corporation filed Critical Interdigital Technology Corporation
Publication of WO2006031587A2 publication Critical patent/WO2006031587A2/en
Publication of WO2006031587A3 publication Critical patent/WO2006031587A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L1/12Arrangements for detecting or preventing errors in the information received by using return channel
    • H04L1/16Arrangements for detecting or preventing errors in the information received by using return channel in which the return channel carries supervisory signals, e.g. repetition request signals
    • H04L1/1607Details of the supervisory signal
    • H04L1/1664Details of the supervisory signal the supervisory signal being transmitted together with payload signals; piggybacking
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/28Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L1/00Arrangements for detecting or preventing errors in the information received
    • H04L2001/0092Error control systems characterised by the topology of the transmission link
    • H04L2001/0093Point-to-multipoint
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W84/00Network topologies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/02Terminal devices

Definitions

  • the present invention relates generally to wireless local area networks (WLANs) and, more particularly, to a method for reducing latency in transmitting acknowledgements (ACKs) in a mesh network.
  • WLANs wireless local area networks
  • ACKs acknowledgements
  • WLAN wireless local area network
  • STAs stations
  • AP access point
  • Figures Ia and Ib show a general overview of the hidden node problem.
  • the hidden node problem results from the scenario in which, as shown in Figure Ia, node A is within range of node B and node C is within range of node B, but node A is not within range of node C.
  • node A and node C are "hidden" from each other. If both node A and node C attempt to send information to node B at the same time, there will be a collision at node B, as shown in Figure Ib.
  • RTS request-to-send
  • CTS clear-to-send
  • FIG. 2 shows a mesh network with four nodes (A, B, C, and D), where node A is a source node, node B is a destination node, node C is a hidden destination node, and node D is a source node.
  • node A sends an RTS frame. Because node C is hidden from node A, it does not hear the RTS from node A.
  • Node B receives the RTS frame and replies with a CTS frame.
  • node D sends an
  • the data transmission arrives from node A, causing a collision at node B.
  • This example illustrates that overhearing a CTS (at node C) from neighboring nodes (node B) over the same channel can inhibit a remote node (node D) from transmitting to its neighboring nodes (node C).
  • FIG 3 where a node that overhears communications intended for another node is prevented from transmitting to a remote node.
  • node B sends a CTS, which is received by both node A and node C.
  • node C receives the CTS, it enters a backoff period, thereby preventing it from sending its own RTS. Due to the unintentional backoff in the mesh configuration, this behavior has a large impact on the overall system performance.
  • the exposed node problem can prevent independent parallel communication among other mesh points over the same channel.
  • Each node has a network allocation vector (NAV) table which contains the remaining time of packet transmission of the neighboring nodes.
  • NAV network allocation vector
  • Nodes conduct virtual carrier-sense detection and when the channel is physically sensed to be idle and the NAV table is empty, the source node sends an RTS packet. All other idle nodes, upon hearing an RTS, update their NAV table and defer their own transmissions (i.e., enter a backoff period).
  • the destination node sends a CTS packet to respond to the RTS packet. Nodes neighboring the destination node overhear the CTS and update their NAV tables. After receiving the CTS, the source node transmits data and receives an acknowledgement (ACK).
  • ACK acknowledgement
  • each frame has to be acknowledged by the receiving side. For example, as shown in Figure 4, when node B receives a data frame from node A, node B has to send an ACK for this data packet and then start forwarding the data packet to node C. Performing the ACKs at each node increases both the traffic load and the latency in an 802.11 mesh network.
  • the hidden node and exposed node problems are conflicting issues, and are especially relevant in an auto-configured mesh deployment. RTS/CTS virtual carrier-sensing is not sufficient to completely resolve those problems for the mesh architecture.
  • the enabling of broadcast and multicast traffic within the mesh network can intensify the hidden node and exposed node interference problems, thereby degrading the overall system throughput. Therefore, a method and apparatus are needed for reducing latency when transmitting ACKs in mesh networks.
  • ACK in a mesh network begins by receiving a data packet at an intermediate node from a source node.
  • the intermediate node generates an ACK upon receipt of the data packet.
  • the intermediate node then forwards the data packet to a target node, including the ACK in the forwarded data packet.
  • the source node receives the ACK while the target node receives the data packet.
  • ACK in a mesh network having a source node, an intermediate node, and a target node
  • the data packet is sent by the source node to the intermediate node.
  • the ACK is generated by the intermediate node upon receipt of the data packet from the source node.
  • the intermediate node then forwards the data packet with the ACK to the target node.
  • the source node receives the ACK while the target node receives the data packet.
  • a node for use in a mesh network includes an antenna, a transmitter/receiver connected to the antenna, and a packet updating device connected to the transmitter/receiver.
  • the packet updating device adds an acknowledgement to a received packet, whereby upon transmission of the received packet, a first node receives the data contained in the packet and a second node receives the acknowledgement contained in the packet.
  • Figures Ia and Ib are diagrams of an overview of the hidden node problem in a WLAN
  • Figure 2 is a diagram showing an example of a collision problem caused by the hidden node problem
  • FIG. 3 is a diagram of the exposed node problem in a WLAN
  • FIG. 4 is a diagram showing a prior art WLAN acknowledgement mechanism
  • Figure 5 is a diagram showing a piggybacked acknowledgement mechanism
  • Figure 6 is a diagram of an existing 802.11 data frame format
  • Figure 7 is a diagram of a data frame format in accordance with one embodiment of the present invention.
  • Figure 8 is a diagram of a data frame format in accordance with another embodiment of the present invention.
  • Figure 9 is a diagram of a negative acknowledgement frame format in accordance with the present invention.
  • Figure 10 is a diagram of a node configured to add an ACK to a data packet in accordance with the present invention.
  • a node includes, but is not limited to, a wireless transmit/receive unit (WTRU), a user equipment, a mobile station, a fixed or mobile subscriber unit, a pager, or any other type of device capable of operating in a wireless environment.
  • WTRU wireless transmit/receive unit
  • an access point includes, but is not limited to, a base station, a Node B, a site controller, or any other type of interfacing device in a wireless environment.
  • the present invention provides for piggybacking acknowledgements (ACKs) on data packets.
  • ACKs piggybacking acknowledgements
  • a node When a node receives a data packet, it updates the address field in the data packet and piggybacks the ACK of the received packet onto the forwarded data packet. Since the carrier sense multiple access with collision avoidance (CSMA/CA) medium access protocol allows all the near nodes to hear this transmission (by exploiting the exposed node problem), the previous and next nodes in the communication path will be able to hear the transmission. The previous node receives the ACK and the next node receives the forwarded data packet.
  • CSMA/CA carrier sense multiple access with collision avoidance
  • FIG. 5 shows a diagram of an ACK mechanism for mesh networks in accordance with the present invention.
  • node A sends a data frame (Data (I)) to node B.
  • Data (2) data frame
  • node A Since node A also hears node B's transmission to node C, it knows that the packet was received successfully and that the ACK timer will not expire. A similar transmission occurs when node C forwards the data packet to node D.
  • this ACK mechanism may be employed as explained below.
  • Figure 6 shows a typical frame format under current 802.11 standards.
  • the first embodiment of the ACK mechanism is a positive ACK mechanism; a data frame format in accordance with this embodiment is shown in Figure 7.
  • the destination node When the destination node receives the data packet correctly, it piggybacks the ACK to the data packet indicating that the data packet was received properly.
  • This embodiment adds a field, Address 5, to indicate the ACK recipient's address (i.e., the source node).
  • Address 1 indicates the data frame recipient's address (RA_data) and Address 5 indicates the ACK frame recipient's address (RA_ACK).
  • Address 1 would have the address of node C and Address 5 would have the address of node A.
  • the second embodiment of the ACK mechanism is an ACK/NACK mechanism. Similar to the first embodiment, when the destination node receives the data packet, it piggybacks the ACK to the data packet indicating that the data packet was received. Referring to Figure 8, Address 1 indicates the data frame recipient's address (RA_data) and the new field Address 5 indicates the ACK frame recipient's address (RA_ACK), as explained above. [0042] A second new field, called the ACK/NACK field, is a Boolean field. If it is set to zero, this means that the recipient did not receive the packet properly, and the recipient has the choice to either ACK or NACK the packet.
  • the ACK/NACK field allows the destination node to send an ACK frame when it receives the packet from the sender properly, by setting the field to one. If the recipient node does not receive the packet (i.e., when a packet is received with an incorrect sequence number, the recipient knows that it missed the packet) or if the recipient node could not decode the received packet properly, it can send a NACK to the sender by setting the field to zero.
  • the ACK/NACK field would be set to zero if node B did not correctly receive the Data(l) packet from node A.
  • node B sends the Data(2)/ACK(1) packet
  • node C receives the data packet
  • node A is informed that the packet was incorrectly received by node B.
  • Whether node B sends the Data(2) packet to node C depends on what caused the incorrect receipt at node B. If the current packet was not received properly, node B will not send a Data(2) packet to node C and will send a NACK to node A.
  • node B can still forward the Data(2) packet to node C and send a NACK to node A for the missed packet. For example, if node B receives a packet with a sequence number of "n+1" instead of "n", then node B can forward the "n+1" packet to node C and send a NACK to node A for the "n" packet.
  • the third embodiment of the ACK mechanism is a negative acknowledgement (NACK) mechanism.
  • NACK negative acknowledgement
  • the destination node when it does not receive a data packet, it sends a NACK to the source node to indicate that the data packet was missing.
  • the destination node knows that it missed a packet when a packet is received with an incorrect sequence number or if a packet is received that it cannot decode correctly.
  • the source node assumes that the data packet was received properly if it did not receive a NACK within a specific period of time.
  • Figure 9 shows an example of a NACK frame in accordance with this embodiment. It is noted that the NACK frame format is the same as the standard 802.11 ACK frame format.
  • FIG 10 is a diagram of a node 1000 configured to add an ACK to a data packet in accordance with the present invention.
  • the node 1000 includes an antenna 1002, a transmitter/receiver 1004 connected to the antenna 1002, and a packet updating device 1006 connected to the transmitter/receiver 1004.
  • the packet updating device 1006 receives a data packet from the transmitter/receiver 1004, adds an ACK to the data packet, and returns the data packet with the ACK to the transmitter/receiver 1004.
  • the packet updating device 1006 can add an ACK or a NACK to the data packet in accordance with any of the methods described above.
  • a method for reducing latency in a mesh network including the step of adding an acknowledgement (ACK) to a data packet.
  • ACK acknowledgement
  • a method for reducing latency in transmitting an acknowledgement (ACK) in a mesh network including the steps of: receiving a data packet at an intermediate node from a source node; generating an ACK upon receipt of the data packet at the intermediate node; and forwarding the data packet from the intermediate node to a target node including the ACK in the forwarded data packet, whereby the source node receives the ACK while the target node receives the data packet.
  • ACK acknowledgement
  • a system for reducing latency in transmitting an acknowledgement (ACK) in a mesh network having a source node, an intermediate node, and a target node including: a data packet sent by the source node to the intermediate node; and an ACK generated by the intermediate node upon receipt of the data packet from the source node, the intermediate node forwarding the data packet with the ACK to the target node, whereby the source node receives the ACK while the target node receives the data packet.
  • ACK acknowledgement
  • a node for use in a mesh network including an antenna; a transmitter/receiver connected to the antenna; and a packet updating device connected to the transmitter/receiver.

Abstract

A method for reducing latency in transmitting an acknowledgement (ACK) in a mesh network begins by receiving a data packet at an intermediate node (B, C) from a source node (A). The intermediate node (B, C) generates an ACK upon receipt of the data packet. The intermediate node (B, C) then forwards a data packet to a target node (D), including the ACK in the data packet. By combining the ACK with the data packet, the source node (A) receives the data packet.

Description

[0001] REDUCING LATENCY WHEN TRANSMITTING
ACKNOWLEDGEMENTS IN MESH NETWORKS
[0002] FIELD OF INVENTION
[0003] The present invention relates generally to wireless local area networks (WLANs) and, more particularly, to a method for reducing latency in transmitting acknowledgements (ACKs) in a mesh network.
[0004] BACKGROUND
[0005] In an 802.11 wireless local area network (WLAN) setting, one type of network that can be created is a mesh network, which involves several stations (STAs) or nodes communicating directly with each other, rather than through an access point (AP). Two problems in WLANs are especially prevalent in mesh networks: hidden node and exposed node.
[0006] Figures Ia and Ib show a general overview of the hidden node problem. The hidden node problem results from the scenario in which, as shown in Figure Ia, node A is within range of node B and node C is within range of node B, but node A is not within range of node C. In this setting, node A and node C are "hidden" from each other. If both node A and node C attempt to send information to node B at the same time, there will be a collision at node B, as shown in Figure Ib.
[0007] The use of the request-to-send (RTS)/clear-to-send (CTS) virtual carrier-sense mechanism can prevent some of the hidden node problems, but not all. A node that wants to transmit (a source node) sends an RTS frame to the intended recipient node (a destination or target node). The RTS frame can also be heard by all nodes within the range of the source node. The destination node replies to the RTS frame by sending a CTS frame to the source node. As with the RTS frame, the CTS frame can be heard by all nodes within range of the destination node.
[0008] The RTS/CTS mechanism can cause additional problems when used in a mesh network. Figure 2 shows a mesh network with four nodes (A, B, C, and D), where node A is a source node, node B is a destination node, node C is a hidden destination node, and node D is a source node. In the example shown in Figure 2, node A sends an RTS frame. Because node C is hidden from node A, it does not hear the RTS from node A. Node B receives the RTS frame and replies with a CTS frame.
[0009] At the same time node B transmits its CTS frame, node D sends an
RTS frame. Both the CTS frame from node B and the RTS frame from node D are received at node C at the same time, causing a collision at node C. This collision prevents node C from responding to node D's RTS frame, requiring node D to retransmit the RTS frame. At the same time of the collision at node C, node A receives the CTS frame from node B and prepares to begin its data transmission. [0010] While node A is beginning its data transmission, node C receives the second RTS frame from node D. Node C replies to the second RTS from node D, and the CTS frame from node C is also heard by node B. At the same time, the data transmission arrives from node A, causing a collision at node B. This example illustrates that overhearing a CTS (at node C) from neighboring nodes (node B) over the same channel can inhibit a remote node (node D) from transmitting to its neighboring nodes (node C).
[0011] The exposed node problem results from a scenario like that shown in
Figure 3, where a node that overhears communications intended for another node is prevented from transmitting to a remote node. For example, node B sends a CTS, which is received by both node A and node C. When node C receives the CTS, it enters a backoff period, thereby preventing it from sending its own RTS. Due to the unintentional backoff in the mesh configuration, this behavior has a large impact on the overall system performance. The exposed node problem can prevent independent parallel communication among other mesh points over the same channel.
[0012] Each node has a network allocation vector (NAV) table which contains the remaining time of packet transmission of the neighboring nodes. Nodes conduct virtual carrier-sense detection and when the channel is physically sensed to be idle and the NAV table is empty, the source node sends an RTS packet. All other idle nodes, upon hearing an RTS, update their NAV table and defer their own transmissions (i.e., enter a backoff period). The destination node sends a CTS packet to respond to the RTS packet. Nodes neighboring the destination node overhear the CTS and update their NAV tables. After receiving the CTS, the source node transmits data and receives an acknowledgement (ACK).
[0013] In a WLAN, each frame has to be acknowledged by the receiving side. For example, as shown in Figure 4, when node B receives a data frame from node A, node B has to send an ACK for this data packet and then start forwarding the data packet to node C. Performing the ACKs at each node increases both the traffic load and the latency in an 802.11 mesh network. [0014] The hidden node and exposed node problems are conflicting issues, and are especially relevant in an auto-configured mesh deployment. RTS/CTS virtual carrier-sensing is not sufficient to completely resolve those problems for the mesh architecture. In addition, the enabling of broadcast and multicast traffic within the mesh network can intensify the hidden node and exposed node interference problems, thereby degrading the overall system throughput. Therefore, a method and apparatus are needed for reducing latency when transmitting ACKs in mesh networks.
[0015] SUMMARY
[0016] A method for reducing latency in transmitting an acknowledgement
(ACK) in a mesh network begins by receiving a data packet at an intermediate node from a source node. The intermediate node generates an ACK upon receipt of the data packet. The intermediate node then forwards the data packet to a target node, including the ACK in the forwarded data packet. By combining the ACK with the data packet, the source node receives the ACK while the target node receives the data packet.
[0017] A system for reducing latency in transmitting an acknowledgement
(ACK) in a mesh network having a source node, an intermediate node, and a target node includes a data packet and an ACK. The data packet is sent by the source node to the intermediate node. The ACK is generated by the intermediate node upon receipt of the data packet from the source node. The intermediate node then forwards the data packet with the ACK to the target node. By combining the ACK with the data packet, the source node receives the ACK while the target node receives the data packet.
[0018] A node for use in a mesh network, includes an antenna, a transmitter/receiver connected to the antenna, and a packet updating device connected to the transmitter/receiver. The packet updating device adds an acknowledgement to a received packet, whereby upon transmission of the received packet, a first node receives the data contained in the packet and a second node receives the acknowledgement contained in the packet.
[0019] BRIEF DESCRIPTION OF THE DRAWINGS
[0020] A more detailed understanding of the invention may be had from the following description of a preferred embodiment, given byway of example, and to be understood in conjunction with the accompanying drawings, wherein:
[0021] Figures Ia and Ib are diagrams of an overview of the hidden node problem in a WLAN;
[0022] Figure 2 is a diagram showing an example of a collision problem caused by the hidden node problem;
[0023] Figure 3 is a diagram of the exposed node problem in a WLAN;
[0024] Figure 4 is a diagram showing a prior art WLAN acknowledgement mechanism;
[0025] Figure 5 is a diagram showing a piggybacked acknowledgement mechanism;
[0026] Figure 6 is a diagram of an existing 802.11 data frame format;
[0027] Figure 7 is a diagram of a data frame format in accordance with one embodiment of the present invention;
[0028] Figure 8 is a diagram of a data frame format in accordance with another embodiment of the present invention;
[0029] Figure 9 is a diagram of a negative acknowledgement frame format in accordance with the present invention; and [0030] Figure 10 is a diagram of a node configured to add an ACK to a data packet in accordance with the present invention.
[0031] DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS [0032] Hereafter, a node includes, but is not limited to, a wireless transmit/receive unit (WTRU), a user equipment, a mobile station, a fixed or mobile subscriber unit, a pager, or any other type of device capable of operating in a wireless environment. When referred to hereafter, an access point includes, but is not limited to, a base station, a Node B, a site controller, or any other type of interfacing device in a wireless environment.
[0033] To avoid increasing system load and latency, the present invention provides for piggybacking acknowledgements (ACKs) on data packets. When a node receives a data packet, it updates the address field in the data packet and piggybacks the ACK of the received packet onto the forwarded data packet. Since the carrier sense multiple access with collision avoidance (CSMA/CA) medium access protocol allows all the near nodes to hear this transmission (by exploiting the exposed node problem), the previous and next nodes in the communication path will be able to hear the transmission. The previous node receives the ACK and the next node receives the forwarded data packet.
[0034] By transmitting only a single packet, instead of separate ACK and data packets, the system latency is improved and the system load is decreased. Utilizing this mechanism requires changing the 802.11 MAC frame format, to properly address the data packet and the ACK packet. It is noted that the source node, as referred to herein, is the node that is transmitting at the time in question, and not necessarily the node the originated the transmission. [0035] Figure 5 shows a diagram of an ACK mechanism for mesh networks in accordance with the present invention. In this example, node A sends a data frame (Data (I)) to node B. When node B receives the data frame, it forwards the data frame (Data (2)) to node C as follows:
[0036] 1) Piggyback the ACK to node A (ACK(I)) on the data frame; and [0037] 2) Forward the data frame with the piggybacked ACK (Data
(2VACK(I)) to node C.
[0038] Since node A also hears node B's transmission to node C, it knows that the packet was received successfully and that the ACK timer will not expire. A similar transmission occurs when node C forwards the data packet to node D. By way of example, three embodiments of this ACK mechanism may be employed as explained below.
[0039] Figure 6 shows a typical frame format under current 802.11 standards. The first embodiment of the ACK mechanism is a positive ACK mechanism; a data frame format in accordance with this embodiment is shown in Figure 7. When the destination node receives the data packet correctly, it piggybacks the ACK to the data packet indicating that the data packet was received properly.
[0040] This embodiment adds a field, Address 5, to indicate the ACK recipient's address (i.e., the source node). As shown in Figure 7, Address 1 indicates the data frame recipient's address (RA_data) and Address 5 indicates the ACK frame recipient's address (RA_ACK). As applied to the example shown in Figure 5, Address 1 would have the address of node C and Address 5 would have the address of node A.
[0041] The second embodiment of the ACK mechanism is an ACK/NACK mechanism. Similar to the first embodiment, when the destination node receives the data packet, it piggybacks the ACK to the data packet indicating that the data packet was received. Referring to Figure 8, Address 1 indicates the data frame recipient's address (RA_data) and the new field Address 5 indicates the ACK frame recipient's address (RA_ACK), as explained above. [0042] A second new field, called the ACK/NACK field, is a Boolean field. If it is set to zero, this means that the recipient did not receive the packet properly, and the recipient has the choice to either ACK or NACK the packet. The ACK/NACK field allows the destination node to send an ACK frame when it receives the packet from the sender properly, by setting the field to one. If the recipient node does not receive the packet (i.e., when a packet is received with an incorrect sequence number, the recipient knows that it missed the packet) or if the recipient node could not decode the received packet properly, it can send a NACK to the sender by setting the field to zero.
[0043] As applied to the example shown in Figure 5, the ACK/NACK field would be set to zero if node B did not correctly receive the Data(l) packet from node A. When node B sends the Data(2)/ACK(1) packet, node C receives the data packet, and node A is informed that the packet was incorrectly received by node B. Whether node B sends the Data(2) packet to node C depends on what caused the incorrect receipt at node B. If the current packet was not received properly, node B will not send a Data(2) packet to node C and will send a NACK to node A. However, if node B received the packet properly, but with a sequence number other than what it was expecting, node B can still forward the Data(2) packet to node C and send a NACK to node A for the missed packet. For example, if node B receives a packet with a sequence number of "n+1" instead of "n", then node B can forward the "n+1" packet to node C and send a NACK to node A for the "n" packet.
[0044] The third embodiment of the ACK mechanism is a negative acknowledgement (NACK) mechanism. In this embodiment, when the destination node does not receive a data packet, it sends a NACK to the source node to indicate that the data packet was missing. The destination node knows that it missed a packet when a packet is received with an incorrect sequence number or if a packet is received that it cannot decode correctly. The source node assumes that the data packet was received properly if it did not receive a NACK within a specific period of time. Figure 9 shows an example of a NACK frame in accordance with this embodiment. It is noted that the NACK frame format is the same as the standard 802.11 ACK frame format.
[0045] Figure 10 is a diagram of a node 1000 configured to add an ACK to a data packet in accordance with the present invention. The node 1000 includes an antenna 1002, a transmitter/receiver 1004 connected to the antenna 1002, and a packet updating device 1006 connected to the transmitter/receiver 1004. The packet updating device 1006 receives a data packet from the transmitter/receiver 1004, adds an ACK to the data packet, and returns the data packet with the ACK to the transmitter/receiver 1004. The packet updating device 1006 can add an ACK or a NACK to the data packet in accordance with any of the methods described above.
[0046] Embodiments
[0047] 1. A method for reducing latency in a mesh network, including the step of adding an acknowledgement (ACK) to a data packet.
[0048] 2. The method according to embodiment 1, further including the step of sending the data packet containing the ACK to a first node and a second node.
[0049] 3. The method according to any preceding embodiment wherein the first node is a source node, the second node is a destination node, and the adding step is performed at an intermediate node.
[0050] 4. A method for reducing latency in transmitting an acknowledgement (ACK) in a mesh network, including the steps of: receiving a data packet at an intermediate node from a source node; generating an ACK upon receipt of the data packet at the intermediate node; and forwarding the data packet from the intermediate node to a target node including the ACK in the forwarded data packet, whereby the source node receives the ACK while the target node receives the data packet.
[0051] 5. The method according to embodiment 4, wherein the data packet includes the address of the source node to receive the ACK.
[0052] 6. The method according to any of embodiments 4 or 5, wherein the data packet includes a field to indicate whether the packet was received at the intermediate node.
[0053] 7. The method according to any of embodiments 4-6, wherein the data packet includes the address of the source node to receive the ACK and a field to indicate whether the packet was received at the intermediate node.
[0054] 8. A system for reducing latency in transmitting an acknowledgement (ACK) in a mesh network having a source node, an intermediate node, and a target node, the system including: a data packet sent by the source node to the intermediate node; and an ACK generated by the intermediate node upon receipt of the data packet from the source node, the intermediate node forwarding the data packet with the ACK to the target node, whereby the source node receives the ACK while the target node receives the data packet.
[0055] 9. The system according to embodiment 8, wherein the data packet includes an address of the source node, the address being inserted into the data packet by the intermediate node prior to transmitting the data packet to the target node, such that the ACK is properly addressed to the source node.
[0056] 10. The system according to any of embodiments 8 or 9, wherein the data packet includes a field to indicate whether the packet was received at the intermediate node.
[0057] 11. The system according to any of embodiments 8-10, wherein the data packet includes an address of the source node, the address being inserted into the data packet by the intermediate node prior to transmitting the data packet to the target node, such that the ACK is properly addressed to the source node; and a field to indicate whether the packet was received at the intermediate node.
[0058] 12. A node for use in a mesh network, including an antenna; a transmitter/receiver connected to the antenna; and a packet updating device connected to the transmitter/receiver.
[0059] 13. The node according to embodiment 12, wherein the packet updating device adds an acknowledgement to a received packet, whereby upon transmission of the received packet, a first node receives the data contained in the packet and a second node receives the acknowledgement contained in the packet.
[0060] 14. The node according to embodiment 12, wherein the packet updating device uses the method of any one of embodiments 1-7.
[0061] 15. The node according to embodiment 12, wherein the node is part of the system of any one of embodiments 8-11. [0062] Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone (without the other features and elements of the preferred embodiments) or in various combinations with or without other features and elements of the present invention.

Claims

CLAIMS What is claimed is:
1. A method for reducing latency in transmitting an acknowledgement (ACK) in a mesh network, comprising the steps of: receiving a data packet at an intermediate node from a source node; generating an ACK upon receipt of the data packet at the intermediate node; and forwarding the data packet from the intermediate node to a target node including the ACK in the forwarded data packet, whereby the source node receives the ACK while the target node receives the data packet.
2. The method according to claim 1, wherein the data packet includes the address of the source node to receive the ACK.
3. The method according to claim 1, wherein the data packet includes a field to indicate whether the packet was received at the intermediate node.
4. The method according to claim 1, wherein the data packet includes: the address of the source node to receive the ACK; and a field to indicate whether the packet was received at the intermediate node.
5. A system for reducing latency in transmitting an acknowledgement (ACK) in a mesh network having a source node, an intermediate node, and a target node, the system comprising: a data packet sent by the source node to the intermediate node; and an ACK generated by the intermediate node upon receipt of said data packet from the source node, the intermediate node forwarding said data packet with said ACK to the target node, whereby the source node receives said ACK while the target node receives said data packet.
6. The system according to claim 5, wherein said data packet includes an address of the source node, the address being inserted into said data packet by the intermediate node prior to transmitting said data packet to the target node, such that said ACK is properly addressed to the source node.
7. The system according to claim 5 , wherein said data packet includes a field to indicate whether said packet was received at the intermediate node.
8. The system according to claim 5, wherein said data packet includes: an address of the source node, the address being inserted into said data packet by the intermediate node prior to transmitting said data packet to the target node, such that said ACK is properly addressed to the source node; and a field to indicate whether said packet was received at the intermediate node.
9. A node for use in a mesh network, comprising: an antenna; a transmitter/receiver connected to said antenna; and a packet updating device connected to said transmitter/receiver.
10. The node according to claim 9, wherein said packet updating device adds an acknowledgement to a received packet, whereby upon transmission of the received packet, a first node receives the data contained in the packet and a second node receives the acknowledgement contained in the packet.
PCT/US2005/031974 2004-09-10 2005-09-08 Reducing latency when transmitting acknowledgements in mesh networks WO2006031587A2 (en)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US60877504P 2004-09-10 2004-09-10
US60/608,775 2004-09-10
US11/010,465 2004-12-13
US11/010,465 US20060056421A1 (en) 2004-09-10 2004-12-13 Reducing latency when transmitting acknowledgements in mesh networks

Publications (2)

Publication Number Publication Date
WO2006031587A2 true WO2006031587A2 (en) 2006-03-23
WO2006031587A3 WO2006031587A3 (en) 2006-06-15

Family

ID=35853934

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2005/031974 WO2006031587A2 (en) 2004-09-10 2005-09-08 Reducing latency when transmitting acknowledgements in mesh networks

Country Status (6)

Country Link
US (1) US20060056421A1 (en)
KR (2) KR20060066617A (en)
AR (1) AR050872A1 (en)
DE (1) DE202005014255U1 (en)
TW (3) TW200620909A (en)
WO (1) WO2006031587A2 (en)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005101719A1 (en) * 2004-04-13 2005-10-27 Nokia Corporation Apparatus, and associated method, for providing a medium access control layer hybrid automatic repeat request scheme for a carrier sense multiple access communication scheme
US20060215708A1 (en) * 2005-03-24 2006-09-28 Intel Corporation Signaling/control transport
US7631021B2 (en) * 2005-03-25 2009-12-08 Netapp, Inc. Apparatus and method for data replication at an intermediate node
US7957362B2 (en) * 2005-06-01 2011-06-07 Texas Instruments Incorporated System and method of communication in mesh networks
US8799211B1 (en) * 2005-09-06 2014-08-05 Symantec Operating Corporation Cascaded replication system with remote site resynchronization after intermediate site failure
DE102005055150A1 (en) * 2005-09-30 2007-04-05 Rohde & Schwarz Gmbh & Co. Kg Message transmitting method for e.g. mobile ad-hoc network, involves transmitting acknowledgement of reception together with message using intermediate node, where message that is to be transmitted by node is message received by source node
DE102005049931B4 (en) * 2005-10-19 2009-04-09 Atmel Germany Gmbh Transmitting / receiving device
US20070115821A1 (en) * 2005-10-26 2007-05-24 Samsung Electro-Mechanics Co., Ltd. Method for transmitting wireless data using piggyback
KR100713378B1 (en) * 2006-01-13 2007-05-04 삼성전자주식회사 Method for detecting a hidden station in a wireless communication network
WO2007105765A1 (en) * 2006-03-15 2007-09-20 Matsushita Electric Industrial Co., Ltd. Wireless transmitting device and wireless transmitting method
US20080107116A1 (en) * 2006-11-08 2008-05-08 Sicortex, Inc. Large scale multi-processor system with a link-level interconnect providing in-order packet delivery
US7546302B1 (en) * 2006-11-30 2009-06-09 Netapp, Inc. Method and system for improved resource giveback
US7613947B1 (en) 2006-11-30 2009-11-03 Netapp, Inc. System and method for storage takeover
JP5283702B2 (en) 2007-08-24 2013-09-04 インターデイジタル パテント ホールディングス インコーポレイテッド Method and apparatus for reliably transmitting a radio block including a piggyback ACK / NACK field
US8320358B2 (en) 2007-12-12 2012-11-27 Qualcomm Incorporated Method and apparatus for resolving blinded-node problems in wireless networks
US20100137021A1 (en) * 2008-11-28 2010-06-03 Eric Sharret System, Method and Devices for Communications via a Mesh Network
KR101499755B1 (en) * 2009-03-19 2015-03-18 삼성전자주식회사 Intermediate node device, method for controlling the intermediate node device, and network system
US9912568B2 (en) * 2009-06-24 2018-03-06 Provenance Asset Group Llc Method and apparatus for handling broken path in peer-to-peer network
KR101200792B1 (en) * 2011-05-24 2012-11-13 성균관대학교산학협력단 An network broadcast method using mac unicast and multipoint relays
US9608789B2 (en) 2012-05-11 2017-03-28 Interdigital Patent Holdings, Inc. Method and apparatus for transmitting acknowledgements in response to received frames
US8831008B1 (en) * 2013-04-19 2014-09-09 Cubic Corporation Reliable message delivery in mesh networks
US9492741B2 (en) 2013-05-22 2016-11-15 Microsoft Technology Licensing, Llc Wireless gaming protocol
TWI542164B (en) 2014-05-21 2016-07-11 微晶片科技公司 Blue-tooth communication system and broadcasting method thereof
WO2016029366A1 (en) * 2014-08-26 2016-03-03 华为技术有限公司 Access method and device
US9992042B2 (en) * 2014-12-17 2018-06-05 Intel Corporation Pipelined hybrid packet/circuit-switched network-on-chip
CN106937241B (en) * 2015-12-31 2021-05-18 华为技术有限公司 Time sequence data detection method and device
JP6612434B2 (en) * 2016-03-31 2019-11-27 京セラ株式会社 Network equipment
MX2018012121A (en) 2016-04-07 2019-02-11 Ericsson Telefon Ab L M Radio-network node, wireless device and methods performed therein.
WO2019182421A1 (en) * 2018-03-23 2019-09-26 엘지전자 주식회사 Method for supporting harq process in wireless lan system and wireless terminal using same
US11296966B2 (en) 2019-11-27 2022-04-05 Rockwell Collins, Inc. System and method for efficient information collection and distribution (EICD) via independent dominating sets
US11726162B2 (en) 2021-04-16 2023-08-15 Rockwell Collins, Inc. System and method for neighbor direction and relative velocity determination via doppler nulling techniques
US11665658B1 (en) 2021-04-16 2023-05-30 Rockwell Collins, Inc. System and method for application of doppler corrections for time synchronized transmitter and receiver
US11737121B2 (en) 2021-08-20 2023-08-22 Rockwell Collins, Inc. System and method to compile and distribute spatial awareness information for network
US11290942B2 (en) 2020-08-07 2022-03-29 Rockwell Collins, Inc. System and method for independent dominating set (IDS) based routing in mobile AD hoc networks (MANET)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038216A (en) * 1996-11-01 2000-03-14 Packeteer, Inc. Method for explicit data rate control in a packet communication environment without data rate supervision
US6208622B1 (en) * 1997-11-04 2001-03-27 International Business Machines Corporation Traffic flow cutover to virtual connection transport
US20010025310A1 (en) * 2000-02-04 2001-09-27 Srikanth Krishnamurthy System for pricing-based quality of service (PQoS) control in networks
US20030025959A1 (en) * 2001-07-31 2003-02-06 Ramesh Nagarajan Connection setup strategies in optical transport networks

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6490259B1 (en) * 2000-02-24 2002-12-03 Telcordia Technologies, Inc. Active link layer and intra-domain mobility for IP networks
US6839752B1 (en) * 2000-10-27 2005-01-04 International Business Machines Corporation Group data sharing during membership change in clustered computer system
US20030065811A1 (en) * 2001-05-16 2003-04-03 Lin Philip J. Methods and apparatus for allocating working and protection bandwidth in a network
US7486696B2 (en) * 2002-06-25 2009-02-03 Avaya, Inc. System and method for providing bandwidth management for VPNs
US6996368B2 (en) * 2003-01-21 2006-02-07 Mitsubishi Electric Research Labs., Inc. System and method for reducing power consumption in a wireless communications network
US7487541B2 (en) * 2003-12-10 2009-02-03 Alcatel Lucent Flow-based method for tracking back single packets

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6038216A (en) * 1996-11-01 2000-03-14 Packeteer, Inc. Method for explicit data rate control in a packet communication environment without data rate supervision
US6208622B1 (en) * 1997-11-04 2001-03-27 International Business Machines Corporation Traffic flow cutover to virtual connection transport
US20010025310A1 (en) * 2000-02-04 2001-09-27 Srikanth Krishnamurthy System for pricing-based quality of service (PQoS) control in networks
US20030025959A1 (en) * 2001-07-31 2003-02-06 Ramesh Nagarajan Connection setup strategies in optical transport networks

Also Published As

Publication number Publication date
KR200404707Y1 (en) 2005-12-27
KR20060066617A (en) 2006-06-16
TW200943837A (en) 2009-10-16
AR050872A1 (en) 2006-11-29
TWM291146U (en) 2006-05-21
WO2006031587A3 (en) 2006-06-15
US20060056421A1 (en) 2006-03-16
TW200620909A (en) 2006-06-16
DE202005014255U1 (en) 2006-02-09

Similar Documents

Publication Publication Date Title
US20060056421A1 (en) Reducing latency when transmitting acknowledgements in mesh networks
US9706576B2 (en) Method for multicast frame transmission and duplicated multicast frame detection
AU2008358409B2 (en) Apparatus for requesting acknowledgement and transmitting acknowledgement of multicast data in wireless local area networks
US8553548B2 (en) Collision mitigation for multicast transmission in wireless local area networks
Tang et al. MAC reliable broadcast in ad hoc networks
US7801063B2 (en) Method and apparatus for rate fallback in a wireless communication system
EP2294741B1 (en) Method and apparatus for acknowledgement and retransmission of multicast data in wireless local area networks
US7054329B2 (en) Collision avoidance in IEEE 802.11 contention free period (CFP) with overlapping basic service sets (BSSs)
US7894381B2 (en) System and method of reliably broadcasting data packet under ad-hoc network environment
US20030227934A1 (en) System and method for multicast media access using broadcast transmissions with multiple acknowledgements in an Ad-Hoc communications network
US20110096711A1 (en) Apparatus for collision mitigation of multicast transmissions in wireless networks
Wang et al. SYN-DMAC: A directional MAC protocol for ad hoc networks with synchronization
US20070025379A1 (en) Method of providing a medium access protocol
KR20160125436A (en) Avoiding extended interframe space
RamMohan et al. A new protocol to mitigate the unheard RTS/CTS problem in networks with switched beam antennas
JP2008211600A (en) Radio communication system, communication device and method for controlling communication
Zhao et al. A rate-adaptive cooperative MAC protocol based on RTS/CTS scheme for MANETs
Shigeyasu et al. A broadcasting method for suppressing hidden terminals effect on IEEE802. 11DCF
Si et al. RMAC: A New MAC Protocol with Reliable Multicast Support for Wireless Ad-Hoc Networks

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KM KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NG NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SM SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU LV MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase