[OpenWrt-Devel] Alternatives do TDMA

Tue Feb 17 07:20:26 EST 2015

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
<fhfrediani at 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 at lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel