Hello, Oh, sorry about that, I'm new and not familiar with the health status of the lists.
I would say that it would be difficult to give you an RTS threshold which is optimal for every scenario in every deployment. The guidelines outlined at the following link seem to be sane: http://resources.infosecinstitute.com/rts-threshold-configuration-improved-wireless-network-performance/ RTS/CTS usage is not synchronized and needs to be set at every site of transmission individually as needed. The settings need not be the same, as there doesn't exist a single optimum for all node pairs and directions anyway. Sadly, enabling RTS/CTS on the AP side only would probably be much less useful than if done at stations in this case. It introduces much more overhead to the network, because traditional Internet traffic involves much more downstream than upstream., and thus much more handshakes. Also consider that every station must be already able to hear the AP and vice versa to stay associated*. So theoretically their transmission should not collide with ones from the AP without noticing. In practice, transmissions from the AP might collide with neighboring networks as seen at various edge nodes. In this case, AP-side RTS/CTS could force these edge nodes to silence the neighbors at the time of transmission. However, I'd say that hidden local nodes should be more of a barrier to scaling at such hotspots. Of course, enabling both directions should be the most robust. If you are desperate in improving reliability without deploying more hotspots or adjusting settings at the clients, you might want to do benchmarks of MTU adjustments. I guess you need to disable aggregation and perhaps some more capabilities in order for this hack to work. Although, because major reductions in frame size by itself increases contention at the medium in case of lots of active nodes, I'm not at all sure if this would help in the end. Don't forget the option of fine tuning of traffic shaping with bandwidth reservation at the router side. Web searches revealed that there had been multiple attempts at TDMA and some researchers had implemented proof of concept codes, but none were finished. i guess those who did finish decided to sell their solution instead. Do note that the standards had provided options for a kind of TDMA by the point coordination function and the newer HCCA which would only need AP-side setup, but sadly vendors like to ignore such optional features in practice. I'm not quite sure what kind of configuration is needed for the mandatory TXOP+RDP/frame bursting. Perhaps wireless developers could give a hint or someone could look at the sources. https://en.wikipedia.org/wiki/IEEE_802.11e-2005#Enhanced_distributed_channel_access_.28EDCA.29 *: You could argue that obtainable link speed will be different between stations depending on local attenuation. however because the AP does not modulate TX power, energy-based clear-channel assessment should work the same way and (the most important parts of) the PLCP header and preamble runs at basic rate anyway. On Tue, Feb 17, 2015 at 12:07 AM, Fernando Frediani <fhfredi...@gmail.com> wrote: > Hello bkil, > > Many thanks for your detailed response. > I would gladly post it to openwrt-users if that worked, which doesn't seem > to be the case as far as I know. > > But also taking the opportunity in this devel list to ask if anyone worked > of ever saw any work to develop a open TDMA implementation that could be > merged to OpenWRT. I personally have read a while ago about some material > that was developed for FreeBSD, but there wasn't much information really and > no much other than that I could find unfortunately. > > Regarding your response I was particularly interested in the RTS/CTS > configuration and hear about optimal RTS Threshold values. > Also does that AP and Clients have to have exactly same RTS/CTS > configuration and RTS Threshold values or only the AP is enough ? > This is more common in WISP providers, but would that be also for example in > internal areas with many clients (e.g: a conference) where the clients > aren't aware about having to enable the RTS/CTS protection and eventually > the threshold ? > > Regards, > Fernando > > > On 16/02/2015 19:24, bkil wrote: >> >> Dear Fernando, >> >> You should have posted this question to OpenWrt-User, but I will answer it >> here. >> >> I haven't personally deployed such a configuration, yet. I don't think >> you can do much besides enabling RTS/CTS at every CPE (client). Much >> fewer connected clients will be supported compared to a TDMA system. >> >> However, here are some other non-default settings you could test: >> * coverage class/distance optimization >> * try narrow 5-10MHz channels in case of a crowded neighborhood - >> sometimes less is more >> * if link speed is already maxed out for the closest nodes, you may >> try to reduce their tx power while maintaining the link speed and >> error rate, though I wouldn't expect much effect >> * after you've measured the link margin and its fading characteristic >> at each of your clients, you could consider increasing the mandatory >> basic_rate and mcast_rate to reduce airtime a bit more >> * you could experiment with increasing the beacon interval, though >> each station should already sync and avoid interference with those, >> and this could reduce stability >> * you may increase dtim_period a bit - again not much effect >> * consider blocking most kinds of broadcast/multicast packets if your >> network doesn't need it >> * compared to AP mode, 802.11s mesh mode has various promising >> techniques for precise node coordination and time slot reservation in >> the standard which may or may not have been implemented, so you should >> have a look >> * RTS/CTS should be enough, but another option would be to reduce max >> packet size (fragmentation threshold), which will also gravely reduce >> your throughput >> * you may reduce the number of retries as a last resort and hope for >> the upper layers to limit rate (black magic) >> ... >> >> Hardware considerations: >> * use good directional or sector antennas and/or shielding at the base >> to reduce noise from the surrounding buildings >> * 5GHz is less crowded >> * the best solution would be to insert a few intermediary nodes to >> form a mesh instead of a star topology - unslotted and uncoordinated >> medium access has its limits >> * or at least offload the clients to multiple hotspots operated at the >> same location, but using different frequencies or polarization >> >> Note that not all options are displayed on Luci, but you could add >> them to /etc/config/wireless manually (some could require capability >> overrides): >> http://wiki.openwrt.org/doc/uci/wireless >> >> An interesting hack come to mind. What if we turned the situation >> around? You could operate each CPE in AP mode with a very long beacon >> interval. The portal (gateway) itself would operate in multi-STA. >> After some u-APSD/PS-POLL tweaking, you could power save on all but >> one AP similar to how it's done by default on multi-frequency >> multi-STA. The portal would essentially unmute a single CPE at a time >> in a round-robin fashion. It sounds a bit quirky and it would surprise >> me if the solution scaled beyond a few dozen CPEs, but it would >> enforce a kind of TDMA and it might theoretically eliminate collisions >> without RTS/CTS if that is your thing. Bandwidth utilization and >> latency would leave much to be desired, however. >> >> I'm all into radio propagation, so please do share your views and >> findings about this question. >> >> Regards >> >>> Hi guys, >>> >>> What is the best alternative to TDMA when using OpenWRT and Outdoor / >>> PtMP access ? Any specific configuration to be done in OpenWRT in order >>> to deal with multiple clients in different ranges ? >>> >>> Thanks >>> Fernando >> >> _______________________________________________ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > _______________________________________________ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
