CN101860423A - Retransmission method and device for protocol packet transmission - Google Patents

Abstract

Embodiments of the present invention provide a retransmission method and device for protocol packet transmission, so as to alleviate the waste of transmission resources and the reduction of system throughput caused by the retransmission of data frames in the window. The method includes: sending the packets in the transmission window; starting the first timing ; If the acknowledgment frame to the sent group is not received when the first timing is overtime, then send a message for requesting the receiver to send an acknowledgment frame, and start the second timing; When the acknowledgment frame is received, determine whether to retransmit the sent packet according to the acknowledgment information carried in the acknowledgment frame. The technical solution provided by the embodiment of the present invention effectively reduces the retransmission overhead, improves the throughput of the network, and reduces the possibility of network congestion or paralysis. At the same time, it reduces the end-to-end retransmission delay. The larger the transmission window , the more times of retransmission, that is, the more the number of retransmitted packets, the more obvious the above technical effect of the technical solution provided by the embodiment of the present invention.

Description

Retransmission method and device for protocol packet transmission

technical field

The invention relates to the field of wireless communication, in particular to a retransmission method and device for protocol packet transmission.

Background technique

ZigBee technology has many advantages such as low power consumption, low cost, large network capacity, short delay, safety and reliability, and flexible working frequency band. de facto standard. The ZigBee Alliance has standardized network layer protocols and application programming interfaces (Application Programming Interfaces, API). The ZigBee protocol stack architecture is based on the seven-layer model of the open system interconnection model, including the IEEE 802.15.4 standard and the network layer and application layer protocols independently defined by the alliance. Compared with the traditional seven-layer model, the ZigBee protocol stack does not define the transport layer independently, but puts the application layer directly on the network layer, but this does not mean that ZigBee does not need the transport layer, but because ZigBee puts the transport layer The functions are included in the Application Support Sub-layer (Application Support Sub-layer, APS) included in the application layer. ZigBee's transmission mechanism mainly includes the following aspects: 1. No connection; 2. Based on endpoint addressing; 3. Support unreliable transmission and reliable transmission; 4. Deny repetition. Among them, unreliable transmission means that no confirmation is required during the transmission process, and reliable transmission means that confirmation is required during the transmission process. ZigBee 2007 added the function of segmentation and reassembly on the basis of the original transmission mechanism.

ZigBee 2007 APS sublayer stipulates: If the application service data unit (APS service data unit, ASDU) is too large to be transmitted in a medium access control (Medium Access Control, MAC) data frame, then request a unicast with confirmation transmission, and allow fragmentation of the ASDU. The so-called ASDU fragmentation means that the ASDU is divided into several small octet streams, and these small octet streams are called blocks, and each block is transmitted in a different data frame. In order to realize the sequential transmission of services, the sending and receiving parties need to maintain a transmission window (the transmission window maintained when one party is in the sending state can be referred to as the sending window for short, and the transmission window maintained when the other party is in the receiving state can be referred to as the receiving window for short), the maximum transmission The capacity of window apscMaxWindowSize is set to 8.

APS general frame structure, APS extended header field definition and APS extended frame control field definition are shown in Figure 1, Figure 2 and Figure 3 respectively. field shall be included in the frame structure with the Fragmentation subfield in the Extended Frame Control field set to 0b01 for the first block and 0b10 for subsequent blocks. The block number field of the first block is set to the total number of blocks transmitted by the service, the second block is set to 0x01, and the subsequent blocks are incremented in turn. The principle of sending and receiving data between the sending and receiving parties using the ZigBee protocol is as follows:

The sender sends the data blocks in its transmission window in turn, and starts the interframe timer every time a block is sent. After apsInterframeDelay (set time) is delayed, the next block is sent until all data blocks in the window are sent. Blocks of data may also be referred to as packets. When all data blocks in the transmission window are sent, the sender starts the timeout timer, and the timeout period is set to apscAckWaitDuration. If the sender does not receive an acknowledgment frame within the set apscAckWaitDuration time, that is, the timeout timer overflows, then retransmit all unacknowledged data blocks, and increase the count value of the retransmission counter retryCounter by 1. When the count value of retryCounter reaches the maximum number of retransmissions apscMaxFrameRetries, it is considered that the service transmission fails, and the APSDE-DATA.confirm primitive with the status value of NO_ACK is returned.

