Let's say we have S1 sending to R1 and S2 sending to R2. S1 and S2 are outside of each other's carrier sense (CS) range. R1 and R2 are obviously both within the receive (RX) range of S1 and S2, respectively. R1 is within the CS range for S2 (but outside S2's RX range). R2 is outside S1's CS range. Note the asymmetry of the topology means that R1 will carrier sense S2's transmissions, but R2 will not carrier sense S1's transmissions.
1. S1 starts sending an RTS to R1. 2. Before S1's RTS finishes, S2 starts sending an RTS to R2. In ns-2, this causes the capture function in mac-802_11.cc to be called at node R1. The effect is that R1 will set its NAV for EIFS plus the txtime of S2's RTS. 3. When S1's RTS finishes, R1 cannot send a CTS since its NAV was just set in the capture function. 4. Every time that S1 trys to retransmit an RTS during S2's data transmission, R1 is unable to reply with a CTS. This can cause S1's backoff window to get relativley large. 5. When S2 finishes sending and tries to transmit another packet, there's a relatively decent chance that it will send its RTS and start sending the data packet before S1 can send an RTS (S2's backoff is relatively small and S1's is relatively large). This causes Step 4 to repeat and S1 may reach its RTS retry threshold and consider the link dead. In a correct implementation, I think that R1 should be able to send a CTS in response to S1's first RTS and S1's transmission can proceed in parallel with S2's transmission. It seems this was mentioned over two years ago on the list, but the bug still exists in the most recent CVS code: http://mailman.isi.edu/pipermail/ns-users/2003-December/038043.html -Matt
