WO2018014795A1

WO2018014795A1 - Method and apparatus for packet transmission

Info

Publication number: WO2018014795A1
Application number: PCT/CN2017/093032
Authority: WO
Inventors: Ronald Chi-Chun Hui
Original assignee: Vishare Technology Limited
Priority date: 2016-07-21
Filing date: 2017-07-14
Publication date: 2018-01-25

Abstract

A method executes packet transmission with improved latency. The method improves latency for packet transmission with an acknowledgement packet that includes a cumulative acknowledgment number and a reception bit vector. The cumulative acknowledgment number indicates a sequence number of a next data packet expected to be received by a receiver. Each bit of the reception bit vector indicates the reception status of a corresponding packet with a sequence number larger than or equal to the cumulative acknowledgement number.

Description

Method and Apparatus for Packet Transmission

FIELD OF THE INVENTION

The present invention relates to information technology, and more particularly to methods and apparatus that executes packet transmission.

BACKGROUND

Network data (e.g., data packets) are often required to be transmitted from one electronic device to another over one or more networks for various purposes. Correct reception of data packets in a sequential order is essential. Reception of data packets is often acknowledged by electronic devices to ensure all communications reach their destinations. Acknowledgement mechanisms are supported by various protocols, such as Transmission Control Protocol (TCP) , User Datagram Protocol (UDP) -based Data Transfer Protocol (UDT) , 802.11, etc.

New methods and apparatus that assist in advancing technological needs and industrial applications in information technology such as packet transmission are desirable.

SUMMARY OF THE INVENTION

One example embodiment is a method that executes packet transmission with improved latency. The method improves latency for packet transmission with an acknowledgement packet that includes a cumulative acknowledgment number and a reception bit vector. The cumulative acknowledgment number indicates a sequence number of a next data packet expected to be received by a receiver. Each bit of the reception bit vector indicates the reception status of a corresponding packet with a sequence number larger than or equal to the cumulative acknowledgement number.

Other example embodiments are discussed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 illustrates an electronic system that executes packet transmission in accordance with an example embodiment.

Figure 2 illustrates an electronic system that executes packet transmission in accordance with another example embodiment.

Figure 3 illustrates a scheme that selects a data packet for transmission in accordance with an example embodiment.

Figure 4 illustrates an electronic system that executes packet transmission in accordance with an example embodiment.

Figure 5 illustrates a method in accordance with an example embodiment.

Figure 6 illustrates a scheme that selects a data packet for transmission in accordance with an example embodiment.

Figure 7 illustrates a packet transmission system in accordance with an example embodiment.

Figure 8 is a graph illustrating how active relay nodes are combined with other network nodes to support multi-hop packet delivery in accordance with an example embodiment.

Figure 9 illustrates a packet transmission system in accordance with an example embodiment.

Figure 10 illustrates an adaptive relay node in accordance with an example embodiment.

Figure 11 illustrates a method executed by an active relay node in accordance with an example embodiment.

Figure 12 illustrates a packet transmission process in accordance with an example embodiment.

Figure 13 illustrates a method that executes packet transmission in accordance with an example embodiment.

Figure 14 illustrates an electronic system that executes packet transmission in accordance with an example embodiment.

Figure 15 illustrates an electronic system that executes packet transmission in accordance with an example embodiment.

DETAILED DESCRIPTION

Example embodiments relate to methods and apparatus that execute packet transmission in unconventional ways to improve performance for packet transmission in the field of information technologies and applications.

Conventional schemes for packet transmission, especially conventional systems that involve wireless channels, are flawed in various aspects. As an example, some conventional schemes, such as Transmission Control Protocol (TCP) scheme, cause underutilization of network resources and increase packet delays or latency accordingly. As another example, when packet retransmission is required, many conventional schemes have relatively low reliability that is unqualified for quick retransmission. If acknowledgements are sent too frequently, the efficiency is low. If the acknowledgements are sent at a longer interval, it takes long time for a transmitter or sender to be aware of packet loss and retransmission delay becomes longer as well. For conventional schemes that use negative acknowledgement (NACK) packets to trigger retransmission, loss of NACK packets would increase retransmission latency. As a further example, some conventional schemes do not support multicasting, while many conventional schemes that support multicasting have large latency and thus are not suitable for applications such as video streaming.

Example embodiments solve one or more of the above technical problems associated with conventional schemes for packet transmission. Example embodiments provide technical solutions in new methods and apparatus that improve performance for packet transmission in various aspects. Example embodiments achieve improved performance, such as improved reliability and latency in executing packet transmission by providing new technical solutions that operate in unconventional ways to contribute to information technology.

One or more example embodiments include methods, systems, and apparatus that support a reliable data protocol (RDP) as a reliable transmission protocol optimized and adapted for low-latency and reliable packet delivery. By way of example, example embodiments improve performance such as latency by employing a combination of a cumulative acknowledgement number and a reception bit vector to acknowledge packet reception and request retransmission.

One or more example embodiments include methods, systems, and apparatus that support reliable multicasting in a multicast network. Example embodiments enable multiple receivers receive data packets in a sequential order. Example embodiments monitor reception status of a data packet with reliable schemes. When acknowledged with transmission error, or failure, or packet loss by at least one receiver, a sender multicasts or resends the data packet.

One or more example embodiments include one or more adaptive relay nodes that reduce network loading, shortens latency, and improve transmission quality by performing active relay functions. The one or more adaptive relay nodes buffer data packets received from a source node, and resend the data packet to a destination node on behalf of the source node when packet loss or transmission failure is detected.

One or more example embodiments include methods, systems, and apparatus that achieve various technical advantages or effects by combining multicasting and active relay functions in a multicast network to support adaptive packet relay.

Figure 1 illustrates an electronic system 100 that executes packet transmission in accordance with an example embodiment.

