Re: [OpenWrt-Devel] Alternatives do TDMA
Sorry to jump in on an older tdma thread, but I found two interesting things. It looks like Russian company called NETSHe have made TDMA driver: http://www.netshe.ru/files/doc/en/TDMA_brief_en.pdf http://www.netshe.ru/tdma And also there was a intesting job posting for developing TDMA driver for cliend in United Arab Emirates: https://www.elance.com/j/outdoor-wireless-open-wrt-atheros-development/69183838/?backurl=aHR0cHM6Ly93d3cuZWxhbmNlLmNvbS9yL2pvYnMvcS1vcGVud3J0Lw== So I guess there are few working implementations out there, but just not is open source so far :( ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alternatives do TDMA
Sorry for not sending all links at once (some consider it spammy), but I also see that NETSHe guys extensively tested different size time slots and did benchmarks and comparisons: http://netshe.stasoft.net/node/47 And here are their results: http://netshe.ru/files/doc/en/test_results_28032015.pdf This seams like a stable and tested TDMA driver which is in development for around 5 years. Versions prior to stable 1.0 also had their source posted on UBNT forums (search for NETSHe on Ubiquiti forums). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alternatives do TDMA
I have your found out that NETSHe offers some of their firmwares for free download and testing with TDMA enbled driver: http://netshe.ru/files/NETSHe-3.0/ On 14 July 2015 at 10:47, valent.turko...@gmail.com valent.turko...@gmail.com wrote: Sorry to jump in on an older tdma thread, but I found two interesting things. It looks like Russian company called NETSHe have made TDMA driver: http://www.netshe.ru/files/doc/en/TDMA_brief_en.pdf http://www.netshe.ru/tdma And also there was a intesting job posting for developing TDMA driver for cliend in United Arab Emirates: https://www.elance.com/j/outdoor-wireless-open-wrt-atheros-development/69183838/?backurl=aHR0cHM6Ly93d3cuZWxhbmNlLmNvbS9yL2pvYnMvcS1vcGVud3J0Lw== So I guess there are few working implementations out there, but just not is open source so far :( ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alternatives do TDMA
On 14/07/2015 11:18, valent.turko...@gmail.com wrote: I have your found out that NETSHe offers some of their firmwares for free download and testing with TDMA enbled driver: http://netshe.ru/files/NETSHe-3.0/ looks like it is based on owrt, did you manage to find the GPL source ? is the tdma linked directly into the kernel or provided as a module ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] alternatives to TDMA
2015-07-14 17:50 GMT+02:00 Bill Moffitt bmoff...@ayrstone.com: My understanding is that UBNT has an ASIC in their devices to help with the timing of the TDMA mode. My suspicion is that, without that ASIC, software only TDMA would probably not be precise enough to bring benefit. Does anyone have a better understanding of this? I have no clue about this but there is a FreeBSD implementation that is adverstised to work on Atheros chipsets: https://wiki.freebsd.org/WifiTDMA + https://people.freebsd.org/~sam/FreeBSD_TDMA-20090921.pdf regards Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] alternatives to TDMA
My understanding is that UBNT has an ASIC in their devices to help with the timing of the TDMA mode. My suspicion is that, without that ASIC, software only TDMA would probably not be precise enough to bring benefit. Does anyone have a better understanding of this? -Bill ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alternatives do TDMA
After some more research I found that FreeBSD recently added TDMA support to their ath driver [1]. Friend of mine just tried to use it on some cheap TP-Link device but currently TDMA support is broken but it will be fixed in next few days. [1] https://wiki.freebsd.org/dev/ath%284%29 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] alternatives to TDMA
Hi Bill, I´m not sure about this. Do you have the source to confirm this ? Fernando On 14/07/2015 12:50, Bill Moffitt wrote: My understanding is that UBNT has an ASIC in their devices to help with the timing of the TDMA mode. My suspicion is that, without that ASIC, software only TDMA would probably not be precise enough to bring benefit. Does anyone have a better understanding of this? -Bill ___ 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
Re: [OpenWrt-Devel] Alternatives do TDMA
2015-07-14 18:45 GMT+02:00 Martin Tippmann martin.tippm...@gmail.com: 2015-07-14 11:34 GMT+02:00 John Crispin blo...@openwrt.org: On 14/07/2015 11:18, valent.turko...@gmail.com wrote: I have your found out that NETSHe offers some of their firmwares for free download and testing with TDMA enbled driver: http://netshe.ru/files/NETSHe-3.0/ looks like it is based on owrt, did you manage to find the GPL source ? is the tdma linked directly into the kernel or provided as a module ? Here is some information from them: http://www.netshe.ru/wirelessstack - Sorry did not found this before. However there seems to be no download for the GPL patchsets... regards Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alternatives do TDMA
2015-07-14 11:34 GMT+02:00 John Crispin blo...@openwrt.org: On 14/07/2015 11:18, valent.turko...@gmail.com wrote: I have your found out that NETSHe offers some of their firmwares for free download and testing with TDMA enbled driver: http://netshe.ru/files/NETSHe-3.0/ looks like it is based on owrt, did you manage to find the GPL source ? is the tdma linked directly into the kernel or provided as a module ? I just took an image and did a grep -ri tdma and got the following results: Übereinstimmungen in Binärdatei ./usr/lib/libpcore.so.4.0.0. Übereinstimmungen in Binärdatei ./usr/sbin/iw. Übereinstimmungen in Binärdatei ./lib/modules/3.8.6/mac80211.ko. Übereinstimmungen in Binärdatei ./lib/modules/3.8.6/pdwext.ko. Übereinstimmungen in Binärdatei ./lib/modules/3.8.6/cfg80211.ko. Übereinstimmungen in Binärdatei ./lib/modules/3.8.6/ath.ko. Übereinstimmungen in Binärdatei ./lib/modules/3.8.6/pnwext.ko. Looks like they at least modify GPLd iw, ath9k and mac80211 code or am I wrong here? regards Martin some strings output: [~/tdma/squashfs-root]$ strings ./usr/sbin/iw | grep -i tdma tdma TDMA join_tdma leave_tdma Join the TDMA network with the given frequency, version, slots, bitrate and keys Leave the current TDMA network. [~/tdma/squashfs-root]$ strings ./lib/modules/3.8.6/cfg80211.ko | grep -i tdma /home/stanislav/stasoft/NETSHe-SDK-4/barrier_breaker/openwrt/build_dir/target-mips_r2_uClibc-0.9.33.2/linux-ar71xx_generic/compat-wireless-2014-05-22/net/wireless/cfg80211_tdma.c [~/tdma/squashfs-root]$ strings ./lib/modules/3.8.6/mac80211.ko | grep -i tdma TDMA: It is the first node. Start with node_id (%d) TDMA: Try to associate with node_id (%d) and node_bitmap (%04X) TDMA: No neighbours or beacons in ASSOCIATING state. Reset state to UNKNOW TDMA: All neighbours accept this node settings. Change state to ASSOCIATED TDMA: Not all neighbours voted for this node. TDMA: (%lu) All neighbours do'nt see node / or beaconing troubles. Reset node. (LV %lu / LB %lu / TC %lu / NB %d) TDMA: Could not allocate memory for beacon! TDMA: Could not put beacon header into skb! TDMA: Could not put ESSID into skb! TDMA: Could not put basic rates into skb! TDMA: Could not put ext rates into skb! TDMA: Could not put HT capabilities into skb! TDMA: Could not allocate beacon TDMA: Could not put TDMA info into skb! TDMA: Could not put peer info into skb! 6%s: Failed to join TDMA network, DFS for specified channel is required TDMA: Something wrong TDMA: Start network join with %d nodes and %d version TDMA: Setuped bitrate - %d. Calced - %d. Supported Rates - %x TDMA: Round duration - %lu, TX slot duration - %lu, Second TX slot duration - %lu TDMA: Beacon interval in TU - %d. TDMA: stop is called TDMA: leave is called TDMA: Enable frame transmission TDMA: Wrong beacon len - %d TDMA: Different SSID TDMA: Wrong ie len - %d TDMA: Wrong IE - %d TDMA: Wrong version - %d %d TDMA: Wrong node_id TDMA: Rate mismatch TDMA: Uh-Oh! Beacon with the same ID received. TDMA: Desynchronize this node TDMA: Just ignore it. 6%s: No room for a new TDMA STA entry %pM TDMA: Could not link the key TDMA: Could not allocate key TDMA: Round duration - %lu, TX slot duration - %lu, Second TX slot duration - %lu TDMA: Neighbour with node_id (%d) is voted for this node. TDMA: Disable frame transmission after beacon precessing TDMA: USC - %u TDMA: Reset starts Intf Queue %d TDMA: Reset starts IEEE80211 Queue %d tdma_originator_expire tdma_max_clock_drift tdma_get_skb_from_queue tdma_sta_init tdma_get_avail_slot tdma_get_tx_window tdma_originator_update tdma_calc_ideal_interval tdma_process_pending_frames tdma_store_pending_frame ieee80211_tdma_tx_notify tdma_process_hdr tdma_plan_next_tx tdma_update_skb_hdr tdma_tx_slot_duration tdma_sched_tx tdma_originator_get tdma_amsdu_to_8023s tdma_tu_adjust tdma_update_hdr_counter tdma_tx_slot_calc ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Alternatives do TDMA
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
Re: [OpenWrt-Devel] Alternatives do TDMA
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
Re: [OpenWrt-Devel] Alternatives do TDMA
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] Alternatives do TDMA
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
