First, host1 sends a UDP package, then an addba image. host2 responds with an ADDBA response image (both frames are woven). This frame exchange creates the blockack session and host2 does not return the frames of this point normally, but waits for a blockack request. The first input of the bitmap is anything that indicates that data-1 has been fully received (all fragments) although only two fragments have been sent into this block. The second entry has three zeroes. The first zero indicates a lost fragment of Data-2. The last two are fragments that have not yet been sent. It appears in the ack block when some of the images in a block have not been correctly received. The MAC redeploys them to the next block.
Here`s a new transmission in the packet traffic view: Below the BlockAck sequence is displayed using the delayed blockack policy Several Hcf sub-modules are involved in the Blockack mechanism. These modules have parameters that control blockack behavior. The following paragraphs list some of the most important parameters. MixedTraffic: Two traffic sources in host1 generate packages below and above the maxBlockAckPolicyFrameLength threshold. Packages smaller than the threshold are blocked. the above are not. We use three configurations to demonstrate different aspects of the blockack mechanism. The configurations in omnetpp.ini are as follows: For blockAckReq frames sent with delayed and delayed HT chords, the BAR Ack Policy subfield of the BAR Control field has the meaning indicated in Table 8-15. For blockAckReq executives sent under other types of contracts, the BAR Ack Policy subfield is reserved. This is the frame block sent by the STA receiver.
Instead of retransmiting the data frames, the sender can return the blockack request if they have not received a blockack. This is currently a limitation of implementation. Once the initiator has sent a block of images, he asks the recipient to confirm it. This requirement is done by sending a BlockAck query framework that is a control framework. Here is the image format of this BlockAck requirement framework. After sending five UDP packages, host1 sends a blockack requirement, host2 responds with a blockack.