As illustrated, the electronic system 100 includes a sender 110 and a receiver 120. By way of example, the electronic system 100 is a system that supports a protocol for reliable data transmission (also referred as reliable data protocol (RDP) ) . In an example embodiment, the electronic system 100 is also called a RDP system. In another example embodiment, each of the sender 110 and the receiver 120 includes a transceiver that can transmit and receive data packets.

By way of example, the sender 110 sends or transmits data packets or packets 112 to the receiver 120. The receiver 120 generates an acknowledgement (ACK) packet 114 that is transmitted to the sender 110 to indicate reception status of the data packets 112. The ACK packet 114 includes a cumulative acknowledgment number or cumulative ACK number 116 and a reception bit vector 118. The cumulative ACK number 116 indicates a sequence number of a next data packet expected to be received by the receiver 120. The reception bit vector 118 includes one or more reception bits. Each bit of the reception bit vector indicates the reception status of a corresponding packet with a sequence number p, such that p is larger than or equal to the cumulative acknowledgement number and p can be calculated from the bit position.

By way of example, one important function of the ACK packet 114 is to inform the sender 110 about lost or corrupted data packets. In an example embodiment, if there is no packet transmission error or failure, the receiver 120 delays sending the ACK packet 114 as long as possible. In some example embodiments, while the sender 110 is not receiving acknowledgement packets due to deliberate delayed transmission by receiver 120 or uncontrolled network delays, the sender 110 can keep sending packets as long as there is a space available in a buffer of the sender 110 for storing the new packet, thus maximizing the data throughput. One advantage of the example system is that if detecting a possible transmission error, the receiver 120 can explicitly specify which data packet is or is not received with the minimum bandwidth.

By way of example, the receiver 120 keeps track of the cumulative ACK number 116 (denoted as nextRcvData) . The cumulative ACK number 116 is next data sequence expected to be received. Additional and optionally, the receiver 120 manages the reception bit vector 118 for other received packets. For example, if the receiver 120 receives a data packet with a sequence number larger than or equal to nextRcvData, the corresponding reception bit in the reception bit vector 118 is ‘1’ . Otherwise, the corresponding reception bit is ‘0’ . The receiver 120 acknowledges multiple data packets by sending the ACK packet 114 containing at least the two pieces of information, i.e. the nextRcvData 116 and the reception bit vector 118.

By way of example, receipt of nextRcvData by the sender 110 implies that the receiver 120 has received all data packets with sequence numbers smaller than nextRcvData. Based on the nextRcvData of the received ACK packet 114, the sender 110 updates the next data sequence expected to be acknowledged by the receiver 120, denoted as nextAckedData. Additionally and optionally, according to the reception bit vector 118 in the ACK packet 114, the sender 110 determines whether each sent packet that has a sequence number larger than or equal to nextRcvData is received by the receiver 120 successfully, lost or not received within a timeout period. Then the sender 110 can update its sndStatus bit vector and decide how to resend the lost and/or timeout packets accordingly. The sndStatus bit vector will be described later.

By way of example, after sending a new acknowledgement packet, the receiver 120 increases the next acknowledgement sequence number by one. In some example embodiments, an acknowledgement packet repeatedly acknowledges a data packet which has already been acknowledged by another acknowledgement packet sent at an earlier time. In an example embodiment, the acknowledgement packet (e.g., the ACK packet 114) includes redundancy information. In this case, the receiver 120 can acknowledge the sender 110 about the most updated packet reception status even if some acknowledgement packets are lost. Because of the redundancy information in the acknowledgement packet, the data packet that is most recently sent (i.e., the packet with a larger acknowledgement sequence number) always includes the most updated information. Therefore, when receiving an older acknowledgement packet, the sender 110 can discard the older acknowledgement packet.

Figure 2 illustrates an electronic system 200 that executes packet transmission in accordance with another example embodiment.

By way of example, the electronic system 200 includes a sender device or sender 210 and a receiver device or receiver 220 that communicates data packets or packets with the sender 210. The sender 210 includes one or more packet buffers or buffers 216, and the receiver 220 includes one or more packet buffers or buffers 226.

By way of example, the sender 210 and the receiver 220 coordinate with each other to perform four different operations:

1. Data packet transmission by the sender 210 (indicated by arrow 212) ；

2. Data packet reception by the receiver 220 (also indicated by arrow 212) ；

3. Acknowledgement packet transmission by the receiver 220 (indicated by arrow 214) ； and

4. Acknowledgement packet reception by the sender 210 (also indicated by arrow 214) .

In an example embodiment, for illustrative purpose only, the number of buffers 216 is N, and the number of buffers 226 is also N, where N is a whole number larger than zero. By way of example, N＝2^n, which means N is the result of exponentiation with number two as the base and integer n as the exponent, where n is a positive integer. b represents buffer index. The buffer index b varies from 0 to (2ⁿ-1) . The sender 210 stores the next-store sequence number (denoted as ‘nextStore’ ) . For example, the next-store sequence number initially can be set to an arbitrary default value, such as zero. A data packet with a sequence number p is stored at buffer location b, where b＝p％N and ％represents modulo operation. The buffer location is linked with the sequence number, which makes it easier to locate and retrieve a data packet with a particular sequence number from the buffers.

In an example embodiment, the sender 210 at least stores and updates the following information to support data packet transmission:

- nextAckedData: the next data sequence number expected to be acknowledged； nextAckedData is also the smallest data sequence number that has not been acknowledged yet；

- estRate: estimated channel rate reported by the most updated acknowledgement packet； it is also called estimated data rate； and

- sndStatus [] : packet delivery status for each buffered packet of which the sequence number is equal to or larger than nextAckedData； sndStatus [] is updated with the most updated acknowledgement packet. All entries of sndStatus [] are initialized to ‘RECEIVED’ . sndStatus [] has one of the following values:

UNSENT: Packet is stored but not sent yet；

UNKNOWN: Packet is sent but it is not known if it is received yet；

RECEIVED: Packet is received and acknowledged；

