.11g performance on M product line

[Belkid]

Hi,

As most of people, i'm very interested by the M product line, but I got some questions regarding the overal .11g performance.

Can we expect similar .11g performance on a nanostation M compare to the regular nanostation ?

From what I understand, the 2x2 mimo feature makes the antenna twice as small, and .11g can only use one at a time (correct ?), so it would reduce a lot the gain/performance/distance ?

On the other hand, I guess there is no reason to buy the regular nanostation anymore in the future if the new one is just better ...

[WHT]

I havne't gotten my hand on a Nanostation M yet, but I'm gonna guess at this point...the MIMO feature would be similar to using the Adaptive Antenna feature as a dual-polarity antenna for MIMI.

There won't be any significant increase in range, but there will be significant improvement in the service area as you now have an alternate path for the radio signal.

The antenna array would still be the same size as with any other b/g format.

With a similar price point as the regular non-AirMax product line, I can see the AirMax family usurping (that means "taking over" for those of you in Rio Linda, California in a Rush Limbaughesque tone of voice). The non-AirMax will still be popular for the thousands of now legacy deployments.

[Belkid]

If I understand good, instead of having 2 antenna, one for each polarization, you'd have 2 pola x 2 mimo = 4 antenna but on the specs, I can see 8 antennas.
http://www.ubnt.com/downloads/nanoM5_DS.pdf

I'm not sure I understand ... from the image it looks like a 4x4 mimo ... not a 2x2

I'm still very affraid that if you use only 1 of the 4 or 1 of the 8 in .11g mode, the gain of the antena would be a lot worse, since it's way smaller.

[WHT]

OK, I stand partially corrected. I'd seen that picture of the internal antennas, but it slipped my mind.

Basically you have two vertical positioned arrays, where the Nano 5 had only one vertical array.

So my observation that the arrays are the same size is still correct. Its basically two identical four-bay array antennas. At 5.8 Gig, each array is 14 dBi, but that doesn't mean two arrays will give you a 17 dBi (2 x 14 dBi = 17 dBi) matrix.

On a side note, as I discussed in the past, switching a vertically aligned four-bay array from VPOL to HPOL will not inherent a true HPOL reciprocate pattern; you would have to flip the Nano on its side...

HOWEVER, with the Nano M5, this does not appear to be the case, it appears to be a true VPOL to HPOL shift.

[Belkid]

The more I read you, the more I'm confused i'm affraid ;)
I'll try to organise my questions :p