If the sender receives the acknowledgment frame within the set apscAckWaitDuration time, and the values of its address field, APS counter and block sequence number all match the sent data block, the timeout timer is suspended and the counter retryCounter is reset to 0. The sender checks the transmission status of the sent data block according to the confirmation bit information of the confirmation frame. If all the data blocks in the current transmission window are successfully transmitted, then continue to send the subsequent data blocks, and at the same time, the sending transmission window is increased by apscMaxWindowSize. Otherwise, repeat Data blocks lost during transmission. If all the data blocks of a service have been transmitted and confirmed, then return the APSDE-DATA.confirm primitive whose status is SUCCESS.

If the receiver receives a packet whose fragmentation subfield in the extended frame control field is invalid, the frame is rejected; if the address field or APS counter of the packet received by the receiver does not match the packet service being processed, it is rejected The frame is either handled separately as another transaction; if the receiver receives a packet without transaction processing, reassembly is attempted. In addition, if the currently received traffic has the same APS counter and source address as the previous traffic, the new traffic is rejected as a duplicate of the previous traffic.

If all data blocks in the current transmission window have been received, or the last data block of the current service is received, the receiver sends an acknowledgment frame to the sender. Wherein, the APS counter field of the confirmation frame indicates the field value of the corresponding field of the confirmed frame, the block number field indicates the minimum block number of the current receiving window, and the value of 0 indicates the first block. If the first data block of the current transmission window is successfully received, then the first bit of the acknowledgment bit field is set to 1, otherwise it is set to 0, and the setting of subsequent bits is similar, corresponding to subsequent packets of the current receiving window. If apsMaxWindowSize is less than 8, then the remaining bits are all set to 1.

If the receiver receives a data block whose number of blocks is higher than the current receive window, then the receive window is increased in units of apscMaxWindowSize.

If the receiving window does not slide forward within (apscAckWaitDuration+apscAckWaitDuration×MaxFrameRetries) time, the service is regarded as failure.

Once all data blocks for the current transaction have been received, the APS issues an APSDE-DATA.indication containing reassembly information, and the transaction is considered complete.

The packet transmission mechanism of the above existing ZigBee 2007APS sublayer utilizes the confirmation frame to decide whether to carry out selective retransmission. It stipulates that if the sender does not receive the confirmation frame after the set time (timeout timer overflows), the retransmission sending window All unacknowledged data in it until the acknowledgment frame for these data is received or the maximum number of retransmissions is reached. The defect of this retransmission mechanism is that in the actual network, the confirmation frame delay, the loss of the confirmation frame and the loss of the last frame in the sending window, etc. will cause the sender to fail to receive the confirmation frame before the timeout timer overflows. Regardless of any of the above situations, if all data frames in the sending window are retransmitted according to the original provisions of the protocol, the transmission resources will be wasted, the throughput of the system will be greatly reduced, and the network may be congested or even paralyzed in severe cases. .

Contents of the invention

Embodiments of the present invention provide a retransmission method and device for protocol packet transmission, so as to alleviate the waste of transmission resources and the reduction of system throughput caused by the retransmission of data frames within a window.

An embodiment of the present invention provides a retransmission method for protocol packet transmission, including: sending a packet within a transmission window; starting a first timing; if no confirmation frame for the sent packet is received when the first timing times out, then Sending a message for requesting the recipient to send an acknowledgment frame, and starting a second timing; if the acknowledgment frame is received before the second timing expires, then determine whether to retransmit the Packet sent.

An embodiment of the present invention provides a retransmission device for protocol packet transmission, including: a sending module, used to send a packet within a transmission window; a first timing module, used to start a first timing when the sending of the packet is completed; a request module , used to send a message for requesting the recipient to send a confirmation frame if no acknowledgment frame for the sent packet is received when the first timing expires, and trigger a second timing module; the second timing module is used for According to the trigger, the second timing is started; the retransmission determination module is configured to determine whether to retransmit the received message according to the confirmation information carried by the confirmation frame if the confirmation frame is received before the second timing expires Send packets.

In the embodiment of the present invention, when waiting for the acknowledgment frame of the receiver after sending all the packets in the transmission window, if the acknowledgment frame is still not received before the timeout timer overflows, the message of requesting the receiver to send the acknowledgment frame is not Retransmit all packets within the transmission window. Therefore, compared with the prior art, the technical solution provided by the embodiment of the present invention effectively reduces the retransmission overhead, improves the throughput of the network, reduces the possibility of network congestion or paralysis, and at the same time reduces the end-to-end retransmission For the transmission delay, the larger the transmission window, the more times of retransmission, that is, the more the number of retransmitted packets, the technical solution provided by the embodiment of the present invention is also more obvious in terms of the above technical effects.

Description of drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following will briefly introduce the accompanying drawings that need to be used in the description of the embodiments. Obviously, the accompanying drawings in the following description are only of the present invention. For some embodiments, those of ordinary skill in the art can also obtain other drawings like these drawings without paying creative efforts.

FIG. 1 is a schematic diagram of an APS general frame structure provided by the prior art;

Fig. 2 is a schematic diagram of the definition of the APS extension header field provided by the prior art;

Fig. 3 is a schematic diagram of field definition of an APS extended frame provided by the prior art;

Fig. 4 is a schematic diagram of the transmission services of both the transceiver and the transceiver using the ZigBee protocol provided by the embodiment of the present invention;

Fig. 5 is a schematic diagram of packet retransmission when a certain data block is lost in the transmitting and receiving parties using the ZigBee protocol provided by an embodiment of the present invention;

Fig. 6 is a schematic diagram of packet retransmission when a plurality of confirmation frames are lost during the transmission business process of both the transceiver and the transceiver using the ZigBee protocol provided by the embodiment of the present invention;

FIG. 7 is a schematic flow diagram of a basic flowchart of a retransmission method for protocol packet transmission provided by Embodiment 1 of the present invention;

FIG. 8 is a schematic diagram of a request confirmation frame structure provided by an embodiment of the present invention;

FIG. 9 is a schematic diagram of the definition of the frame type subfield of the frame control field of the request confirmation frame provided by the embodiment of the present invention;

FIG. 10 is a schematic diagram of packet retransmission when the confirmation frame is lost once during the transmission service process of the sending and receiving parties provided by the embodiment of the present invention;

Fig. 11 is a schematic flow diagram of a packet retransmission method when a confirmation frame is lost once during the transmission service process of the sending and receiving parties provided by the embodiment of the present invention;

FIG. 12 is a schematic diagram of packet retransmission when the confirmation frame is lost multiple times during the transmission service process of the sending and receiving parties provided by the embodiment of the present invention;

Fig. 13 is a simulation diagram for comparing the technical solution of the present invention provided by the embodiment of the present invention with the prior art solution in terms of end-to-end delay when the acknowledgment frame is lost once;

Fig. 14 is a simulation diagram for comparing the technical solution of the present invention provided by the embodiment of the present invention with the prior art solution in terms of network throughput when the acknowledgment frame is lost once;

Fig. 15 is a simulation diagram for comparing the technical solution of the present invention provided by the embodiment of the present invention with the prior art solution in terms of end-to-end delay when acknowledging frame loss for multiple times;

FIG. 16 is a schematic diagram of a basic logical structure of a retransmission device for protocol packet transmission provided by Embodiment 1 of the present invention;

FIG. 17 is a schematic diagram of a basic logical structure of a retransmission device for protocol packet transmission provided in Embodiment 2 of the present invention;

FIG. 18 is a schematic diagram of a basic logical structure of a retransmission device for protocol packet transmission provided by Embodiment 3 of the present invention.

Detailed ways

The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only some, not all, embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by persons of ordinary skill in the art without making creative efforts belong to the protection scope of the present invention.

Please refer to FIG. 7 , which is a schematic flow chart of a retransmission method for protocol packet transmission provided by Embodiment 1 of the present invention, which mainly includes steps:

S701. Send the packets within the transmission window.

S702, start the first timer.

S703. If no acknowledgment frame for the sent packet is received when the first timing expires, send a message for requesting the receiver to send the acknowledgment frame, and start the second timing.

In the embodiment of the present invention, one or several timeout timers can be used to set the maximum time for waiting for a feedback confirmation frame, for example, the first timing is set, and the first timing is started after sending the packets in the transmission window. Timing, waiting for the receiver to feed back an acknowledgment frame. The maximum time for waiting for an acknowledgment frame (for example, the first timing) can be flexibly adjusted according to the link transmission status in the network.

S704. If the confirmation frame is received before the second timing expires, determine whether to retransmit the sent packet according to the confirmation information carried in the confirmation frame.

In this embodiment of the present invention, the second timing and the first timing may use the same timer or different timers, which is not limited in this embodiment.

The following grouping is an example of octets divided into ZigBee 2007 protocol application support sublayer service data unit, illustrating the technical solution of the embodiment of the present invention. It should be noted that although the embodiment of the present invention takes the packet transmission of the ZigBee 2007 protocol as an example, it is not limited to the ZigBee network, nor is it limited to the packet transmission. Those skilled in the art can understand that any network or transmission mechanism based on group transmission of multiple data blocks and requiring confirmation of data blocks can adopt the technical solutions provided by the embodiments of the present invention without further creative work.

