Turbocharge Your Ubiquiti RocketM5 PtP Links in 4 Steps

Pretty much every WISP I know of has at least one Ubiquiti RocketM5 link using the RD-5G30  2' parabolic dishes. These links work well for medium range, medium capacity, point to point (PtP) links. They're cheap, they're easy to setup, and they perform pretty well for the cost. I put them up when I need 50mbps or less of bandwidth, and the site doesn't use enough bandwidth to warrant a licensed link. I also sometimes put them up as an inexpensive backup/secondary link at a site.

When Cambium came out with their ePMP line, which introduced low cost radios capable of GPS synchronization, we started thinking... what if we simply swapped out the radios on one of our many RocketM5 PtP links and see what the performance was like? Both types of radios use the same RP-SMA connectors and are similar in size and form factor. What if we could convert some of these links to use back-to-back frequency reuse? We have some sites that have 4 WISP's operating on them, and pretty much every 5GHz frequency has been used for PtP and PtMP use. The idea of possibly improving PtP performance while freeing up channels that our PtP's were using for PtMP use was too good an opportunity to pass up.

After performing this upgrade a number of times and experiencing great success with each one, we decided to share our experiences with the community to make the transition smoother for those of you who wish to perform this upgrade.

Step 1: Pick a Link

Find an existing RocketM5 PtP link on your network, ideally a shorter, non-mission critical site OR a site where you have a backup link that you can temporarily route traffic through until you get the hang of setting up ePMP and optimizing these new links. You’ll want to copy down all the settings or make a backup of the RocketM5 AP side of the link. You should also do some bandwidth tests across the existing RocketM5 link to give you a reference point to compare after you convert to ePMP. For bandwidth tests, you can do this pretty easily if you use Mikrotik routers at each site, or you can have your field techs use iperf, and lastly, Ubiquiti has a built in speed test you can run between radios.

Step 2: Radio Configuration and Lab Testing

In your lab, configure an ePMP GPS sync radio with the exact same settings as the RocketM5 AP. Configure an ePMP connectorized radio to be a client and to connect to the new ePMP GPS AP. Make sure that you can pass traffic between the two ePMP radios. You’ll now want to load the config file that you backed up onto a test RocketM5 radio. Turn OFF Airmax mode on the test RocketM5 AP. Turn ON WiFi compatibility mode (featured in firmware release 2.3) on the newly configured ePMP client radio. Make sure that the ePMP client radio can connect to the test RocketM5 AP and you can pass traffic. If you want to further minimize downtime during the transition, lock the SM to the exact channel width and center channel of the AP so it will register immediately on power up. Keep in mind you’ll want to undo the locked channel after you deploy in order to deal with DFS triggering alternate channel use or if you plan on doing further link channel optimization after the link is deployed.

Step 3: Game Day

Have your field crew go to the remote/client side of the RocketM5 link. If you’re using RF Armor shield kits on your dishes, you’ll want to make sure your tower crew has tin snips or other capable metal cutting hand tools. If you’re using brand new RF Armor shield kits that slide in place, you might not have to cut anything. Take the radio shield enclosure off of the back of the rocketdish and take your newly configured ePMP client radio and size it up against the shield enclosure. You’ll see where you need to cut on the bottom of the RF Armor radio box to make the ePMP radio fit.

Next up, have your ground crew or office staff disable ‘Airmax’ on the RocketM5 AP side of the link. Go ahead and swap the RocketM5 for the ePMP and make sure you coordinate with your ground crew to make sure that the power supplies are swapped before plugging in the ePMP. Remember, Ubiquiti and Cambium do not use the same voltages or pin outs on their PoE!!! If all is configured properly that link should come up very quickly and be able to pass traffic. If the ePMP client isn’t linking up OR if traffic isn’t passing, you’ll need to quickly do some troubleshooting OR you can simply plug the old RocketM5 client back in (remember to swap PoE’s again!!!) and try to do more troubleshooting on the ground or in the lab.

Assuming that it does link up and you can pass traffic, go ahead and put the modified RF Armor radio box back on the dish. You're done with the client side. Move on to the AP side of the link. Pretty much the same deal applies to this side of the link. Remove box, modify it, and get ready to plug the newly configured ePMP GPS AP radio in. This time you’ll want to login to the remote/client side of the ePMP link, and disable/turn-off the WiFi compatibility mode and reboot the radio. Once you’ve applied this, quickly put the ePMP GPS AP radio into place, again, making sure you use the proper PoE. Assuming everything has been configured and tested properly, it should just link up. If it doesn’t link up, then this one may be more difficult to fix as you may have locked yourself out of the remote/client side. Try putting the old RocketM5 AP back in place (reminder swap PoE’s!) and see if the link comes back. Check to see if the WiFi compatibility mode is still checked. If it’s still enabled, try to disable it again, reboot the ePMP client radio. Plug the ePMP GPS AP radio back in place and see if it links up. If you’re still having issues, then maybe further lab testing and a complete in lab link upgrade needs to be done as there is a bug or something that is being overlooked.

Step 4: Post Upgrade Benchmarking and Optimization