0. Could you confirm that there is one four-bay array for HPOL and one for VPOL ? (If yes, i'm lost, because the loco has only one I guess, meaning no switch between POL ?)
1. Why is it a four bay array for 2x2 mimo ? A 2 bay array would be enough, w'nt it ?
2. Does it use the four antenna or the array for .11g ? or only 2 ? or worse, 1 ? I guess we need to use all to keep the same sensitivity ...
3. Why don't you have the same design antenna for the M5 ?



On a side note, as I discussed in the past, switching a vertically aligned four-bay array from VPOL to HPOL will not inherent a true HPOL reciprocate pattern; you would have to flip the Nano on its side...

HOWEVER, with the Nano M5, this does not appear to be the case, it appears to be a true VPOL to HPOL shift.

Do you have a link where this is discussed ?

[WHT]

I'd have to find the link, but basically its what I said above.

Discussing the Nano M5 and M2 radio antenna array:

* There are two antennas. Both antenna have identical performance. This give you the MIMO feature.

* In MIMO operation, in HPOL mode - both are HPOL. In VPOL mode, both are VPOL

* I do not know for a fact if when using non-MIMO, how the antennas will operate; but that is really a moot point as it was never designed for b/g operation.

* The Nano M5 and Nano M2 have same antenna principles. Because the antenna dimensions for 5.8 Gig are half the size as for 2.4 gig, you can have twice the size array. While that doubles you EIRP, you still have the additional path loss due to the reduces antenna aperture, but not to worry as that is compensated with the Friss path loss formula.

* The Nano 5 and Nano M5, and Nano 2 and Nano M2 have the same antenna principles, but the M family has an additional array for MIMO use. For all intent and purposes, it should be considered as a single antenna when it comes to EIRP calculations.

Edited twice for typographic corrections.

[Belkid]

Would it be possible to have a pic of both hardware ?
I think all my confusion came from the pic from the spec of the M5

[WHT]

Nano 2 http://metrix.net/blog/2008/04/09/10/ and http://www.flickr.com/photos/mattw/with/2402293052/

Nano 5 http://whtonline.com/Team_Ubiquiti/NS5_antenna-director.jpg

[WHT]

Technical explanation of the Nano 5 antenna.

Each bay or patch has unity or 0 dBi gain.

Each bay or patch with the director in front of it has about 5 dB gain.

Therefore two bays gives you 8 dBi gain (2 x 5 dB = 8 db)

Adding another two-bay portion doubles it again, (2 x 8 dB = 16 dB) or 17 dBi (as listed in the spec sheet PDF) if you round off all the numbers.

[WHT]

Clarification of "Each bay or patch with the director in front of it has about 5 dB gain."

A single director alone has a 3 dB gain. A single reflector (the back base if the circuit board) has a 5 dB gain. But when you combine a 3 dB director with a 5 dB reflector, your net gain is only 5 dB.

[Belkid]

I'm looking forward to seeing the test about .11g performance.

Unless we use the hardware for pure point-to-point link, I don't think it's realistic to expect only .11n clients in a real environment.

[WHT]

I don't think it's realistic to expect only .11n clients in a real environment.Then there's no sense in adding any AirMax radios.

[Belkid]

I don't think it's realistic to expect only .11n clients in a real environment.Then there's no sense in adding any AirMax radios.

Well, this is the real world, we still have .11b so ... we need backward compatibility. Life's a ***** ;)

[WHT]

AirMax was never designed with traditional a/b/g compatibility in mind. If you don't want to run AirMax all the way, then stay with what you have.

[Belkid]

don't get stressed :)
I'm just trying to understand how is the new product and its limitations.
I guess I have the answers I wanted.

[WHT]

I suppose you could call it a limitation that the AirMax line won't support non-AirMax radios. Or the other way around.

But that would be like saying a Moto Canopy has a limitation that it can't support non-Canopy products.

[opampca]

AirMax was never designed with traditional a/b/g compatibility in mind. If you don't want to run AirMax all the way, then stay with what you have.
mmm...
Is that what Ubiquiti thinks ?

[netsplice]

I think you are looking at this the wrong way. What I am seeing here is two new technologies. .11n and airMax.

.11n is reverse compatible with .11g or .11b but you loose all .11n speeds even if you have another .11n card. if there is even one .11g card the ap can't handle the process.

.11n with airmax is similar to any of the following, canopy, nstreme, alvarion, trango, any one that is using proprietary polling mechanisms. this means that you have to use the same vendor for ap and cpe to be able to use the polling. it is just that instead of ubiquity using a .11a or .11b/g standard to start with they chose .11n.

if you want to use .11b then do not buy airmax products you are wasting time and money. (not that they are that expensive).

if you want to phase out .11b and start using proprietary mechanisms than start using .11n and airmax.

[UBNT-Mike.Ford]

I think you are looking at this the wrong way. What I am seeing here is two new technologies. .11n and airMax.

.11n is reverse compatible with .11g or .11b but you loose all .11n speeds even if you have another .11n card. if there is even one .11g card the ap can't handle the process.

.11n with airmax is similar to any of the following, canopy, nstreme, alvarion, trango, any one that is using proprietary polling mechanisms. this means that you have to use the same vendor for ap and cpe to be able to use the polling. it is just that instead of ubiquity using a .11a or .11b/g standard to start with they chose .11n.

if you want to use .11b then do not buy airmax products you are wasting time and money. (not that they are that expensive).

if you want to phase out .11b and start using proprietary mechanisms than start using .11n and airmax.

This is correct.

Thanks,

Mike

[WHT]

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.

[netsplice]

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.

I would agree I would love to keep legacy combined... however after learning the hard way it doesn't make sense to. i have add mt ap's w/ nstreme on my towers and am having substantial issues that I don't like...

I really wish ubnt would have come out with this 6 months ago.

I am now looking at switch all of my nstreme units to legacy and replacing with airmax equipment on ap and cpe. the price point is just toooooooo gooooooood not to.

I just hope it works as good as everyone claims.

[drwho17]

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.
Sure, but I'm not sure why Ubiquity doesn't implement Airmax in their previous OS, we've got a substantial investment in the "old tech" now, and can't afford to just swap everyone's radio out. My understanding is that their airmax is done in software, and could be backported to previous versions of the airos.

[netsplice]

the issue I beleive is not just software but processing power... the ns2 for example right now are 120mhz or less Cpu might only be 60mhz ... the nsm2 are 400 mhz if I remember what I was reading in another post...

so it is not that the software couldn't be loaded it is that the processing power of the existing equipment would peg and not work.

[UBNT-Mike.Ford]

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.
Sure, but I'm not sure why Ubiquity doesn't implement Airmax in their previous OS, we've got a substantial investment in the "old tech" now, and can't afford to just swap everyone's radio out. My understanding is that their airmax is done in software, and could be backported to previous versions of the airos.

The hardware physically cant take it.

Thanks,

Mike

[WHT]

but I'm not sure why Ubiquity doesn't implement Airmax in their previous OS, It - won't - work...It - ain't - gonna - happen.

we've got a substantial investment in the "old tech" now, and can't afford to just swap everyone's radio out. Then don't swap out your old gear. Thousands of companies stayed with XP instead of upgrading to Vista.

If it works, don't mess with it. Look what happened to AT&T.

[Ron]

The hardware physically cant take it.



Mike, what bothers us, and other WISPs, is replacing hunderds or thousands of CPEs in the field. Replacing the APs is easier and I know the polling is done on the AP side.

So do this:
1) Release a version of AirOS that supports AirMax only in Station and Station WDS mode on "legacy" hardware.
2) If you must, charge for this feature, say $10 per device.