In order to better compare the difference between the technical solution provided by the present invention and the technical solution using the existing ZigBee protocol, the accompanying drawings 4 to 6 are used as examples for illustration below.

Please refer to accompanying drawing 4, it is the embodiment that uses the existing ZigBee protocol to send and receive both parties to transmit the business. In the example of FIG. 4 , the capacity apscMaxWindowSize of the current transmission window (sending window) is 3, and a certain service is divided into 5 blocks. The range of the sending window is 0~2, which means that the sending end can only send data blocks whose block numbers are 0~2. Since block 0 is the first block of the service, its block sequence number is the total number of packets of the service, 5, so as to notify the receiving end to do a good job of receiving the service. Then the sender waits for the time of apsInterframeDelay (the overflow time of the interframe timer), and then sends the data block with the block number 1, and then waits for the time of apsInterframeDelay, and then sends the data block with the block number 2. Finally wait for confirmation. When the sender receives the confirmation frame whose block number is 0, it knows that it is confirming the data block of the sending window, and then checks the confirmation bit information, and finds that the confirmation bit information is 0xFF, that is, 11111111, indicating that the block number is 0~2 Data blocks The transfer was successful. Since the business has not been completed yet and there are still data blocks to be sent, the sending window is updated, and the range is 3 to 4. Similarly, when block numbers 3 and 4 are successfully transmitted, the receiver's APS proposes to its adjacent high-level The APSDE-DATA.indication primitive containing the reassembly information, and the APS of the sender returns the APSDE-DATA.confirm primitive with a status value of SUCCESS to its adjacent upper layer, and the transmission of the service is completed.

Figure 5 is a schematic diagram of packet retransmission when a certain data block is lost. It can be seen from Figure 5 that the confirmation bit information received by the sender for the first time is not 0xFF, but 0xFD, that is, 11111101. It means that the second data block is lost, so the sender retransmits the data block until a successful confirmation is received.

As can be seen from accompanying drawing 4 and accompanying drawing 5, ZigBee 2007APS sublayer adopts flow control of sliding window, block confirmation and selective retransmission based on confirmation bit information when carrying out packet transmission. However, in practice, it is not always possible to receive an acknowledgment frame from the other party, as shown in FIG. 6 , which is a schematic diagram of packet retransmission when multiple acknowledgment frames (ACK) are lost. In the case of multiple acknowledgment frames being lost, according to ZigBee 2007, the sender needs to retransmit all data frames in the sending window multiple times until the number of retransmissions is reached. Assuming that the number of retransmissions is 3, then, for the situation where the current sending window capacity apscMaxWindowSize is 3 as shown in FIG. 4 , 9 frames need to be retransmitted.

However, in the embodiment of the present invention, when the sender has not received the acknowledgment frame for the sent packet when the timeout timer overflows, instead of retransmitting the sent packet, it generates a message for requesting the receiver to send an acknowledgment frame. go out.

As an embodiment of the present invention, one can generate a communication protocol, such as a request for acknowledgment frame (Request ForACK, RFA) similar to the acknowledgment frame structure in the ZigBee 2007 protocol as a message for requesting the receiver to send an acknowledgment frame, the particularity of the request for acknowledgment frame The advantage is that it can have the same frame structure as the acknowledgment frame, for example, the same fields, but it is sent from the sender to the receiver, so the request acknowledgment frame is not an acknowledgment frame. The acknowledgment request frame carries the sequence number of the packet requiring acknowledgment by the receiver and a frame type field used to identify the type of the acknowledgment request frame.

Accompanying drawing 8 has provided the request confirmation frame structure that generates in the embodiment of the present invention, as can be seen from accompanying drawing, request confirmation frame only comprises frame header, does not comprise frame load, not only does not take extra resource like this, and because with ZigBee 2007 agreement The acknowledgment frame structure is similar, so it can be well compatible with the ZigBee 2007 protocol.

As an embodiment of the present invention, the request confirmation frame can be generated in this way, that is, the reserved 2-bit "11" of the frame type subfield of the frame control field of the APS confirmation frame is defined as the "request confirmation" type, and other fields The value of remains unchanged, as shown in Figure 9.