DROPPED: Packet is sent but an acknowledge packet indicates that the packet is dropped； and

TIMEOUT: Packet is sent but not acknowledged within a timeout interval.

In an example embodiment, when the sender 210 receives a new packet from an upper-layer network component or an end-use application, the sender 210 checks if there is a buffer available for storing the new packet. By way of example, the sender 210 has N packet buffers 216, such that N ＝ 2^n and n is a positive integer. The sender 210 checks if sndStatus [b] equals to RECEIVED, where b ＝ (nextStore％N) . If sndStatus [b] equals to RECEIVED, the sender 210 performs the following operations:

1. Stores the new packet at buffer b；

2. Increases nextStore by 1； and

3. Changes sndStatus [b] to UNSENT.

If sndStatus [b] does not equal to RECEIVED, a storage fail signal will be outputted to higher layer software and the new packet is not stored.

In an example embodiment, the receiver 220 reports the estimated data rate (denoted as “estRate” ) , so that the sender 210 can accurately limit the transmission data rate to maximize communication channel utilization while avoiding congestion. For example, the sender 210 sends the next data packet only if the sender 210 determines that transmission loading does not exceed estRate. If the transmission loading exceeds estRate, no packet is sent. In an example embodiment, the sender 210 decides whether there is eligible packet to be sent, as well as which packet should be sent when the eligible packet is found. For example, a packet is eligible to be sent if the packet has not been sent yet or the packet has been sent but an acknowledgement shows that the packet is lost or not received by the receiver 220 within timeout. In this case, sntStatus equals to either UNSENT, DROPPED, or TIMEOUT. If there are multiple eligible packets, the eligible packet with the smallest sequence number is selected for transmission.

Figure 3 illustrates a scheme 300 that selects a data packet for transmission in accordance with an example embodiment.

In this example embodiment, the next packet to be sent is denoted as “nextSent” . Block 305 initializes nextSent. For example, the nextSent is set as undefined initially. Block 310 sets p＝nextAckedData. p is a variable indicating a sequence number of a data packet that is stored in a buffer of a sender. For example, the sender has N buffers with buffer index b where N is a positive integer. Iteration steps or loop begin with block 320. Block 320 sets b＝p％N, where ％represents modulo operation. Block 330 decides whether the value of sndStatus [b] equals to UNSENT, DROPPED, or

TIMEOUT. If sndStatus [b] equals to one of UNSENT, DROPPED, and TIMEOUT, the flow goes to block 340 where sndStatus [b] is updated as sndStatus [b] ＝UNKNOWN, and nextSent is updated as nextSent＝p, which indicates the data packet with sequence number being p is selected as next data packet for transmission. The flows jump out of the iteration loop and ends at block 370.

If sndStatus [b] does not equal to any of UNSENT, DROPPED, and TIMEOUT at block 330, the flow goes to block 350 where the variable p is updated as p＝p+1, which indicates next data packet is examined to determine whether the next data packet should be selected for transmission. Block 360 examines whether p<nextStore. Since the largest stored data sequence or sequence number is (nextStore-1) and so the scanning process stops when p＝nextStore. If p＝nextStore, it indicates no data packet is eligible to be sent, then the flow jumps out of the iteration loop and ends at block 370. If p is determined as p<nextStore at block 360, then the flow goes back to block 320 and starts a new cycle within the iteration steps.

By way of example, when the receiver receives a data packet with a sequence number p, the packet will be stored at buffer b of the receiver. For example, b＝p％N. The receiver outputs the received data packets in an order of increasing sequence numbers so as to ensure in-order data delivery. In an example embodiment, the receiver updates at least the following data:

1. nextRcvData: the expected sequence number of the next data packet to be received. nextRcvData is also the smallest number among all sequence numbers of the packets not received yet；

2. rcvStatus [] : this is an N-bit vector which shows the packet reception status of N packets, each with a sequence number p, such that p>＝nextRcvData. If a packet with the sequence number p is received, then the b^th bit is set to ‘RCV’ state, such that b ＝ p％N；

3. estRate: the estimated maximum data transmission rate between the sender and the receiver.

By way of example, the receiver sends an acknowledgement packet which carries at least the following information:

1. nextRcvData；

2. estimated channel rate； and

3. rcvStatus bit vector

By way of example, when the sender receives an acknowledgement packet, the sender checks if the acknowledgement sequence number is larger than that of the previously received acknowledgement packet. In an example embodiment, if the acknowledgement sequence number is not larger than that of the previously received acknowledgement packet, the acknowledgement packets is likely not to be received in order and so the sender discards the packets. Otherwise, the acknowledgement packet is further processed. For example, the sender forwards the estimated channel rate to the upper layer software so that the upper layer software changes the transmission bit rates accordingly. As another example, the sender extracts nextRcvData and the receiving bit vector to update the sndStatus of its buffered packets. The sender confirms that all packets, each with a sequence number p, are received, such that

nextAckedData <＝ p <nextRcvData.

Afterwards, the value of nextAckedData is updated such that nextAckedData＝nextRcvData. The sender decodes the reception bit vector to update the corresponding entries of the array sndStatus [] . For each packet with a sequence number p, such that p>＝nextRcvData, the corresponding sndStatus entry is set to 'RECEIVED'if the corresponding rcvStatus bit is '1' .

Figure 4 illustrates an electronic system 400 that executes packet transmission in accordance with an example embodiment. The electronic system 400 includes a sender 410 and multiple receivers 420-1, 420-2, …, 420-C, where C is a number of receivers.

As illustrated, the sender 410 multicasts data packets to the multiple receivers 420-1, 420-2, …, 420-C, and receives acknowledgement (ACK) packets (e.g., the ACK packet 114 with reference to Figure 1) from these multiple receivers. By way of example, the electronic system 400 adapts RDP protocol to support multicasting. The electronic system 400 allows data broadcasting from the sender 410 to the multiple receivers 420-1, 420-2, …, 420-C simultaneously.

