Mac Rx/Tx Sequence Control collisions
From my understanding of the transmission/reception flow, one of the last steps is placing the Mac Header Sequence number and in the reception using it to detect duplicates.
For generating and bookkeeping of sequence numbers (at least in the case of QoSTxop) it happens in MacTxMiddle::GetNextSequenceNumberFor (const WifiMacHeader *hdr)
.
Under this method if a frame is QoS Data and not addressed for a group it keeps a sequence number counter per tid for each destination. Otherwise uses a common to all frames counter for generating the sequence number.
On the reception side it looks at the sequence control to check for duplicates and stores the latest sequence control, this code happens in MacRxMiddle::Receive (Ptr<WifiMacQueueItem> mpdu)
.
The Lookup
(line 193) method checks if the destination is not group addressed, if so looks at the source of the frame and the tid and returns the class that keeps the seqnum.
Some bugs/questions:
-
Shouldn't the lookup method look at Address 1 of Mac to check if destination is not group addressed, instead of Address 2 (source address)? Line in question
-
Shouldn't at the receiver side make distinction of the seqnum for the QoS Data frames between different triples of (source, destination, tid) instead of the current (source, tid)?
I will illustrate the second issue with a scenario:
- In a mesh network there are 4 nodes in line of sight between each other A <-> B <-> C <-> D
- Node B sends QoS Data frame to node A, first seqnum is 0; Both Node A and C will receive the frame;
- Node B sends QoS Data frame to node C, first seqnum is 0; Node A receives it, Node C fails to receive due to interference of node D;
- Node B retries TX, frame is sent with seqnum 0 and retry flag; Node A detect dup, Node C will detect as dup because already saw a frame from Node B with seqnum 0 and has retry flag.