Since the acknowledgment request frame is used for packet transmission to request acknowledgment, the values of the acknowledgment request subfield and the extended header existence subfield of its frame control field (also the frame control field of the acknowledgment frame) should be set to be valid. The value setting of the address field and the APS counter field is the same as that of other types of frames, the extension header is consistent with the frame to be confirmed, and the confirmation bit information is empty.

Taking the transmission window size shown in Figure 10 as 3, the total number of packets in the transmission service as 5, and the ACK loss once during the transmission process as an example, the technical solution of the present invention is described below. The flow chart is shown in Figure 11, including steps:

S111, the sender initializes the transmission window, determines the number of packets that can be transmitted in the current transmission window, and then starts sending packets and starts an interframe timer (overtime timer);

S112, sending a packet after waiting for the overflow time apsInterframeDelay set by the interframe timer each time, until sending the last packet in the transmission window and starting the timeout timer;

S113, if the confirmation frame to the sent packet is still not received when the timeout timer overflows, then generate a request confirmation frame and send it to the receiver, at the same time, reset the timeout timer after overflow and start it again;

S114, if the confirmation frame is received before the restarted timeout timer overflows, in order to avoid receiving wrong confirmation frames or repeated confirmation frames, it may be determined whether the confirmation frame is a valid confirmation frame.

In the embodiment of the present invention, it can be judged whether the received confirmation frame is an effective confirmation frame in the following manner: first check whether the address field of the confirmation frame is correct, if correct, then further check whether the APS counter field matches, if it matches, then judging that the acknowledgment frame is an effective acknowledgment frame;

After determining that the received acknowledgment frame is a valid acknowledgment frame, according to the indication of the acknowledgment information carried by the acknowledgment frame, retransmit the packets that have not been correctly received by the receiver in the sent packets, including:

Judging whether the acknowledgment information carried by the acknowledgment frame matches the information of "all the packets have reached the receiver" (S115);

For example, if the sending and receiving parties agree that the acknowledgment information is all bit "1" indicating that "the packets all reach the receiver", the sender only needs to check whether the acknowledgment information carried by the confirmation frame is all bit "1";

If it is checked that the confirmation information carried by the confirmation frame does not match the information that "all packets have reached the receiver", for example, part of the confirmation information carried by the confirmation frame is bit "1" and part is bit "0", then the retransmission does not reach the receiver. packet, that is, retransmit the packet corresponding to the bit "0" and start the timeout timer (S116).

S117. If the acknowledgment frame is still not received before the restarted timeout timer overflows, retransmit the request acknowledgment frame.

Considering that in the actual network environment, there are occasional delays in sending confirmation frames for some reason, in order to avoid the additional load caused by frequent retransmission of request confirmation frames in a short period of time, you can request confirmation every time you retransmit After the frame, the timing time aspACKWaitDuration of the timeout timer is extended appropriately.

Figure 12 shows a schematic diagram of packet retransmission when the transmission window size is 3, the total number of packets of the transmission service is 5, and ACK is lost multiple times during the transmission process. In accompanying drawing 11, when the timeout timer overflows once and does not receive the acknowledgment frame to the sent packet, then generate a request acknowledgment frame (RFA) and send it out until the number of retransmissions of the request acknowledgment frame reaches the maximum Or an acknowledgment frame is received before the restarted timeout timer expires.

Comparing the embodiment shown in accompanying drawing 6 with the technical solution of the embodiment shown in accompanying drawing 12, assuming that a total of 3 times the confirmation frame is not received before the timeout timer overflows, then the embodiment shown in accompanying drawing 6 is in the whole retransmission During the retransmission process, 9 data frames (9 packets) were retransmitted, and the time used was (2×apsInterframeDelay+3×apscAckWaitDuration), while the technical solution of the embodiment shown in Figure 11 only transmitted 3 requests during the entire retransmission process Acknowledgment frame, the time used is 3×apscAckWaitDuration. It can be seen that the technical solution of the present invention effectively reduces the retransmission overhead and at the same time reduces the end-to-end retransmission delay.

Apparently, if the transmission window is larger and the number of retransmissions is greater, that is, the number of retransmitted packets is greater, then the technical solution of the present invention has more obvious advantages over the solutions of the prior art.

For the receiver, if it receives a normal packet, the processing flow is similar to that of the prior art, and will not be described here. If it receives a request confirmation frame, it is judged that the sender has sent all the packets in the sending window. But no acknowledgment frame was received. At this point, the receiver should immediately send an acknowledgment frame to the sender. If the receiver has not sent an acknowledgment frame before, indicating that the last frame or the last few frames in the sending window are lost, an indication that the corresponding data frame (packet) has not been received should be given in the acknowledgment frame (for example, the acknowledgment bit information in The corresponding bit is set to 0), and then send a confirmation frame; if the receiver has sent a confirmation frame before, it means that the confirmation frame is delayed or lost, and the previous confirmation frame should be retransmitted.

