Significant improvement for 60 GHz solutions

Announcements
1

We have made a significant improvement for 60 GHz wireless (Wireless Wire and wAP 60G) configurations in the latest 6.42rc version release - increased supported distance for wAP 60G to 200+ meters.

Those of you who are willing to test rc versions on your test network, please upgrade to the latest version, test the performance and report to support@mikrotik.com with the results. Your effort and feedback will be highly appreciated.

Please note that rc versions are released strictly for testing purposes and should not be used on crucial network devices.

2

Could you guys be a bit more specific as to what we are looking for?

Do you mean you can maintain lower mcs rates at higher distance or are you saying we should get full gig at 200+ meters?

What exactly are we looking for here? Also, ptp or ptmp?

3

I join the question, what exactly are we looking for? Stability at distances +200m on wAPs or a better signal?

4

I have tried with my 20 - 30 m short link.

With 6.43rc49 I see it hitting MCS 10. With the previous versions the maximum it reached was MCS8.

5

In simple words, you can get ~900Mbits not only at 100 meters, but now even at 200 meters.

6

But we are curious souls who would like to Know some details! :wink:

Now seriously, I have spammed support with some tests I have done in my link, which is a short one. Stability has gone down with rc49. With rc30 it was rock
solid, as it is with 6.41.3.

The changes I noticed are, higher TX power? (Assuming tx-sector is an indication of TX power)

7

350m how can i get ?

8

I installed rc49 on a few of our >100m links (PtP and PtMP) and neither MCS or Signal Quality have changed. Throughput seems better, though, as running a traffic generator over our longest link (160m?) nets a solid 500Mbps full-duplex with little fluctuation. Used to be all over the place. Seeing a lot more link downs, too, but that might be due to rain we’ve been having. Should we be seeing better MCS and/or Quality readings? What exactly is being improved?

9

Calibration data for beamforming patterns.

10

Just a heads up, I had an issue with 6.42rc56 on a multipoint (ap-bridge) AP. Interfaces weren’t showing up and the station wasn’t connecting. I switched to bridge mode and everything worked again. Really digging the rssi and tx-sector-info, but I don’t think it’s ready for ap-bridge mode yet.

11

The perfect product for the 60Ghz, would be a point-to-multipoint solution, clearly with high gain CPE antennas for distances up to max 1km.
Possibility to connect up to 50/60 customers on a single cell
Channels smaller than the 2000Mhz (1000Mhz or 500Mhz)
TxPower increased to 20dB
A integrated failover 5ghz radio could be failover when primary 60Ghz fail due to rain

With this solution provider wisp can delivery 100/200/500 Mbps to customers and fight vdsl fttc/ftth of cable isp

12

Lupin you are right I think we need a solutions like ignitenet with 5 ghz backup to have a killer product to use in PtMP scenario to max 700m I hope to see it soon it’s not an hard job make it

13

Confirmed. The interface hangs if I set the mode to ap-bridge.

14

Totally agreed.

15

We are currently working on fixing this, fixes will be included in upcoming versions.

16

I hoped to see something like that at mum, but nothing

17

I’m kinda keen to see some more helpful SNMP OIDs soon - as it would be really useful to see how the link behaves in bad weather. e.g. coding scheme, and RX and Tx sig strength?

18

I would be pleased to have on option in the Wireless60G to

  • run a script (like netwatch)
  • or disable/enable the bridge port status depending on Signal (or CCQ in future)

This would be useful to switch to backup before link quality goes down to loosing packets.

19

You can do it that now just run script in scheduler read RSSI or signal and disable or enable port in bridge or whatever you wont it is possible now with script run in scheduler.

20

yes, i know, i can run a scheduler.
however generally in wireless would be a nice option to offer a (netwatch alike) option to run script in case of

  • signal (or ccq) is decreasing and reached X value (disable in bridge or dyn.routing)
  • signal (or ccq) is increasing and reached Y value (enable in brdige or dyn.routing)

Would be nice even with general wireless package.