Figure 5 illustrates a method 500 in accordance with an example embodiment. The method 500, for example, can be executed by the electronic system 400 with reference to Figure 4.

By way of example, at block 502, a sender (e.g., the sender 410) multicasts a data packet to a plurality of receivers (e.g., the multiple receivers 420-1, 420-2, …, 420-C) . In an example embodiment, if any of the plurality of receivers detects loss or transmission failure or error of the data packet, this receiver individually generates an acknowledgement (ACK) packet to report its own nextRcvData and receiving bit vector. In another example embodiment, each of the plurality of receivers generates an ACK packet to report its own reception status of the data packet to the sender.

At block 504, the sender receives an acknowledgement (ACK) packet from each of the plurality of receivers. For example, each ACK packet includes a cumulative acknowledgment number and a reception bit vector to indicate reception status for the data packet. In an example embodiment, if the sender does not receive an ACK packet from a receiver of the plurality of the receivers within a predetermined period of time, the sender assumes that this receiver does not detect any packet loss, or that this receiver receives the data packet successfully and correctly.

At block 506, the sender retransmits or resends the data packet when the data packet is determined by at least one receiver of the plurality of receivers as not being received. For example, the sender determines the reception status reported from each of the plurality of receivers by examining the ACK packet sent by the each receiver. For example, the sender determines that a packet with a sequence number p as being received by all receivers if the cumulative ACK number from each receiver is larger than p. For example, if the corresponding reception bit in the reception bit vector for the data packet is ‘1’ for all receivers, the sender designates the data packet as being received. If the corresponding reception bit for one or more receivers is ‘0’ , the sender resends the data packet to the plurality of receivers. In another example embodiment, the sender resends the data packet if the data packet is not received in order.

In an example embodiment, the receiver device or receiver supporting multicasting at least stores the following data as defined above, i.e. nextRcvData, rcvStatus and estRate. The sender device or sender at least stores and updates the following information to support multicasting:

- C: the number of receivers that receive multicast packets；

- nextRcvData [c] : it is extracted from acknowledgement packets sent by the c^th receiver and nextRcvData [c] denotes the next data sequence number that the c^th receiver expected to receive；

- nextAckedData: the next data sequence number expected to be acknowledged； nextAckedData is also the smallest data sequence number that at least one receiver has not acknowledged yet. More specifically, nextAckedData ＝min(nextRcvData [c] ) for all c；

- estRate: estimated multicast rate； and

- mcastStatus [b] [c] : multicast packet reception status of the p^th data packet as reported by the c^th receiver. mcastStatus [b] [c] , where b＝p％N, may have one of the following values:

UNSENT: Packet is stored but not sent yet；

UNKNOWN: Packet is sent but it is not known if it is received by the c^th receiver yet；

RECEIVED: Packet is received and acknowledged by the c^th receiver； and

DROPPED: Packet is sent but NOT received by the c^th receiver；

TIMEOUT: Packet is sent but not acknowledged within a timeout interval by the c^th receiver.

By way of example, the sender checks estRate to decide whether it can send a packet. If so, the sender selects which packet to send by checking the mcastStatus [b] [c] for all b and c to find the packet with the smallest sequence number p’ such that mcastStatus [b’ ] [c’ ] equals to ‘UNSENT’ , ‘DROPPED’ or ‘TIMEOUT’ for some c’ .

Figure 6 illustrates a scheme 600 that selects a data packet for transmission in accordance with an example embodiment.

In an example embodiment, the next data packet to be sent is denoted as ‘nextSent’ . Block 605 initializes nextSent. For example, nextSent is set as undefined initially. Block 610 sets a variable p＝nextAckedData, where p is a sequence number of a data packet that is stored in a buffer of the sender. The sender has N buffers with buffer index b, N being a positive integer. First iteration steps or external iteration steps begin at block 620. Block 620 sets b＝p％N and c＝0, where ％represents modulo operation and c represents receiver index for a plurality of receivers. The flow goes to second iteration steps or loop at block 630 where it is decided whether the value of mcastStatus [b] [c] equals to UNSENT, DROPPED, or TIMEOUT. If the value of mcastStatus [b] [c] equals to any of UNSENT, DROPPED, and TIMEOUT, then the flow jumps out of the first and second iteration steps by going to block 640. Block 640 chooses the data packet with sequence number p as a next packet to be sent by setting nextSent＝p, and updates mcastStatus. For example, for first transmission, block 640 updates mcastStatus by setting mcastStatus [b] [c] ＝UNKNOWN for all c, where b＝p％N. Then the flow ends at block 690.

If the value of mcastStatus [b] [c] does not equal to any of UNSENT, DROPPED, and TIMEOUT at block 630, the flow goes to block 650 where c is updated as c＝c+1, which examines reception status for next receiver. Block 660 examines whether c<C. If c<C, then the flow goes back to block 630 to start next loop for the second iteration steps such that reception status for all receivers are examined.

If c<C is not true, then the flow jumps out of the second iteration steps and goes to block 670 where p is updated as p＝p+1 to examine the next data packet stored in the buffer. Block 680 examines whether p<nextStore. If p<nextStore is not true, which indicates the status of all buffered packets are examined already but no packet is selected yet, then the flow jumps out of the first iteration steps and ends at block 690. If p is determined as p<nextStore at block 680, then the flow goes back to block 620 and starts a new loop within the first iteration steps to check the multicast status of the next packet.

By way of example, if nextSent is undefined after completion of all iteration steps, no data packet is sent. Otherwise, after completion of all iteration steps, the data packet with sequence number of nextSent is chosen or selected for transmission.

In an example embodiment, after receiving one or multiple data packets, each receiver sends an acknowledgement packet signifying that this receiver has received all data bytes or data packets preceding its own acknowledged sequence number. As an example, the acknowledge number sent by the r^th receiver is denoted as ack [r] . The sender finds out ack_min the minimum of all received acknowledged number, i.e. min (ack [r] ) for all r, and determines how to send or resend packets using ack_min.