At this point the new ePMP link should be up and running. You can then start doing some link evaluations. You can either use the built in bandwidth testing tool, which provides pretty accurate results, or again, you can use iperf or the Mikrotik bandwidth testing tools. Once you’ve gathered some data, you can compare before and after what your link’s performance is. Again, assuming that you’re using the same channel, channel width, and power output as your old RocketM5 link, you should see a performance increase. To see further performance increases, try using the built in spectrum analyzer OR the automatic channel selection (ACS) feature to help find another channel. I probably wouldn’t leave ACS enabled… but it can be a quick and dirty tool to find out what’s available. Keep in mind that ACS will automatically change the power output on the AP based on what portion of the 5GHz band that it chooses.

In Closing - Our experience

Using the above mentioned methods we’ve upgraded three links so far, an 11 mile, a 9 mile and a 7 mile link. All three links have seen a noticeable performance improvement. For example, on the 7 mile link, we were experiencing noise from another WISP’s RocketM5 PtMP radio operating on the same channel at the remote site. This noise was being seen by the ePMP AP @ -77dBm and by the ePMP client @ -68dBm. Due to this noise, the prior RocketM5 link would have difficulty pushing 30mbps aggregate. After the ePMP upgrade, we now get around 70mbps aggregate. That’s a 133% increase over the old RocketM5 link.

All three of these links connect to one central site. This central site has 4 WISP’s operating on it and pretty much all of the 5GHz band (UNII-1, 2 and 3) is being used. There are so many 5GHz channels being used that the tower owners have a spreadsheet that all the operators work from and we all have assigned/fixed 20MHz channel slots on this site. No new channel slots are being added/allowed on this site. The only way to grow on this site is by frequency reuse. The 7 mile and the 9 mile links are back to back (one site is directly east and the other site is directly west of the central site) we thought that these two links would be an ideal for back to back frequency reuse.

Frequency reuse on a shared site is tricky because you might find a channel that works really well in one direction for one link, but due to interference, won’t work well in the other direction. It will take some testing and evaluation to figure out what channel will work optimally for both links. My suggestion is to look at the existing traffic on each link, and find a channel that works optimally for the higher priority or higher traffic link.

Using this method we were able to successfully find a channel in our channel plan for that site that allowed the 7 mile and 9 mile links to be configured using back to back frequency reuse. On the higher bandwidth/higher priority side, we have it configured to use a channel that works best for it. We get 93mbps aggregate on the high priority link, and on the other link, we get 52mbps aggregate. Both links provide about 30% more bandwidth than we currently need, so we have some breathing room to save some money for a pair of PTP650’s or a licensed PTP820 11GHz link in the near future. Lastly, we’ve now freed up one, very valuable, 20MHz channel slot which we can now use for one or possibly two PtMP sectors in the future.

Picture Gallery

Here's a picture of the three PtP links we've outlined above:

Here's a screen shot of a spectrum scan on the central site. Even though this is only for 5560-5760, the rest of the 5GHz band looks similar:

Here's a list of some of the MAC addresses that eDetect found when scanning the entire 5GHz band at this site:

00:15:6D:E6:D7:BD (0015.6de6.d7bd Ubiquiti Networks Inc.)
5D:36:76:32:82:D1 (5d36.7632.82d1 UNKNOWN)
98:C6:6B:E6:D7:BD (98c6.6be6.d7bd UNKNOWN)
5D:3F:6D:E6:D7:BD (5d3f.6de6.d7bd UNKNOWN)
00:00:14:4E:00:00 (0000.144e.0000 NETRONIX)
B9:21:00:00:E2:A7 (b921.0000.e2a7 UNKNOWN)
00:15:6D:66:A9:BD (0015.6d66.a9bd Ubiquiti Networks Inc.)
1F:15:6D:E6:D7:BD (1f15.6de6.d7bd UNKNOWN)
1C:15:6D:E6:D7:BD (1c15.6de6.d7bd UNKNOWN)
00:15:5D:59:6C:36 (0015.5d59.6c36 Microsoft Corporation)
00:15:6D:9B:D3:BD (0015.6d9b.d3bd Ubiquiti Networks Inc.)
00:15:6D:2A:91:9F (0015.6d2a.919f Ubiquiti Networks Inc.)
00:15:6D:E6:D7:8D (0015.6de6.d78d Ubiquiti Networks Inc.)
01:15:6D:E6:D7:BD (0115.6de6.d7bd UNKNOWN)
CC:C3:A5:B4:12:B9 (ccc3.a5b4.12b9 UNKNOWN)
91:20:A1:09:CD:E4 (9120.a109.cde4 UNKNOWN)
00:53:6F:E6:D7:BD (0053.6fe6.d7bd UNKNOWN)
91:65:6D:E6:D7:BD (9165.6de6.d7bd UNKNOWN)
00:15:6D:AE:12:41 (0015.6dae.1241 Ubiquiti Networks Inc.)
00:15:C7:DE:EA:02 (0015.c7de.ea02 CISCO SYSTEMS, INC.)
15:A6:58:D4:90:BF (15a6.58d4.90bf UNKNOWN)
0D:06:6D:E6:D7:BD (0d06.6de6.d7bd UNKNOWN)

Here's a picture of a modified RF Armor box and an ePMP GPS radio inside. This is an early attempt, we've since gotten better at modifying the enclosure OR if you have newer RF Armor, you don't have to cut anything:

Here's a screen shot of eDetect running on the 7 mile PtP link experiencing interference from a Ubiquiti PtMP sector on the remote site:

eDetect small.jpg


Thanks Eric. This is a great tutorial.

Has anyone else tried Eric's solution to see if it works for you?