Considering that when the sender sends a packet, it is possible that the last packet in the transmission window is lost, so that the sender cannot receive the confirmation frame before the timeout timer overflows. In this case, the method of sending a request confirmation frame (RAF frame) may not be used, that is, as an embodiment of the present invention, the last packet in the transmission window may be used to replace the special data frame, and when the timeout timer overflows, the special data frame may be replaced. Retransmits the last packet in the transmission window to the receiver when no acknowledgment frame is received for the sent packet. Because in the usual communication protocol, the last packet in the transmission window carries a "request feedback confirmation frame" information, when the last packet in the transmission window reaches the receiver, the receiver will immediately feedback the confirmation frame, which can also avoid retransmission All packets within the window are transmitted, thereby reducing retransmission overhead and improving network throughput.

In order to verify that the technical solution of the embodiment of the present invention is effective, OPNET14.0 is used for simulation to observe that the technical solution provided by the embodiment of the present invention can reduce the end-to-end delay of the transmission service and improve the throughput of the network. Assuming that the simulation area is a 100m×100m campus network, the simulation object is single-hop transmission between two nodes, the Media Access Control (MAC) protocol adopts IEEE802.11, and the routing protocol is Dynamic Source Routing (Dynamic Source Route, DSR) protocol, the transmission protocol is the simulated ZigBee 2007APS transmission mechanism and the reliable transmission method based on request confirmation (Request ForACK Reliable Transmission Protocol, RARTP), the application configuration is video conference, and some other important simulation parameters and values are shown in the table 1 shows.

Simulation parameters value Frame interval (apsInterframeDelay) 0.001s Timeout (apscAckWaitDuration) 1.5s Maximum number of retransmissions (apscMaxFrameRetries) 3 Maximum transfer window (apscMaxWindowSize) 8 Application packet payload (ASDU) 32000, 64000, 96000, 128000 Maximum transmission payload (APSDU) 16000

Table 1 (simulation parameters and values)

The simulation analyzes the end-to-end delay and network throughput of the two embodiments of the present invention through horizontal comparison and vertical comparison. During the simulation process, first set the transmission window size to 4, and compare the end-to-end delay and throughput of the two methods. The simulation curves are shown in Figure 13 and Figure 14. Setting different transmission window sizes, the simulation situation is similar (horizontal comparison). Then, according to the extreme situations shown in Figure 6 and Figure 12 (that is, multiple retransmissions due to multiple ACK losses), select different transmission window sizes, and compare the average end-to-end delay of the two methods (Longitudinal comparison), as shown in Figure 15.

Figure 13 is a comparison of the end-to-end delay of the method provided by the embodiment of the present invention when the transmission window is 4. Here, the end-to-end delay is defined as the time required to successfully send all packets in the transmission window, that is, from sending the first packet in the transmission window to receiving the full confirmation information is the confirmation of all received (confirmation bits are all 1) The time of the frame, which includes the retransmission time. It can be seen from FIG. 13 that compared with the ZigBee packet transmission mechanism, the use of the RARTP algorithm can reduce the end-to-end delay of the network. Moreover, as time goes by, the number of retransmissions increases, and the end-to-end delay tends to decrease more obviously until the maximum number of retransmissions is reached. This is because RARTP effectively reduces the retransmission overhead and the retransmission time, thereby reducing the end-to-end delay of the network.

Figure 14 is a comparison of the throughput of the method provided by the embodiment of the present invention when the transmission window is 4. Here we take the size of the transmission window as the unit of business volume, and define the throughput as the successfully transmitted business volume per second, excluding the retransmitted business volume. It can be known from Figure 14 that, compared with the ZigBee packet transmission mechanism, the use of the RARTP algorithm can improve the throughput of the network to a certain extent.

Fig. 15 compares the average end-to-end delay of the method provided by the embodiment of the present invention according to the extreme situation described in Fig. 6 and Fig. 12 . It can be seen from FIG. 15 that, compared with the retransmission method of ZigBee packet transmission, using the RARTP algorithm can effectively reduce the average end-to-end delay of the network. And, as the transmission window increases, this advantage becomes more obvious.