Example embodiments include scenarios in which a data packet is transmitted from a source node S, via multiple intermediate nodes N_i, to a destination node D. By way of example, if a node N_i sends a data packet to a node N_i+1 via a direct link, then the node N_i is defined as the upstream node relative to N_i+1, while the node N_i+1 is defined as the downstream node relative to the node N_i.

Figure 7 illustrates a packet transmission system 700 in accordance with an example embodiment.

As illustrated, the system 700 includes a source node 710, a destination node 720, and an adaptive relay node 730 that acts as a communication intermediary between the source node 710 and the destination node 720. The system 700 facilitates packet transmission by supporting multi-hop packet delivery.

By way of example, the source node 710 is a sender, such as the

sender

110 or 410 as stated above. The destination node 720 is a receiver, such as the receiver 120, or one of 420-1, 420-2, …, 420-C as stated above. The active relay node 730 performs packet buffering and lost packet retransmission on behalf of the source node 710 when a data packet transverses multiple nodes to reach the destination node 720.

Although Figure 7 shows only one adaptive relay node between the source node 710 and the destination node 720, a person having ordinary skill in the art would appreciate that the system 700 can include multiple network nodes or multiple nodes between the source node 710 and the destination node 720. The multiple nodes includes, for example, one or more adaptive relay nodes, one or more other network nodes that do not provide active relay function, such as switches and routers. Thus, a data packet can be delivered from the source node 710 to the destination node 720 with multi-hops via multiple network nodes. As used herein, when a node has “active relay function” , it means this node can perform packet retransmission function on behalf of the source node in case of packet loss, transmission failure, error, or acknowledgement timeout, or the like.

By way of example, an upstream node of an active relay node can be one of the followings:

- another active relay node；

- the source node； and

- another network device, such as router or switch that does not provide the active relay function.

By way of example, a downstream node of an active relay node can be one of the followings:

- another active relay node；

- the destination node； or

- another network device, such as router or switch that does not provide the active relay function

Figure 8 is a graph 800 illustrating how active relay nodes are combined with other network nodes to support multi-hop packet delivery in accordance with an example embodiment.

As illustrated by the graph 800, S represents a source node, and D represents a destination node. A_i (i＝1, 2, 3, 4) represents active relay nodes. R_i (i＝1, 2) represents intermediate network nodes that do not perform active relay function. For example, R_i can be a router or a switch. A data packet at the source node can reach the destination node via multi-hops, where one or more active relay nodes can perform active relay function to resend the data packet to the destination node on behalf of the source node when packet loss is detected. As an example, the one or more active relay nodes make use of a connection-oriented communication protocol like RDP described in the previous section, or prior art protocol like TCP.

Figure 9 illustrates a packet transmission system 900 in accordance with an example embodiment.

As illustrated, the system 900 includes a source node 910, an adaptive relay node 930, and multiple destination nodes 920-1, 920-2, …, 920-m. Compared with the system 700 in Figure 7, the system 900 allows the adaptive relay node 930 to broadcast or transmit data packets to multiple destination nodes.

In one example embodiment, the system 900 includes multiple adaptive relay nodes. In another example embodiment, the system 900 includes other network nodes that do not perform active relay function such as routers and switches.

In some example embodiments, the source node 910 broadcasts data packets to the adaptive relay node 930 and the multiple destination nodes 920-1, 920-2, …, 920-m. The adaptive relay node 930 also buffers the data packets. When at least one of the multiple destination nodes 920-1, 920-2, …, 920-m detects packet loss, the adaptive relay node 930 resends the data packets that are buffered to the multiple destination nodes 920-1, 920-2, …, 920-m simultaneously.

Figure 10 illustrates an adaptive relay node 1000 in accordance with an example embodiment. The adaptive relay node 1000 includes an uplink receiver 1010, a relay buffer 1020, and a downlink sender 1030.

By way of example, the uplink receiver 1010 receives a data packet from a source node or upstream node and requests the upstream node to execute packet retransmission when packet loss is detected. The replay buffer 1020 communicates with the uplink receiver 1010 and stores the data packet. The downlink sender 1030 fetches the data packet from the relay buffer 1020, transmits the data packet to a downstream node or a destination node such as a receiver, and instructs the replay buffer 1020 to free buffer space upon receipt of positive acknowledgement from the downstream node.

In an example embodiment, after determining a path of packet delivery, the active relay node 1000 along the path set up two connections with the upstream active relay node or source node and downstream active relay node or destination node, where the connection is denoted as the uplink and downlink respectively. Data packets or packets are sent over uplink and downlink using any connection oriented protocol like RDP, TCP, etc. The upstream link or the downstream link can be a direct physical links to an active relay node/source/destination or a virtual connection that exchanges packets with an active relay node/source/destination through multiple intermediate nodes.

In another example embodiment, the uplink receiver 1010 receives RDP packets or uplink data packets or data packets 1012 from an upstream node via an upstream link. The received packets 1016 are transmitted to and stored in the relay buffer 1020. Additionally and optionally, the uplink receiver 1010 sends uplink acknowledgement (ACK) packets 1014 to the upstream node to request retransmission if packet lost or timeout is detected. The downlink sender 1030 sends RDP packets or downlink data packets or data packets 1034 to a downstream node. Additionally and optionally, the downlink sender 1030 fetches data packets 1022 from the relay buffer 1020 and sends the fetched data packets via a downstream link or downlink to the downstream node. As an example, when the downlink sender 1030 receives a downlink acknowledgement (ACK) packet 1036 from the downstream node, the downlink sender 1030 determines which packets should be retransmitted and the relay buffer 1020 checks if the packets that should be retransmitted are still buffered. If the packets that should be retransmitted are still buffered, the downlink sender 1030 fetches the data packets from the relay buffer 1020 and resends them to the downstream node. Additionally and optionally, if the downstream node positively acknowledges correct reception of a packet, the downlink sender 1030 send instructions 1032 to instruct the relay buffer 1020 to free the buffer space allocated to the acknowledged packet.