The $10 will cover the cost of software development and lost revenue from fewer devices being replaced.

[UBNT-Mike.Ford]

The hardware physically cant take it.



Mike, what bothers us, and other WISPs, is replacing hunderds or thousands of CPEs in the field. Replacing the APs is easier and I know the polling is done on the AP side.

So do this:
1) Release a version of AirOS that supports AirMax only in Station and Station WDS mode on "legacy" hardware.
2) If you must, charge for this feature, say $10 per device.


The $10 will cover the cost of software development and lost revenue from fewer devices being replaced.

Once again. The hardware cant take it.

Thanks,

Mike

[drwho17]

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.
Sure, but I'm not sure why Ubiquity doesn't implement Airmax in their previous OS, we've got a substantial investment in the "old tech" now, and can't afford to just swap everyone's radio out. My understanding is that their airmax is done in software, and could be backported to previous versions of the airos.

The hardware physically cant take it.

Thanks,

Mike
The client version to a polling system should use minimal CPU. I'm not asking for those radios to run it in AP mode, just in client mode, so I have an upgrade path.

[drwho17]

but I'm not sure why Ubiquity doesn't implement Airmax in their previous OS, It - won't - work...It - ain't - gonna - happen.

we've got a substantial investment in the "old tech" now, and can't afford to just swap everyone's radio out. Then don't swap out your old gear. Thousands of companies stayed with XP instead of upgrading to Vista.

If it works, don't mess with it. Look what happened to AT&T.
Look, I don't know how you run your business, but we don't want to run a new flavor of wireless every year. For technical support reasons alone, I don't want to run a different technology at each tower. You don't seem to be a coder, but on the client side this isn't a big deal to implement this, it's a marketing decision.

It would be one thing if their AirOS radios had been out 3-5 years, but Nano's just came out within the last year, and now they are obselete. Ubiquity is talking about ROI, that's a piss poor ROI when you have to keep shuffling your gear in and out. We didn't buy Ubiquity gear to shuffle it out within a short period of time.

[davey]

I agree with you in that I wouldn't dream of swapping out all existing CPE. Only a madman (or someone with a very small network and a very large amount of money) would do that. We will evaluate it and if it works well, we will use it for new build areas or overlay new sectors at existing locations. Unfortunately that will use more spectrum, but we can wait until vanilla 802.11a sectors are almost full and we would have to put up new gear anyway.

Surely this is the sensible approach?

[lncommunications]

If it works, don't mess with it

Simple as.

We have invested a lot of money just like everyone else but we aint gonna change anything and if you have the money to change it - go ahead and change it! If not you dont have that option.

As ive said before I wouldnt even think of deploying this stuff in a commercial enviroment at least on a large scale for at least another quarter maybe 6 months until we have tested, tested and tested again.

If they hadn't of released it everyone would have been perfectly happy with the now 'legacy' kit and going about just as normal, be thankful that you know a manufacturer that keeps on developing.

This is of course regardless of the fact Mike has already said the hardware cannot handle it, just look at how many clients you can put on the 'legacy' kit anyway, do you really think that more processes for the cpu will make things better?

[WHT]

drwho17...

I agree its ridiculous to retrofit an entire deployment with the flavor of the month. But there comes a time when compelling reasons force you to upgrade, usually when the RF landscape becomes too polluted.

Technology changes. Its unfair to fault UBNT for not coming out with AirMax months, or even years ago. That's like faulting the photography industry for not having digital cameras twenty years ago.

Nor is it unfair to fault anyone with coming out with a new technology that simply can't be fully compatible with all legacy products. That's like faulting laptop companies for introducing the Express card format which is totally incompatible with the legacy PCMCIA format.

If your network is working fine without AirMax, then leave it as it is.

[WHT]

Remember when Bill Gates said 640 KB of RAM would be plenty of memory for any application anyone would ever want to run.?

[UBNT-Mike.Ford]

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.
Sure, but I'm not sure why Ubiquity doesn't implement Airmax in their previous OS, we've got a substantial investment in the "old tech" now, and can't afford to just swap everyone's radio out. My understanding is that their airmax is done in software, and could be backported to previous versions of the airos.

The hardware physically cant take it.

Thanks,

Mike
The client version to a polling system should use minimal CPU. I'm not asking for those radios to run it in AP mode, just in client mode, so I have an upgrade path.


For the third time. The hardware cant take it, I have tested it to death.

Thanks,

Mike

[drwho17]

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.
Sure, but I'm not sure why Ubiquity doesn't implement Airmax in their previous OS, we've got a substantial investment in the "old tech" now, and can't afford to just swap everyone's radio out. My understanding is that their airmax is done in software, and could be backported to previous versions of the airos.

The hardware physically cant take it.

Thanks,

Mike
The client version to a polling system should use minimal CPU. I'm not asking for those radios to run it in AP mode, just in client mode, so I have an upgrade path.


For the third time. The hardware cant take it, I have tested it to death.

Thanks,

Mike
Well, hrm. I guess I will have to accept that then. Will airmax be part of the 5.0 SDK, or binary only? I'd love to tinker with it, and see why it doesn't scale down to the old hardware.

[drwho17]

If it works, don't mess with it

Simple as.

We have invested a lot of money just like everyone else but we aint gonna change anything and if you have the money to change it - go ahead and change it! If not you dont have that option.

As ive said before I wouldnt even think of deploying this stuff in a commercial enviroment at least on a large scale for at least another quarter maybe 6 months until we have tested, tested and tested again.

If they hadn't of released it everyone would have been perfectly happy with the now 'legacy' kit and going about just as normal, be thankful that you know a manufacturer that keeps on developing.

This is of course regardless of the fact Mike has already said the hardware cannot handle it, just look at how many clients you can put on the 'legacy' kit anyway, do you really think that more processes for the cpu will make things better?
In AP mode I would concur, however in client mode there is normally much less resource utilization on the client side. Some of the TDMA devices out there make the previous generation CPU's look like supercomputers in comparison.

[Headbang]

What makes Ubiquiti so great is the price. We all have legacy(current) networks that work great! I see the new stuff as something that can be used in addition to the current stuff. It never really makes financial sense to re-deploy anything. I still have dialup users that make us money.
For the cost of a bullet and an omni you can add the ability to gain more clients off existing infrastructure, this is good! Before the new options I was working on the plan for 8 45deg sectors just to cover 120 clients! Now I add 1 omni and can continue to subscribe to that tower. We have other options by other manufacturers, but price always wins when it comes to growth and cpe's.

[Belkid]

For me the only conclusion of all this is that the M product line is limited to point-to-point application and never AP to client...

I guess it's now clear for everyone ...

[davey]

For me the only conclusion of all this is that the M product line is limited to point-to-point application and never AP to client...

I guess it's now clear for everyone ...

I don't agree with you.

Of course, time will tell how it will perform PTMP.

[masked]

If it works, don't mess with it

Simple as.

We have invested a lot of money just like everyone else but we aint gonna change anything and if you have the money to change it - go ahead and change it! If not you dont have that option.

As ive said before I wouldnt even think of deploying this stuff in a commercial enviroment at least on a large scale for at least another quarter maybe 6 months until we have tested, tested and tested again.

If they hadn't of released it everyone would have been perfectly happy with the now 'legacy' kit and going about just as normal, be thankful that you know a manufacturer that keeps on developing.

This is of course regardless of the fact Mike has already said the hardware cannot handle it, just look at how many clients you can put on the 'legacy' kit anyway, do you really think that more processes for the cpu will make things better?
In AP mode I would concur, however in client mode there is normally much less resource utilization on the client side. Some of the TDMA devices out there make the previous generation CPU's look like supercomputers in comparison.

Look at SkyPilot's client software for the Bullet and Nano's, it practically cuts the throughput in half. As a matter of fact achieving FULL data rates (not air rates) through the 180MHz CPU with standard AirOS still chokes out at less that what it would with a 400MHz CPU in G or A mode. Again look at the Motorola Canopy, it can only do even less again.

[lukic]

Hi,