Please refer to FIG. 16 , which is a schematic diagram of a basic logical structure of a retransmission device for protocol packet transmission provided by Embodiment 1 of the present invention. For ease of description, only parts related to the embodiments of the present invention are shown. The functional modules included in the device may be software modules, hardware modules or a combination of software and hardware, including a sending module 161, a first timing module 162, a request module 163, a second timing module 164, and a retransmission determination module 165, wherein:

A sending module 161, configured to send packets within the transmission window;

In this embodiment, the packets may be octets divided into ZigBee 2007 protocol application support sublayer service data units.

The first timing module 162 is configured to start the first timing when the packet transmission in the transmission window is completed;

The request module 163 is used to send a message for requesting the receiver to send a confirmation frame if the confirmation frame to the sent packet is not received when the first timing expires, and trigger the second timing module 164;

The second timing module 164 is configured to start the second timing according to the trigger of the request module 163;

The retransmission determination module 165 is configured to determine whether to retransmit the sent packet according to the confirmation information carried in the confirmation frame if the confirmation frame is received before the second timing expires.

As an embodiment of the present invention, one can generate a communication protocol, such as a request confirmation frame similar to the confirmation frame structure in the ZigBee 2007 protocol as a message requesting the recipient to send the confirmation frame. The special feature of the request confirmation frame is that it can be used with An acknowledgment frame has the same frame structure, ie, the same fields, but it is sent from the sender to the receiver, so a request acknowledgment frame is not an acknowledgment frame. The acknowledgment request frame carries the sequence number of the packet requiring acknowledgment by the receiver and a frame type field used to identify the type of the acknowledgment request frame.

The request acknowledgment frame only contains the frame header and does not contain the frame load, which not only does not occupy additional resources, but also is well compatible with the ZigBee 2007 protocol due to its similar structure to the acknowledgment frame of the ZigBee 2007 protocol.

As an embodiment of the present invention, the request confirmation frame can be generated in this way, that is, the reserved 2-bit "11" of the frame type subfield of the frame control field of the APS confirmation frame is defined as the "request confirmation" type, and other fields The value of remains unchanged, as shown in Figure 9.

Since the acknowledgment request frame is used for packet transmission to request acknowledgment, the values of the acknowledgment request subfield and the extended header existence subfield of its frame control field (also the frame control field of the acknowledgment frame) should be set to be valid. The value setting of the address field and the APS counter field is the same as that of other types of frames, the extension header is consistent with the frame to be confirmed, and the confirmation bit information is empty.

As another embodiment of the present invention, the request confirmation frame can be replaced by the last packet in the transmission window. When the acknowledgment frame for the sent packet has not been received when the timeout timer expires, retransmit the last packet in the transmission window to the receiver. When the packet arrives at the receiver, the receiver will immediately feed back the acknowledgment frame, which can also avoid retransmission All packets within the transmission window are transmitted, thereby reducing retransmission overhead and improving network throughput.

The retransmission determination module 165 illustrated in FIG. 16 may further include a judging submodule 171 and a retransmission submodule 172. FIG. 17 shows a schematic diagram of the basic logical structure of a retransmission device for protocol packet transmission provided by Embodiment 2 of the present invention, wherein:

Judgment sub-module 171, used to judge whether the confirmation frame is an effective confirmation frame;

The retransmission submodule 172 is configured to retransmit the unreceived packets in the sent packets according to the indication of the confirmation information carried by the confirmation frame when the judging submodule 171 judges that the confirmation frame is a valid confirmation frame. packets correctly received by the party.

In this embodiment, after the judging sub-module 171 determines that the received acknowledgment frame is valid, the retransmission sub-module 172 judges whether the acknowledgment information carried in the acknowledgment frame is consistent with the information that "all packets have reached the receiver". For example, if the sending and receiving parties agree that the acknowledgment information is all bits "1" to indicate that "all the packets have reached the receiver", the retransmission submodule 172 only needs to check whether the acknowledgment information carried by the confirmation frame is all bits "1"; The acknowledgment information carried does not match the information that "all the packets have reached the receiver". For example, if the acknowledgment information carried by the acknowledgment frame is partly bit "1" and partly bit "0", then the retransmission sub-module 172 does not reach the receiver. , that is, retransmit the packet corresponding to bit "0" and start the timeout timer.

The request module 163 illustrated in FIG. 16 or 17 may further include a request retransmission unit 181, as shown in FIG. 18, a schematic diagram of a basic logical structure of a retransmission device for protocol packet transmission provided by Embodiment 3 of the present invention. The request retransmission unit 181 is configured to retransmit the message for requesting the receiver to send the confirmation frame if no confirmation frame is received when the second timing times out, and start the second timing.

