Dear ns users;

 

When the RTS/CTS is enabled, the following trace is obtained;

 

s 10.110075000 _1_ MAC  --- 0 RTS 44 [239e 0 1 0]
r 10.110427170 _0_ MAC  --- 0 RTS 44 [239e 0 1 0]
s 10.110437170 _0_ MAC  --- 0 CTS 38 [2264 1 0 0]
D 10.110741339 _1_ MAC  STA 0 CTS 38 [2264 1 0 0]
s 10.110995000 _1_ MAC  --- 0 RTS 44 [239e 0 1 0]
D 10.111347170 _0_ MAC  BSY 0 RTS 44 [239e 0 1 0]
s 10.112115000 _1_ MAC  --- 0 RTS 44 [239e 0 1 0]
D 10.112467170 _0_ MAC  BSY 0 RTS 44 [239e 0 1 0]
s 10.114015000 _1_ MAC  --- 0 RTS 44 [239e 0 1 0]
D 10.114367170 _0_ MAC  BSY 0 RTS 44 [239e 0 1 0]
s 10.115915000 _1_ MAC  --- 0 RTS 44 [239e 0 1 0]
D 10.116267170 _0_ MAC  BSY 0 RTS 44 [239e 0 1 0]
D 10.116585000 _1_ MAC  RET 0 RTS 44 [239e 0 1 0]
D 10.116585000 _1_ MAC  --- 6 cbr 1060 [13a 0 1 0] ------- [1:1 0:1 32 0]
[0] 0 0

 

After I read the code in the file Mac802_11e.cc, I found that other
priorities than priority 0 are not supported. RTS does not convey the
priority information, and the responding node always reply with a priority-0
CTS. Therefore, I guess that the initiating node having a packet with
priority 1, 2, or 3 will have the wrong state (STA in the above trace). The
successive RTS's retransmitted by the initiator are all discarded by the
responder which is waiting DATA packet.

 

I know that TKN group said that they did not test the RTS/CTS mechanism. Is
there anybody who had this experience? Any comments, patch or help will be
appreciated very much. Thank you for reading.

 

K. Lee

[EMAIL PROTECTED]

 

Reply via email to