can anyone confirm, that new Bullet5M and Nanostation5M works with "old" Mikrotik AP's? We have hardly upgraded our network (more than 70 sites) to new 6x60 or 3x120 sectors in 802.11a using Mikrotik AP's. As CPE we are using with pleasure Nanostation5 (after 3.3.2 AirOS they are now working OK). Now I have to make decision which model to order - i'm talking in hundreds of CPEs. Old Nanostation5 or new Nanostation5M? It will be good to meet trend and change all old devices to new ones, but I'm afraid of stability and compatibility with Mikrotik AP (just for some year, then we will replace them with MIMO AP).

With old Nano5 we have problems with virtual AP (pre 3.3.2 AirOS can't see all virtual AP's or takes long time to associate with AP when using WPA2). Then - we have Litestation SR71 and SR71-A to test on one 10km long bridge link - but on load it stops transmitting data (i can get on web and see association) every 2 hours and we are waiting half of year to get new firmware. Mike still wrote that they are working on it, but nothings happen - so it's quite disappointing.

[masked]

should work fine in "legacy" mode(s).

[rconaway]

For me the only conclusion of all this is that the M product line is limited to point-to-point application and never AP to client...

I guess it's now clear for everyone ...

That is just a silly statement with no basis in fact. The M product line was planned for PTMP from the ground up with polling being in the first version of firmware. The originally product line was standard 802.11 a/b/g.

As for running additional software, I can tell you that the 180MHz processor is taxed at 25Mbps. We see it maxing out at 33Mbps where SMTP won't even respond. Yes, it can run synchromesh at a maximum of 13.5Mbps but realistically about 8Mbps. If that is what you want, not problem. Call SkyPilot, order the $6000 Gateway and $100 per NS radio on top of the cost of the NS2 and go to town. It's great firmware, I agree, but you pay for it and it's slower. SkyPilot has an application in SCADA and long range mesh designs and the firmware is rock solid (yes, there was some bugs in a previous version but it's cleared up).

As for legacy compatibility, again a silly argument. The entire industry ratified (or is about to ratify) a whole new specification. Technically the M is completely compatible. You get a 400MHz Bullet HP basically at the same price. I can't see anything wrong with that. Ubiquiti doubled the processor power and made a compatible radio and you whine about it?

However, if you want the new features that everyone on the planet asked for, 802.11N, you buy new radios. As Justin said, try running Windows Vista on your 25MHz 386 computer with 64MB of Ram. Just because Ubiquiti added in some of the features that make the product incompatible in polling mode (and I hope other features really soon), that just means you aren't compatible with other N products.

What you have is what you have. Either start planning for migration or stay with it. There isn't a product in Motorola's product line that is compatible with the previous generation. Ubiquiti went far beyond that and the complaining doesn't stop. If you don't have product obsolecense and churn in your business plan, then I suggest you research what that means.

[Belkid]

That is just a silly statement with no basis in fact. The M product line was planned for PTMP from the ground up with polling being in the first version of firmware. The originally product line was standard 802.11 a/b/g.

What other conclusion can you make when you read this ...
Honestly ...?

It seems the compelling reason for the legacy compatibly questions is people really, really want to incorporate AirMax into an existing network.

* Adding 802.11b/g will pull down 802.11n performance.

* Adding AirMax simply won't work with non-AirMax 802.11(whatever) products.

I'd like to hear what you understand ...

[lukic]

should work fine in "legacy" mode(s).

I know it should work fine, but i'm asking if someone did try it in real environment and confirm that they WORK, because "should" and "do" are two different things - even similar..

[rconaway]

Belkid, you definitely read that differently than I read that. Reread what I wrote. WHT is telling you that same thing.

Just because the new product supports 802.11a/b/g, it's no different than throwing b clients on a g radio. It slows it down.

[WHT]

Let's recap this one more time and close this thread.

** Using non-AirMax products with an AirMax AP will not get you AirMax features.

** Adding AirMax CPEs to an existing non-AirMax AP will not get you AirMax features.

** Adding non-AirMax CPEs to an existing AirMax AP will prevent the AirMax CPEs from using AirMax features.

** To get full AirMax performance, all radios have to be AirMax products.

** AirMax is not compatible with AirOS 3.x or any other manufactures' products or OS.

** Non-AirMax UBNT products and other manufactures' products cannot be upgraded to an AirMax product.

** AirMAx products will "support" non-AirMax products *only* to the extent of traditional 802.11a/b/g performance.

** AirMax is a new technology that outperforms older technologies. Stop complaining that UBNT didn't develop this sooner. Technology moves forward and to keep it fully compatible with older products defeats the purpose. Its no different when 802.11g made 802.11b "obsolete".

** If you are on the cusp of deploying a new network and feel AirMax is not mature enough, then either wait a few months or deploy with what you already have and feel comfortable with.