In some examples, depending on various service requirements, the relay buffer 1020 reserves various amount of buffer space for each RDP connection. Alternatively, the relay buffer 1020 dynamically determines to drop some packets to free the buffer space for other packets. In an example embodiment, the relay buffer 1020 determines a predetermined time value or time-to-live value for each buffered packet. When the storage time for a data packet exceeds the time-to-live value, the relay buffer 1020 drops this data packet. In another example embodiment, a data packet is dropped at the adaptive relay node 1000, the downstream node requests for retransmission of this data packet from the source node when the data packet is not received by the downstream node. In one other example embodiment, the downstream node requests for retransmission of this data packet from other upstream node in which the dropped packets are still buffered.

Figure 11 illustrates a method 1100 executed by an active relay node in accordance with an example embodiment. For example, the active relay node is the active relay node 1000 with reference to Figure 10.

At block 1102, the active relay node receives a data packet from an upstream node via an upstream link. As an example, the data packet is received by an uplink receiver of the active relay node. At block 1104, the active relay node buffers the data packet. For example, the data packet is stored or buffered in a relay buffer of the active relay node. At block 1106, the active relay node transmits the data packet to a downstream node via a downstream link. For example, the downstream node is a receiver, such as a smartphone. At block 1108, the active relay node determines reception status of the data packet when receiving a downlink acknowledgement (ACK) packet from the downstream node. For example, the downlink ACK packet includes information that indicates whether the data packet is correctly received, or lost.

In one example embodiment, when the data packet is lost or not correctly received by the downstream node, the active relay node requests retransmission of the data packet by sending an uplink acknowledgement packet to the upstream node. In another example embodiment, upon knowing packet loss of the data packet, the active relay node first checks whether the data packet is still buffered in its own relay buffer, and if so, resends the data packet to the downstream node. In yet a further example embodiment, the active relay node drops the data packet that is buffered to free buffer space upon knowledge of correct reception of the data packet by the downstream node.

Figure 12 illustrates a packet transmission process in accordance with an example embodiment. By way of example, the process includes four sub-processes 1210, 1220, 1230, and 1240, and illustrates how packet retransmission is executed.

In this example embodiment, N₂ and N₄ implement active relay function. In the sub-process 1210, N₀ attempts to send a data packet to N₇, but the data packet is dropped at N₆. In the sub-process 1220, since N₇ does not receive the data packet, it sends out a negative acknowledgement (NACK) packet. When receiving the NACK packet, N₄ responds to the NACK packet because it can perform active relay function. Namely, N₄ does not need to forward the NACK packet to its upstream node N₃ as long as the data packet is still buffered in N₄. In the sub-process 1230, N4 fetches the data packet from its buffer and resends the data packet to N₇. In the sub-process 1240, when receiving the data packet correctly, N₇ sends a positive acknowledgement packet to N₀ to inform N₀ of correct reception.

Figure 13 illustrates a method 1300 that executes packet transmission in accordance with an example embodiment. The method 1300 supports multicasting from a source node to both a destination node and one or more active relay nodes.

At block 1302, the source node multicasts data packets to the destination node and the one or more active relay nodes. For example, the source node sends the data packets simultaneously to the destination node and the one or more active relay nodes. At block 1304, the source node receives multiple acknowledgement packets that indicates reception status for the data packets from each of the destination node and the one or more active relay nodes. In an example, the destination node and the one or more active relay nodes broadcast acknowledgement (ACK) packet to network nodes in the multicast network. At block 1306, the source node multicasts to resend the data packets when the data packets 1) are not received by the destination node and 2) none of active relay node has received it. If all the destination node receives the packet, there is no need to resend either by the source or the active relay nodes. In another case, if at least one of the active relay node receives the data packet, one of them will take the responsibility for the retransmission, as described below. Therefore, the source node only has to resend a packet if BOTH

conditions

1 and 2 are true. At block 1308, when the data packets are not received by the destination node but received by at least one active relay node of the one or more active relay nodes, it is determined which active relay node from the at least one active relay node to resend the data packets. In an example embodiment, the system executes arbitration to determine which active relay node to resend the data packets. When an active relay node is determined to resend the data packets, other active relay nodes do not resend the data packets. In some example embodiments, an active relay node fetches the data packets that are buffered in its own buffer and resend the data packets to the destination node. When the destination node positively acknowledges reception of the data packet, the active relay node frees the data packets from its own buffer.

In an example embodiment, the source node or source is denoted as s, the destination node as r₁ and the adaptive relay node as r₀. The packet error rate (PER) of sending a data packet from s to r₁ is denoted as p_s1. The PER of sending a packet from r₀ to r₁ is denoted as p₀₁. Adaptive relay by multicast is useful if it is faster, more reliable or cheaper to resend packet via the adaptive relay node instead of by the source node. This can be illustrated in the case that p_s1 > p₀₁. In order to send a packet from the source to the destination, s firstly performs multicast to send a packet to both the active relay node and the destination. Then, there are three cases of handling packet retransmission.

1. If r₁ receives a packet, then there is no need for resending the packet.

2. If no destination or active relay node receives the packet, the source node performs multicast to resend the packet again.

3. If the destination node does not receive the packet correctly but at least one active relay node does, then the active relay nodes perform some arbitration to determine which active relay node will send the packet in place of the source node. In one example embodiment, each active relay node contends to access the network to resend the packet. Those active relay nodes which fail to access the network should monitor if any other relay node has already retransmitted the packet. If so, they don’t need to resend the packet.

In this example embodiment, this retransmission is denoted as an adaptive relay operation since the active relay nodes adaptively determine whether packet relay, i.e. retransmission in lieu of the source, is required.

