Firetide? LOL
I’m good friends with the guy who did the design for Firetide. He was, after all, the director of engineering there prior to the VCs moving the company from Hawaii to California. He’s the one who also contributed the OLSR port freeBSD (which pfSense picked up). Said it was just as good, if not better, than the proprietary algorithm in the Fireturd firmware. Firetide was based on Soekris for the longest time. I don’t know what they do these days. The founding CEO of Firetide had me put together a business plan and technology for a competing product. That’s Concentris today. http://www.concentris-systems.com/management.php <http://www.concentris-systems.com/management.php> Just to be pedantic, one needs to be concerned with three things here. Noise - defined as ‘non-coherent signal’. Interference - defined as coherent (decodable) signal that you didn’t want. High ‘enough' signal levels causing the 802.11 MAC to block transmit. (known as ‘clear channel assessment’) The signal level(s) that cause this are different for coherent and non-coherent signals. First, note that 802.11 very very polite. This is by design. Second let’s look at Thermal Noise power. I can walk you through the equation, or you can JFGI, but at the end of the day, for room temp: -174 dBm per Hz • 5 MHz is 67 dBs more than 1 Hz • increase of 1 million times = 60 dB • increase of 5 times = 7 dB • 5 MHz Channel Minimum Noise = -174 + 67 = -107 dBm And, every doubling of the channel bandwidth is another 3dB more thermal noise. Double the channel bandwidth, and 3dB more noise shows up. 20MHz: -101 dBm 40MHz: -98 dBm 80MHz: -95 dBm 160MHz: -92 dBm Now that we know how much background noise to expect in our channel, the next step in figuring out the noise floor is to allow for the thermal energy generated by the receiving Wi-Fi equipment. All Wi-Fi equipment dissipates thermal energy even when not in the act of transmitting. This energy is a result of the heat being given off by the electronics of the device. “Noise figure” is the term that refers to the thermal energy given off by the electronic device being used. The noise figure varies between vendors and designs, but will typically be between 1 and 5 dB. These are the things that are unavoidable. They are physics, and will be present even in a greenfield deployment. and for a 40MHz 802.11n channel, we’re already down to something between -97 (you wish) and -93 (more likely) dBm for a true noise floor. Now then, a Wi-Fi chip is a communications processor – literally a MODEM with a non-wire PHY. It only knows: - RF Energy that can be demodulated = Wi-Fi (interference) - RF Energy that can not be demodulated = Noise Noise is complicated: Collisions, fragments, corruption, Wi-Fi that is below sensitivity threshold of the receiver Peaks in Wi-Fi activity can cause all of these to occur. Other, non-802.11 sources. Now, for CCA there are two types: - Energy Detect: This is quick, runs at low power, but is prone to false positives (power matters for devices with batteries) - Decode Preamble: This takes time, and the receiver is running, so it takes power, but is less prone to false positives. ED CCA threshold for 802.11b/g is -65 dBm CCA for 802.11a is different -65 dBm ED, if true then 20 dB lower for Preamble interrogation needs to be processed, so -85 dBm For 802.11n/802.11ac, things get more complicated. You have to sense on both the primary channel, and the secondary channel(s) Channel width Signal threshold (primary) Signal threshold (non-primary) Energy threshold (non-primary) 20 MHz –82 dBm –72 dBm –62 dBm 40 MHz –79 –72 –59 80 MHz –76 –69 –56 160 MHz –73 n/a(*) n/a(*) (*) With 160 MHz channels, there are no secondary channels, so these thresholds are not defined. Now look at the room we have left between the thermal NF (including the NF of the receiver) without *any* additional noise or interference due to non-coordinated operation, and the level at which an 802.11 will block transmit. Now let’s look at the *minimum* SNR required to decode 802.11g/802.11a rates: 802.11a/b/g/ Data Rate (Mb/s) Minimum Required SNR to decode (dB) 1 4 2 6 5.5 8 11 10 6 4 9 5 12 7 18 9 24 12 36 16 48 20 54 21 802.1n Data Rate (Mb/s) Spatial Streams Minimum Required SNR to decode (dB) 15 1 9.3 30 1 11.3 45 1 13.3 60 1 17.3 90 1 21.3 120 1 24.3 135 1 26.3 157.5 1 27.3 30 2 12.3 60 2 14.3 90 2 16.3 120 2 20.3 180 2 24.3 240 2 27.3 270 2 29.3 300 2 30.3 Now that we’ve spoken about ‘secondary channels’ (which are what we call adjacent channels when we run 802.11n/802.11ac at > 20MHz channel width), let’s talk about the selectivity of your normal, every-day WiFi radio. First, we’ll go all the way back to 1997. To my knowledge, none of the 802.11b radios formerly on the market had enough selectivity to eliminate in-band signals from a nearby radio operating on an adjacent (25Mhz away) or alternate (50MHz away) channel. (I’ll pause to point out that 802.11b used a 25MHz channel width.) Minimum IEEE specs for an 802.11b receiver is 35dB of adjacent (25MHz away) channel rejection. IEEE doesn't publish specs for alternate channel rejection on 802.11b, but I can tell you that the best designs (in terms of ACR) are the "old" super-het receivers. Intersil (subsequently Connextant)'s Prism2/2.5 was good for about 41dB of ACR, the Lucent/Orinoco design was similar. Alternate channel rejection is perhaps 20dB "better" with these chipsets. This means that if you're operating (your Prism 2/2.5 or Orinoco chipset radio) on channel 11, a signal on channel 1 will be 60dB down from where it would be if your radio was on channel 1. Free space path loss (**) in the first meter @ 2.4GHz is -41dB. Lets say you've got a garden-variety radio that puts up 32mW (15dBm) of tx power, and ignore antenna gain for now (so 0 dBi antennas on both radios). 15dBm - 41dB = -26dBm, and 15dBm - 60dB = -45dBm. These are the in-channel 'noise power' of the alternate channel radio for the chipsets detailed above, for adjacent and alternate channel operation. Notice that it is at least 55dB (> 200,000:1) above the thermal noise floor (lets say -100dB for now.) Translated: you've significantly lowered your SINR. Moreover, this signal level is at least 40dB (10,000:1) higher than the 802.11b CCA threshold, so you'll quiesce the entire cell (no matter which radio was trying to operate) whenever one transmits. Its worse than this, if one radio was receiving, you've destroyed the incoming packet(s). Thus, in 802.11b, even if you pick "1 and 11", you're going to end up with significant in-channel power from any operation on the alternate channel by a close-by transmitter. (This is why you can't "co-locate" APs in the same band on a rooftop or tower. But try, just *try* to discuss this in a rational manner with most "wireless ISPs”.) Now, if you add any antenna gain to the equation, then, unless you manage to find really special antennas, (or use channel filters, etc) then the gain of both antennas affects the above in a negative way. At the end of the day, a 10m separation with small (2.2dBi) antennas was often practical with 802.11 (pre-b) and 802.11b. By the time you move from 1m to 10m, the free space path loss has increased from -41dB to -60dB, which is "barely enough". (do the math!) So the minimum (and essentially optimal) 802.11b AP separation with 2dBi antennas on channels 1 and 11, in free-space, is around 10m. Any closer and you're raising the noise floor in any AP or client that is receiving a packet. Note that a client between the two APs may be on either channel. (In 802.11, the client gets to pick which AP to associate with.) Where there is one, there can be two, and these two might end up on different APs (and different channels), and as a result, interfere with each other's frames. The answer here (and with 802.11g/802.11a networks) is not the little cells on a hexagon layout that you so-often see in the literature, but rather larger cells of co-channel APs, laid out on the same hexagonal pattern. This minimizes the 'edge cases' just described and lets CCA (see below) do its job. This situation got (much) worse with 802.11g and 802.11a. Due to their (now universal) direct conversion archectures, and some interesting properties of OFDM, most 802.11g and 802.11a receivers can't muster even the 35dB of ACR that the IEEE specifies for 802.11b when operating in the 802.11g / 802.11a modes on adjacent channels, and for these reasons, the ACR specification was reduced for 802.11g and 802.11a receivers. In the IEEE specification, ACR varies by modulation rate, but the minimum ACR for 802.11g/a at 6Mbps is 16dB (alternate is 16dB more, for 32dB). This goes down to -1dB (yes, -1dB) ACR @ 54Mbps (with alternate channel rejection at 54Mbps down to 15dB.) The chipset vendors I've spoken with during past jobs have stated that they might be able to get a dB or two better than the spec, (and we've not begun to discuss tolerance issues) but the point is moot, you have to deal with the clients that walk in the conference room door, and these are likely to be bottom-of-the-barrel minimum spec units, if for no other reason than the manufacturer was shaving pennies. This situation got *way* worse with the advent of 802.11n, then 802.11ac. Modulation Rate (R) Adjacent channel rejection (dB) Nonadjacent channel rejection (dB) 20/40/80/160 MHz Channel 80+80 MHz Channel 20/40/80/160 MHz Channel 80+80 MHz Channel BPSK 1/2 16 13 32 29 QPSK 1/2 13 10 29 26 QPSK 3/4 11 8 27 24 16-QAM 1/2 8 5 24 21 16-QAM 3/4 4 1 20 17 64-QAM 2/3 0 -3 16 13 64-QAM 3/4 -1 -4 15 12 64-QAM 5/6 -2 -5 14 11 256-QAM 3/4 -7 -10 9 6 256-QAM 5/6 -9 -12 7 4 These are measured at a Packet Error Rate (PER) of 8%. This equates to roughly a BER of 10%. Note that there is much more opportunity for separating APs into different sub-bands of the spectrum allocated for 802.11a. This spectrum covers from 5.150 - 5.350 GHz and 5.470-5.825 GHz (U-NII rules) and/or 5.725 - 5.850 (ISM rules). There are some restrictions here (5.150 - 5.250 GHz is for 'indoor-only' operations, 23dBm EIRP, and must use fixed antennas. Operation between 5.250 - 5.350 and 5.470-5.725 GHz is limited to 30dBm EIRP, and such operations must support both dynamic frequency selection (DFS) and transmit power control (TPC). These restrictions serve to 'limit' the applicability of these frequencies to outdoor use, but the interesting applications for WiFi are indoors. So, assuming a conforming AP can be operated as low on the 5.150 - 5.250 GHz band as possible (without violating the restriction that any out of band emission be no higher than -27dBm/MHz from the band edge (*)), and assuming that operation is under the FCC (USA) regulatory domain, the lowest available channel is "36" with a center frequency of 5.180GHz. We've already seen (above) that alternate channel operation (50Mhz away) **at 6Mbps** results in a mere 32dB of ACR (IEEE minimum), and moving beyond a 60MHz spread is going to put the next AP in the middle of 5.250 - 5.350, operating on either "58" 5.280 or "60" 5.300GHz (better). Now we've used 2 'sub-bands' for two APs. Assuming your (potential) clients all support operation in the 'new' 5.470 - 5.725 GHz band, there are opportunities for 3, or possibly 4 more APs that won't interfere with each other, or nearby clients on an adjacent 'sub-band'. There is potential for one more 'cell' in the 5.725-5.825 GHz band, but don't let it interfere with operation in the band directly below, so likely operations will occur on 5.805 GHz (channel 161). So yes, you can support 6 (perhaps 7) more "cells" using these bands, assuming your clients can use them. So that’s my recommendation. Up to 6 or 7 clustered APs, but only 1 AP per ‘band’ in a given ‘cell’. Additional cells in the same room run co-channel. The thing you really have to understand is this: In wireless, it is a sin to throw what would have been an otherwise correctly-received packet on the floor (or destroy it as outlined above.) You really can't afford to have a near-by AP think the air is clear (because its off- channel) and then stomp on the reception of some near-by AP or client. Now let’s go back to Clear Channel Assessment (CCA). As a reminder, this function of the 802.11MAC blocks transmission (even on a client) if either a) there is a strong signal using the wireless medium, or b) there is a somewhat weaker signal, which is clearly an 802.11 signal (that is, "this" radio has decoded the preamble), above a given threshold. We did a bit of work at Vivato to make several radios (13 in the 11b product, 6 in the 11g product) synchronize via the CCA signal, such that if any of them was receiving a packet, none of the others would transmit. This is the key to making a “big room" network really fly. Multiple, independent APs, all on the same channel, which are able to co-ordinate operation between themselves in a highly- similar manner. Given the higher rates of 802.11g (54Mbps translates to about 27Mbps of throughput for a single client, but this degrades with increased loading by additional clients), or, better, 802.11n, 802.11ac, its entirely possible to have the available 'in-room" bandwidth exceed the typical "Internet connectivity" bandwidth for most situations. Another issue at Vivato was that the 'antennas' for these radios were both highly directional and pointed in different directions, so the actual signal level might not be high enough to set CCA to a given client, but any the clients transmitting would ruin the reception (at the AP) of any other. If you look at the patent art out of VIvato, one of the big ideas at Vivato was "complementary" beam forming, which was a method to raise the signal level "high enough" for the rest of the clients to keep them from transmitting (and ruining the inbound packet. See: <http://www.ll.mit.edu/asap/asap_03/6-page_Papers/tarokh_ASAP.pdf <http://www.ll.mit.edu/asap/asap_03/6-page_Papers/tarokh_ASAP.pdf> > When you consider that channel models out of AT&T Bell Research and Harvard show that the 54Mbps 'rate' of 802.11g / 802.11a can only be achievable at a radius of 8 meters in a NLOS (non line-of-sight) environment, and that to maximize throughput to/from a room-full of radios, you want to be able to send (and receive) at the highest rate possible, the desirability of an architecture designed to do same seems inevitable. As a reminder, a 'radius of 8m' will cover a room where the walls are no farther apart than 37 feet. However, with 802.11n, range can be as much as doubled (even through walls) compared to the same operation using conventional IEEE 802.11 OFDM, if the environment supports "sufficient" orthogonality in the channel matrix. (You can think of this as 'scattering', see http://www.triquint.com/prodserv/tech_info/docs/WJ/Indoor_prop_and_80211.pdf <http://www.triquint.com/prodserv/tech_info/docs/WJ/Indoor_prop_and_80211.pdf>.) But… whatever. I don’t know anything about WiFi. Jim > On Jul 20, 2015, at 1:07 PM, Ryan Coleman <[email protected]> wrote: > > Well… this is my area of expertise at work: cheap hardware begets bad > experiences. > > OTC hardware is cheap. Even if you pay a lot for it. > > Firetide, FluidMesh and Rajant are the best hardware on the market for what > you’re describing. And VERY expensive. > > > >> On Jul 20, 2015, at 12:31 PM, Karl Fife <[email protected]> wrote: >> >> Both Zero Handoff and Wireless Backhaul for Wi-Fi have proven to be *not >> useful* technologies for us due to the transient and unpredictable nature of >> Wi-Fi interference. Both technologies have correlated risk factors that >> cause cascading performance degredation. As interference or load increases, >> the probability of adverse loss, jitter, and latency also increase. That >> breaks the network's suitability to many applications. >> >> SNR in the backhaul band can be fine for days, then can become absolute shit >> for hours, seemingly for no reason. Site analysis shows an energy spike in >> the backhaul band. Maybe somebody's 'smart' AP has changed channels. Maybe >> someone is microwaving a baby monitor. Maybe the UFO's just outside probe >> my brain using the Wi-Fi bands to steal my secret plans. Architecture using >> these technologies can be acceptable for hobbyists, or for when there is >> literally no other option within budget, but IMO architecting a system with >> them is similar to setting out for a day on the ocean with a life jacket >> (i.e. no boat). >> >> Zero Handoff? >> This we've measured less carefully, but performance appears to tank far >> sooner in this scenario too. Please chime in if you have specific expertise >> on this technology, but this appears that ZH depends upon low interference >> on a single channel across the entire handoff 'campus'. That's a pipe >> dream in dense condominiums and high-rise office buildings. It may be OK if >> you live in a Faraday cage or on a drilling platform in the ocean. Apart >> from those scenarios, we've never been "on the fence" as to whether we >> should use it. >> >> Now AC on the other hand... I love me come AC. Plus, they tend to serve >> double duty as space heaters. >> -KF >> >> >> >> >> >> On 7/17/2015 10:37 AM, Zandr Milewski wrote: >>> Be aware, though, the UAP-AC is missing some banner UniFi features. >>> >>> No Zero-Handoff >>> No Wireless Backhaul >>> >>> I can't tell if any of the UniFi indoor stuff does the UNII-2e/DFS stuff. >>> The AC's certainly don't. >>> >>> On 7/17/15 08:29, David Burgess wrote: >>>> On Fri, Jul 17, 2015 at 8:45 AM, Chuck Mariotti <[email protected]> >>>> wrote: >>>>> We are having a number of issues with Engenius Access Points... they >>>>> seems to have the features we need but for some reason, connectivity is >>>>> not reliable (seems Mac related). As much time as I would like to spend >>>>> debugging it, it would be cheaper to replace. >>>>> >>>>> Does anyone have any recommendations for small office access points? >>>> >>>> >>>> I second both of the previous replies. I use Unifi and Tomato >>>> exclusively for wireless. >>>> >>>> For budget installs with plenty of features, try Shibby's Tomato on >>>> the ASUS RT-N12 or RT-AC66U. >>>> >>>> For POE, top aesthetics or mass deployment and central management, >>>> spend a little more on the Unifi. >>>> >>>> db >>>> _______________________________________________ >>>> pfSense mailing list >>>> https://lists.pfsense.org/mailman/listinfo/list >>>> Support the project with Gold! https://pfsense.org/gold >>>> >>> >>> _______________________________________________ >>> pfSense mailing list >>> https://lists.pfsense.org/mailman/listinfo/list >>> Support the project with Gold! https://pfsense.org/gold >> >> _______________________________________________ >> pfSense mailing list >> https://lists.pfsense.org/mailman/listinfo/list >> Support the project with Gold! https://pfsense.org/gold > > _______________________________________________ > pfSense mailing list > https://lists.pfsense.org/mailman/listinfo/list > Support the project with Gold! https://pfsense.org/gold _______________________________________________ pfSense mailing list https://lists.pfsense.org/mailman/listinfo/list Support the project with Gold! https://pfsense.org/gold