It should be noted that the information interaction and execution process among the various modules/units of the above-mentioned equipment are based on the same concept as the method embodiment of the present invention, and the technical effect brought by it is the same as that of the method embodiment of the present invention, and the specific content can be Refer to the descriptions in the method embodiments of the present invention, and details are not repeated here.

Those of ordinary skill in the art can understand that all or part of the steps in the various methods of the above-mentioned embodiments can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium, and the storage medium can include: Read Only Memory (ROM, Read Only Memory), Random Access Memory (RAM, Random Access Memory), disk or CD, etc.

The method and device for retransmitting a protocol packet transmission provided by the embodiment of the present invention have been described in detail above. In this paper, specific examples are used to illustrate the principle and implementation of the present invention. The description of the above embodiment is only used to help Understand the method of the present invention and its core idea; at the same time, for those of ordinary skill in the art, according to the idea of the present invention, there will be changes in the specific implementation and scope of application. In summary, the content of this specification is not It should be understood as a limitation of the present invention. Those skilled in the art can understand that the various embodiments described above can be combined with each other to form new embodiments without conflicts.

Claims (10)

1. the repeating method of a transmitted in packets is characterized in that, comprising:

Send the grouping in the transmission window;

Start first regularly;

If when described first timing is overtime, do not receive that to sending the acknowledgement frame of grouping then transmission is used to ask the recipient to send the message of acknowledgement frame, and start second regularly;

If receive described acknowledgement frame before described second timing is overtime, then the affirmation information of carrying according to described acknowledgement frame determines whether to retransmit the described grouping that sent.

2. the method for claim 1 is characterized in that, also comprises:

If do not receive described acknowledgement frame when regularly overtime, then retransmit and describedly be used to ask the recipient to send the message of acknowledgement frame, and start described second regularly described second.

3. method as claimed in claim 2 is characterized in that, if repeatedly retransmit described message and the number of retransmissions that is used to ask the recipient to send acknowledgement frame and reach a threshold value, then stops to continue to retransmit and describedly is used to ask the recipient to send the message of acknowledgement frame.

4. as each described method in the claim 1 to 3, it is characterized in that the described message that is used for asking the recipient to send acknowledgement frame is a request acknowledgement frame or has describedly sent last grouping that sends of grouping.

5. method as claimed in claim 4 is characterized in that, the described request acknowledgement frame carries the sequence number of the grouping that needs described recipient's affirmation and is used to identify the frame type field of this request acknowledgement frame type.

6. as each described method in the claim 1 to 3, it is characterized in that described affirmation information of carrying according to described acknowledgement frame determines whether to retransmit described the transmission and divides into groups to comprise:

The indication of the affirmation information of carrying according to acknowledgement frame retransmits described the transmission and is not received the upright grouping that really receives in the grouping.

7. method as claimed in claim 6 is characterized in that, describedly judges whether described acknowledgement frame is that effective acknowledgement frame comprises:

Whether the address field of checking described acknowledgement frame is correct;

If correct, check further then whether the application support sublayer counter field of described acknowledgement frame mates, if coupling judges that then described acknowledgement frame is effective acknowledgement frame.

8. the retransmission arrangement of a protocol packet transmission is characterized in that, comprising:

Sending module is used to send grouping in the transmission window;

First time block is used for when described grouping is sent completely, and starts first regularly;

Request module is used for if do not receive sending the acknowledgement frame of grouping when described first timing is overtime, then sends to be used to ask the recipient to send the message of acknowledgement frame, and triggers second time block;

Second time block is used for according to described triggering, starts second regularly;

Retransmit determination module, be used for if receive described acknowledgement frame before described second timing is overtime, then the affirmation information of carrying according to described acknowledgement frame determines whether to retransmit the described grouping that sent.

9. device as claimed in claim 8 is characterized in that, described re-transmission determination module comprises:

Judge submodule, be used to judge whether described acknowledgement frame is effective acknowledgement frame;

Retransmit submodule, be used for if described acknowledgement frame is effectively, the indication of the affirmation information of carrying according to acknowledgement frame retransmits described the transmission and is not received the upright really grouping of reception in the grouping.

10. install as claimed in claim 8 or 9, it is characterized in that the described request module also comprises: the request retransmission unit is used for if do not receive described acknowledgement frame when described second timing is overtime, retransmit and describedly be used to ask the recipient to send the message of acknowledgement frame, and start described second regularly.

Images