yes I think thats right. rts/cts does not change packet size and as Scott says, if multipath is a problem,. it will still be a problem if other users are not transmitting at the same time - ie rts is sent.
Potentially frag level can be used to avoid multipathing, but sometimes it might be easier (and would use less bandwidth) to move a directional aerial slightly, or try to use multipathing constructively (eg use the fact that a signal wants to bounce off a building - not always easy in ptmp setups). Its not really about delays at baseband (the bit level) being great enough, rather about the two or more signals being of similar signal strength cancelling each other out at RF so that momentarily there is nothing for the receiver to demodulate. I don't see that we reduce the probability of this happening with cts/rts, but we might with shorter fragments rather than large frames, which reduces the amount of data corrupted by a single multipath event. It is interesting that frag and rts/cts are often set to the same value. I suppose this is in recognition of the fact that if you are going to frag a frame, you might as well give as good a chance of getting thro as you can (so tell other users to wait - lifes difficult enough as it is!). The effect would be for all to hold off until all fragments in a frame have been completed (hopefully successfully). Again this reduces "self inflicted injuries" but does little/nothing to stop real interference. bw ----- Original Message ----- From: "shoffman" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, November 26, 2003 1:41 PM Subject: RE: [smartBridges] RTS / CTS > Seeni, > > Are you not talking about Frag level when you are talking fixing the > Multi-path problem? I mean, all that RTS is going to do is to ask the AP > to shut everyone else up while I transmit.. but my transmission will > still be multi-pathed, so guess what.. I still get failure and have to re- > transmit. With your description, reducing the packet size, thus giving a > better chance for a packet to get there without the multi-path > interference, would be increased... > > I guess I am missing something here too.. > > Scott > > > -----Original Message----- > From: "Seeni Mohamed" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Date: Wed, 26 Nov 2003 21:17:48 +0800 > Subject: RE: [smartBridges] RTS / CTS > > > Hi Brian, > > > > Multipath is a form of RF interference that occurs when a radio signal > > has more than one path between the receiver and the transmitter. > > Multipath propagation occurs when RF signals take different paths when > > traveling from a source to a destination. A portion of the signal might > > go directly to the destination, while another part might bounce off an > > obstruction or ceiling, then on to the destination. As a result, some > > of > > the signal encounters delay and travels longer paths to the > > destination. > > > > If the delays are great enough, bit errors in the packet occur. The > > receiver can't distinguish the packets and interpret the corresponding > > bits correctly. The receiving station detects the error in the packets. > > It means, the cyclic redundancy check (CRC) checksum does not compute > > correctly, indicating that there is error in the packet. In response to > > the bit errors, the receiving station does not send an acknowledgment > > to > > the sending station. The sender eventually retransmits the signal after > > regaining access to the medium. Because of the re-transmissions, users > > encounter lower throughput when Multipath interference is significant. > > > > Due to multiple re-transmissions, the default value (RTS/CTS) may not > > able to deliver the packet with original size. In such condition, > > adjusting or reducing the RTS/CTS value will improve the efficiency in > > the data transmission. > > > > You can use the RTS/CTS adjustment to overcome the effects of HIDDEN > > NODE. The default value works great in the environment where all the > > clients can hear each other such as indoor wireless LAN. However, in an > > outdoor environment, not all the clients can hear from one each other. > > If the clients located far away, neither one can hear the other. For > > example, if the clients are uploading/downloading large file size at a > > same time. That means data being transmitted simultaneously, which > > results in a COLLISION. Whenever there is a collision, both clients > > have > > to re-transmit at a same time. > > > > That is the reason the hidden node is a problem when there is many > > clients talking to the same AP at same time. None of them knows when > > the > > others are talking, so it will end of with collisions all over the > > place. A lot of collisions results in a lot of re-transmissions which > > will reduce the overall throughput at the CPE end. > > > > Due to multiple re-transmissions, the RTS/CTS adjustment is necessary > > to > > overcome the packet loss and throughput problem. > > > > I hope above info helps to understand the RTS/CTS adjustment for the > > Multipath interference and Hidden node issues. > > > > > > > > > > > > Kind regards, > > > > Seeni > > > > sB Tech Support > > > > > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Brian Winter > > Sent: Wednesday, November 26, 2003 7:30 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [smartBridges] RTS / CTS > > > > > > > > Hi Seeni, > > > > > > > > Could you please explain how rts/cts combats multipath or any other > > interference (ie not my or other users real traffic). I thought it was > > used to tell the far end (AP), and subsequently other in range clients > > (by cts) to shut up while I get on with my transmission and hear the > > ack. I understood that it temporarily stops real traffic, useful on a > > busy contentious system, - not interference. Efficiency is only > > improved as collisions are reduced. Am I missing something ? > > > > ----- Original Message ----- > > > > From: Seeni <mailto:[EMAIL PROTECTED]> Mohamed > > > > To: [EMAIL PROTECTED] > > > > Sent: Wednesday, November 26, 2003 10:35 AM > > > > Subject: RE: [smartBridges] RTS / CTS > > > > > > > > The RTS/CTS adjustment is required ONLY in the CPE devices when there > > is > > poor performance due to MULTIPATH INTERFERENCE and many HIDDEN NODES > > which will result in packet loss. Sometimes when we deal with higher > > interference then we need to lower down the RTS/CTS values to improve > > the efficiency in the packet transmission which avoids the packet loss. > > > > Normally, RTS/CTS adjustment is NOT required in the AP side. RTS/CTS > > only comes into play when a client is transmitting and it does nothing > > for the receive traffic. > > > > > > > > Kind regards, > > > > Seeni > > > > sB Tech Support > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of TJ Burbank > > Sent: Wednesday, November 26, 2003 9:18 AM > > To: [EMAIL PROTECTED] > > Subject: [smartBridges] RTS / CTS > > > > > > > > I am curious what the best values for a network with 30 bridges per AP, > > and a 1.5MB backbone would be. > > > > > > > > I guess I am not certain if changing the RTS / CTS values on customer > > bridges will help in increasing netork load and capacity. > > > > > > > > If you change the RTS / CTS values on the CPE is is neccesary to change > > them on the AP? > > > > > > > > Thanks, > > > > > > > > -TJ > > > > Last Mile Wireless > > > > > > The PART-15.ORG smartBridges Discussion List > To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> > To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) > Archives: http://archives.part-15.org > The PART-15.ORG smartBridges Discussion List To Join: mailto:[EMAIL PROTECTED] (in the body type subscribe smartBridges <yournickname> To Remove: mailto:[EMAIL PROTECTED] (in the body type unsubscribe smartBridges) Archives: http://archives.part-15.org