In an example embodiment, in order to determine whether the source node or the active relay node should resend the packet, both the relay node and the destination node broadcast the acknowledgement packets to all networks nodes. Then the source node and the active relay node make distributed decision of packet retransmission. The source node will only resend the packet if the acknowledgment packet from both the active relay node and the destination node do not acknowledge the packet reception. Additionally and optionally, the active relay node buffers all packets sent by the source node and adaptively determines retransmission based on the following cases:

1. If the acknowledgement packet from the destination node acknowledges the reception, the relay node will not resend the packet and free it from the packet buffer； and

2. If the acknowledgment packet from the destination node negatively acknowledge the reception or does not acknowledge the reception after timeout, the active relay node will resend the packet while keeping it in the buffer until acknowledged by the destination node.

In an example embodiment, the active relay node is a receiver in the multicast network. The active relay node simultaneously receives multicast packets or data packets for its own use while buffering and resending the data packets to other receiver nodes.

By way of example, there are various advantages to perform adaptive relay. First, in case that p_s1 > p₀₁, there is a higher chance to correctly send the packet from the active relay node to the destination node when compared with sending packets from a source node to a destination node. Secondly, if the bandwidth resource from source to destination is more expensive or scarce than that from the active relay node to the destination, it would be more economical to make use of the active relay node for retransmission. Figure 14 is an example that demonstrate such benefits.

Figure 14 illustrates an electronic system 1400 that executes packet transmission in accordance with an example embodiment. The system 1400 includes a source node such as a mobile base station or 4G base station 1410, a destination node such as a smartphone 1430, and an adaptive relay node or relay node such as a smartphone 1420.

By way of example, the smartphone 1420 is closer to the 4G base station 1410 than the smartphone 1430 does. The 4G base station 1410 multicasts data packets to both

smartphones

1420 and 1430 via a 4G network. In an example embodiment, the smartphone 1430 sends an acknowledgement (ACK) packet to request retransmission of the data packet and the smartphone 1420 has buffered the data packet, then the smartphone 1420 sends the packet to the smartphone 1430 directly by Wireless Fidelity (WiFi) Direct to reduce the 4G network loading and enhance the transmission quality. Figure 15 illustrates an electronic system 1500 that executes packet transmission in accordance with an example embodiment. The system 1500 includes a source node such as an 802.11 ad transmitter 1520 that communicates with a video source such as a game console 1510, an adaptive relay node or relay node 1530, and a destination node such as a Virtual Reality (VR) headset 1540. The relay node 1530 includes an 802.11 d transmitter 1532 and an 802.11 ad receiver 1534. The VR headset 1540 includes an 802.11 ad receiver 1542.

By way of example, because of the highly directional nature of 60 GHz communications, transmitter and receiver antennas need to be aligned in the right direction to obtain maximum gain while meeting line-of-sight requirement. In an example embodiment, the 802.11 ad receiver 1542 cannot communicate with the 802.11 ad transmitter 1520. The relay node 1530 buffers data packets received from the 802.11 ad transmitter 1520 and resends the data packets on behalf of the 802.11 ad transmitter 1520 at the source.

The methods in accordance with example embodiments are provided as examples, and examples from one method should not be construed to limit examples from another method. Figures and other information show example data and example structures； other data and other database structures can be implemented with example embodiments. Further, methods discussed within different figures can be added to or exchanged with methods in other figures. Further yet, specific numerical data values (such as specific quantities, numbers, categories, etc. ) or other specific information should be interpreted as illustrative for discussing example embodiments. Such specific information is not provided to limit example embodiments.

As used herein, an “adaptive relay node” or “relay node” is an electronic device that can receive and buffer data (such as data packets) from an upstream node such as a source node and resend the data to a downstream node such as a destination node on behalf of the source node.

As used herein, a “cumulative acknowledgment number” is a sequence number of a next data packet or packet expected to be received by a receiver.

As used herein, “multicasting” means sending data across a computer network to several electronic devices at the same time.

As used herein, a “node” is an electronic device in a computer network that functions as a connection point or intersection point that receives and/or transmits data.

As used herein, a “receiver” or “receiver device” is an electronic device that can receive data (e.g., data packets) from another electronic device such as a node. The “receiver” can be considered as an example of a node.

As used herein, a “reception bit vector” is a vector that indicates reception status for data packets by a receiver. Each element of the vector is called reception bit or bit. Each bit of the reception bit vector indicates the reception status of a corresponding data packet with a sequence number p.

As used herein a “sender” or “sender device” is an electronic device that can send, transmit, or emit data (e.g., data packets) to another electronic device such as a node. The “sender” can be considered as an example of a node.

As used herein, a “source node” is an electronic device that can generate or output data. For example, the “source node” can be a video game console. For example, the “source node” can include one or more transmitters to transmit data to a node (such as a network node) . A “destination node” is an electronic device that can receive data.

Claims

A method that executes packet transmission with improved latency, comprising:

improving latency for packet transmission with an acknowledgement packet that includes a cumulative acknowledgment number and a reception bit vector, wherein the cumulative acknowledgment number indicates a sequence number of a next data packet expected to be received by a receiver, and the reception bit vector includes one or more reception bits with each indicating reception status of a data packet with a sequence number larger than or equal to the cumulative acknowledgment number.
The method of claim 1, further comprising:

determining, in accordance with the cumulative acknowledgment number, a data packet with a sequence number larger than or equal to the cumulative acknowledgment number as being received by the receiver；

updating a sequence number of next data packet expected to be acknowledged by the receiver；

determining, in accordance with the reception bit vector, a data packet that fails to be received by the receiver； and

retransmitting the data packet that fails to be received by the receiver.
The method of claim 1, further comprising:

improving reliability by providing the acknowledgement packet that includes redundancy information；

acknowledging repeatedly, by the acknowledgement packet, a data packet that has been previously acknowledged； and

discarding the acknowledgement packet when the acknowledgement packet is not the most updated acknowledgement packet.
The method of claim 1, further comprising:

checking, by a sender that receives a new data packet for packet transmission, whether the sender has a buffer that is available for storing the new data packet； and

storing, when the buffer is available, the new data packet into the buffer.
The method of claim 1, further comprising:

determining, in accordance with an estimated data rate reported by the receiver, whether to transmit a new data packet to the receiver； and

transmitting, when transmission loading does not exceed the estimated data rate, the new packet to the receiver.
The method of claim 1, further comprising:

performing a search for the smallest sequence number p of a next data packet as a selected data packet p to be sent such that

a) nextAckedData <＝ p <nextStore； and

b) the selected data packet p is stored but not sent； or the selected data packet p is sent but an acknowledgement packet indicates the selected data packet is dropped； or the selected data packet p is sent but not acknowledged within a timeout interval,

transmitting the selected data packet with the searched sequence number p.
The method of claim 1, further comprising:

receiving, by the receiver that has N buffers with buffer index b, a data packet with a sequence number p；

updating a sequence number of next data packet expected to be received；

updating the reception bit vector stored in the receiver； and

updating an estimated date rate that is used to evaluate transmission loading for packet transmission.
A method that improves packet transmission, comprising:

multicasting, by a sender, a data packet to a plurality of receivers；

receiving, by the sender and from each of the plurality of receivers independently, an acknowledgement packet that includes a cumulative acknowledgment number and a reception bit vector that indicate reception status for the data packet for the each of the plurality of receivers； and

retransmitting, by the sender, the data packet when the data packet is determined by at least one receiver of the plurality of receivers as not being received.
The method of claim 8, further comprising:

performing a search for the smallest sequence number p of a next data packet as a selected data packet p to be multicasted such that

a) nextAckedData <＝ p <nextStore； and

b) the selected data packet p is stored but not sent to the receivers； the selected data packet p is sent to but not received by at least one of the receiver； or the selected data packet p is sent but not acknowledged by at least one of the receiver within a timeout interval.
The method of claim 8, further comprising:

determining, by the sender, a data packet p as being received by each of the plurality of receiver when either one of the following true:

the sequence number p of the data packet is smaller than the cumulative acknowledge number of acknowledge packets of all of the plurality of receivers； or

the same corresponding bit of reception bit vectors of all acknowledgement packets from all receivers of the plurality of receivers indicates reception status of the data packet as being received.
An apparatus that improves packet transmission, comprising:

an active relay node that acts as a communication intermediary between an upstream node and a downstream node for packet transmission, the active relay node including:

an uplink receiver that receives a data packet from the upstream node and requests the upstream node to execute packet retransmission when packet loss is detected；

a relay buffer that communicates with the uplink receiver and stores the data packet； and

a downlink sender that fetches the data packet from the relay buffer, transmits the data packet to the downstream node, and instructs the relay buffer to free buffer space upon receipt of positive acknowledgement from the downstream node.
The apparatus of claim 11, wherein the upstream node is a mobile base station, the downstream node is a smartphone, and the active relay node is another smartphone that is closer to the mobile base station compared with the smartphone.
The apparatus of claim 11, wherein the upstream node is a 802.11ad transmitter that is connected with a video source, the downstream node is virtual reality (VR) headset with an 802.11ad receiver, and the active relay node includes an 802.11ad receiver and an 802.11d transmitter.
A method executed by an active relay node to facilitate packet transmission, comprising:

receiving, by the active relay node, a data packet from an upstream node via an upstream link；

buffering, by the active relay node, the data packet；

transmitting, by the active relay node, the data packet to a downstream node via a downstream link； and

determining, by the active relay node and when receiving a downlink acknowledgement packet from the downstream node, reception status of the data packet.
The method of claim 14, further comprising:

sending, by the active relay node and when the date packet is lost, an uplink acknowledgement packet to the upstream node to request retransmission of the data packet.
The method of claim 14, further comprising:

checking, by the active relay node and when the downlink acknowledgement packet indicates the data packet is not received by the downstream node, whether the data packet is buffered in the active relay node；

retransmitting, by the active relay node and when the data packet is determined as being buffered in the active relay node, the data packet to the downstream node via the downstream link； and

freeing, by the active relay node and when the downlink acknowledgement packet indicates the data packet is received by the downstream node, the data packet from the active relay node.
The method of claim 14, further comprising:

dropping, by the active relay node, the data packet that is buffered in the active relay node to free buffer space of the active relay node.
The method of claim 14, further comprising:

determining, by the active relay node, a time value for the data packet indicating how long the data packet is stored in the active relay node； and

dropping, by the active relay node, the data packet when storage time for the data packet exceeds the time value.
A method that improves packet transmission in a multicast network, comprising:

sending, by a source node with multicasting, data packets to a destination node and one or more active relay nodes；

receiving, by the source node and from each of the destination node and the one or more active relay nodes, an acknowledgement packet that indicates reception status for the data packets；

executing, by the source node and when the data packets are not received by the destination node and are not received by any of the one or more active relay nodes, multicasting to resend the data packets； and

determining, when the data packets are not received by the destination node but received by at least one active relay node of the one or more active relay nodes, which active relay node from the at least one active relay node to resend the data packets.
The method of claim 19, further comprising:

broadcasting, by each of the destination node and the one or more active relay nodes, the acknowledgement packet to networks nodes in the multicast network；

buffering, in at least one buffer of the one or more active relay nodes, the data packets received from the source node；

freeing, when the destination node positively acknowledges reception of the data packets, data packets from the at least one buffer of the one or more active relay nodes； and

resending, from the at least one buffer in which the data packets are buffered and when the destination node does not positively acknowledge reception of the data packets, the data packets to the destination node.
The method of claim 19, further comprising:

executing arbitration to determine which active relay node to resend the data packets； and

prompting, when an active relay node that is determined with execution of arbitration to resend the data packets, other active relay nodes not to resend the data packet.