You are here

Ubiquiti Rocket AP's - Techie Question

9 posts / 0 new
Last post
KB9YOJ
KB9YOJ's picture
Ubiquiti Rocket AP's - Techie Question

Hello-

I'm a wireless engineer by career and was curious if the AREDN firmware allows for the Ubiquiti Rockets to accomplish TDMA?  If not, which MCS is the router using for data links?

Matt
KB9YOJ

K6AH
K6AH's picture
No TDMA

TDMA protocol implementations are typically proprietary.  OpenWRT, which is the core of AREDN, has no drivers for TDMA.  There have been a couple of master's projects that created drivers, but so far not for OpenWRT.  I am as eager to see one for the same reason I assume you are.  The project core team keeps an eye out for it.

AREDN uses CSMA/CA.

Andre
K6AH
 

AE6XE
AE6XE's picture
Matt,

Matt,

The last reported state of TDMA in the ath9k linux wireless driver in use is here:  ​http://adrianchadd.blogspot.com/2012/11/getting-tdma-working-on-80211n-c... .  No one in the greater linux wireless community has completed this work, that I know of.  

The AREDN firmware is using the ath9k linux wireless driver, modified for part 97 channel support.  it is fully compliant with all the MCS rates of 802.11n .  We are routinely running 40 mile links hovering in MCS13 to MCS 14 rates on 10Mhz channel width with 2' 30dBi rocket dishes.  At distance, this will be LGI.

What is your background?  Deployment, firmware, hardware, other?   Someone with the right back ground and interest may be able to complete this TDMA work in the ath9k.

Joe AE6XE

KB9YOJ
KB9YOJ's picture
Andre-

Andre-
Thanks for the info.  Yes, I'd like to see higher throughput and MCS rates one day.  I'd also like to see routers with multiple radios doing "multi-channel backhaul" in the future without using switches for the L2 interconnection between radios.

Joe-
Sorry, I focus more on Network Operations and engineering.  Never have been a developer.  Lower-scaled stuff that deals with edge switching, routing, and enterprise grade wireless systems hardware and deployment.  I also do predictive analysis for 802.11 networks, and passive 802.11 surveys for site troubleshooting.  My interest is seeing higher MCS rates and higher throughput.  Does the firmware support antenna diversity and MIMO for AP's with multiple antennas?

Matt
KB9YOJ
 

AE6XE
AE6XE's picture
Yes, MCS8 to MCS15 are dual

Yes, MCS8 to MCS15 are dual chain MIMO -- different data xmit and receive on each antenna chain.   If receiving on the MCS0 to MCS7 single antenna rates, the xmit will send same data on both antenna chains and the receive will use MRC, Maximum-ratio combining, to munge the signals received from both antennas together, and then will decode the data stream.  

We predominantly only find 2 antenna devices with polarities 90deg apart on the market.   I"ve heard of 3 chain antennas and devices, but this must mean polarities are  60deg apart.  The problem with longer distance Point-to-Point links is that SNR becomes a significant issue.    If the power is split to 3 or even 4 antenna chains, this means the power is lower on each chain as it is divided up.  more antennas mean lower SNR per antenna signal and that means less distance to achieve the same rate.  Also, there's more interference between polarities, the more antenna chains there are.   802.11ac can do 8 antenna chains, but this is only beneficial in short distances, e.g. inside a house.

KB9YOJ
KB9YOJ's picture
Plenty of meat on the bone with a Bullet M2

Thanks for the detailed explanations.  Most of the AP's we use on campus are 802.11n 3x3 MIMO, and we are slowly changing to phase 2 802.11ac which will do MU-MIMO.  Good for in-house wireless........

We're going to be setting up our first MESH network to link 2 campus ham-shacks together.  It's not too far away, about 1.5 miles.  We'll install 3 nodes with the center "hop" being the LOS between both sites.  Shack AP's will be NanoStation M2's, with the middle hop being a Bullet M2 with a 15 dbi omni.  We could probably get away with a smaller antenna, but it's "run what ya brung" for us.  Once we finish testing, then a wider deployment will happen.  We have some repeaters that could use data, and a MMDVM data network in the works too!

If we even need mode bandwidth for our primary links, we might eventually upgrade to M2 Rockets.  But for the sake of financials, we'll stick to the cheaper stuff.  Plenty of bandwidth to play at MCS7.

Matt
KB9YOJ
 

AJ6GZ
TDMA

One of the benefits of TMDA is the "hidden node problem" (if u believe the marketing) where in that two stations shouldn't ever be transmitting at the same time since they're all given designated time slots from the AP. There are some mechanisms to combat this in standard 802.11 too, but it some situations it definately breaks down. Then again so does TDMA after a certain number of clients :) One disadvantage of it is that I don't think it will allow all stations to be access points and clients at the same time like we have now on the mesh. So no meshing only point to multipoint. This can be a benefit tho as locally we've seen a scenario where "client 1" pointed only at "client 2", vastly degrading "client 2"'s connection to the "AP" up on the mountain as well as client 3,4,5, since client 2 was "hidden" from all other sites. We guess that all the retransmits and such from client 2 were pooching the mechanisms up on the AP for everyone. Under both signalling methods a significantly bad client can bring down everyone.

The quest for more speed, particularly on the backhaul and permanent site-to-site links has been brought up before. The idea is we may want to look at non-AREDN nodes for this purpose. Basically a DtDLink something other than Ethernet as long it's near 100% reliable.

Rock the MIMO! It's math!

AE6XE
AE6XE's picture
AREDN is configured using the

AREDN is configured using the 802.11 adhoc mode vs AP or client-AP mode.   With the 802.11 AP mode, the devices would have to be designated, generally the tower site nodes.  This would come with the constraint that a client  wouldn't be connecting to multiple cell sites or tower sites at the same time.   With adhoc, we can do this.    This constraint might be good or bad.      AREDN's firmware design is to not require an IT guru -- it will just work.  Requiring a design to be made before hand means more complexity to have a working network for an incident. 

I'm not aware of TDMA implementations on top of adhoc mode implementations.   This may never happen as TDMA needs a mechanism of who is designating the timed slots for everyone to use.   This naturally pushes back to using the AP mode where the AP is the master controlling the client's timing (regardless of CSMA or TDMA in use).  The prior work in the linux community to implement TDMA has only been done on AP / AP-client modes.    Note that CSMA can also define timed slots for a client to transmit, this is what is done with the CTS/RTS handshaking and also was designed to address the hidden node problem.   It would be fair to say that CSMA w/ CTS/RTS is a hybrid form of TDMA.

I'm not convinced that TDMA vs CSMA will be that much of a performance difference as the marketing hype of vendors have made it out to be.  I'd like to see some data comparing same equipment and links, only this protocol difference.   We can readily do that on the 3Ghz rockets on a link, just measure throughput with AREDN, then load AirOS TDMA  and do the same measurement.    This would be in part 97 channels relatively free of other interference  to influence the outcome.    

Joe AE6XE

w6bi
w6bi's picture
Excellent

Excellent explanation, Joe - thanks!
Orv W6BI

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer