This content is for Patreon subscribers of the j2 blog. Please consider becoming a Patreon subscriber for as little as $1 a month. This helps to provide higher quality content, more podcasts, and other goodies on this blog.
We recently headed up a job for a client of installing some RF elements horns, Cambium ePMP, and Baicells LTE for a client. One of the gems of this job was the frame the client designed for the job. We can’t take credit for this. We just think it’s cool. Some of these pictures were taken during construction, thus post clean-up.
The frame is truly an example of how WISPs are stepping up their installs to become more standardized and carrier-grade. It costs some money but is worth it in the end.
Synchronization source– Synchronization mode supports two types of timing sources: the timing signal provided by a Cambium Network’s Cluster Management Module (CMM) or by the AP’s own on-board GPS receiver. Both these sources require GPS Synchronization capable AP hardware and will allow APs to receive a stable timing signal to synchronize their own Tx/Rx cycles.
There is a third option for the Synchronization source, namely “internal”. This “Internal” Synchronization source option is NOT an actual synchronized timing source and when selected, it just provides timing from an internal unsynchronized source. “Internal” is NOT to be used in GPS Synchronized deployments but could be used with single PMP AP installations. The “Internal” timing source is also used when the Flexible DL/UL ratio option is selected.
Please note the following for e3K compatibility. We do not recommend or support running a mix of 3.X AND 4.X on the same sector. All APs/SMs should either be running on 3.X release or 4.X release but not mixed for commercial deployment. Standard upgrade path should still be followed,
For those of you not in the Beta program Cambium has broken tradition and widely announced a new RC for ePMP on some of the Facebook forums. For those of you running ePMP, this is a significant upgrade for just an RC. Some highlights for me in the changelogs.
Keep in mind 4.4 is a point upgrade. For those of you who don’t know you have Major Versions (ie 4.x), Minor (4.4) and Patches (4.3.2 and hotfixes (22.214.171.124). On top of these numberings, you have different builds Alpha, Beta, Release Candidate (RC), and others depending on the vendor. I expect an RC to have a higher build number by the time it is released to even Beta testers. This means the internal team and their test networks have gone through some pretty solid feedback loops. So on to why 4.4 is an important thing, especially to ePMP users. 4.4 is a minor release with significant improvements.
•QoS ePMP3000 now supports Quality of Service to support traffic prioritization. This is the first phase of QOS implementation supporting traffic prioritization at the individual SM/AP. Future additions will cover features such as station priority.
•ePMP3000 now supports maximum information rate further allowing the operator to manage traffic profiles for end customers.
•This release now supports trial configuration that allows a user to try a configuration change without applying the configuration.
•This release now supports cnMaestro Zero-Touch.
So let’s talk about each of these.
QOS. This is where we can get into some debate. How much QOS should you be doing at the Subscriber module? How much of it should be handed off to an ISP managed router? I am under the philosophy an SM should be doing as little overhead of non-radio things as it can. If you want to do QOS do a very basic QOS set, if at all. If you do not do managed routers, then you almost have to do QOS at the radio. Same goes for the traffic profiles. This is something you must decide for your self. I have my philosophies and gladly share them. What works for me may not fit with your methods.
Trial Configuration. This has been a feature of UBNT that has been super awesome. You can apply your settings and if you lock yourself out you just have to wait until the settings are reverted. I have not tried this yet, but it is an exciting thing.
Zero-Touch. This has been a long time coming. This reinforces the cnMaestro ecosystem this much further. At one point you will have enough automation setup where a new AP that comes online will have all of its settings pushed down to it without you ever having to log in to the device.
Bugs Addressed in 4.4.0-RC23
•FC ACG-5846 [FC] F300-25 could not connect to e2K in first attempt. Cause – INA RETRIES EXHAUSTED
•[F130] enable IPv6
•Downlink Frame Utilization always shows 0%
•[MIR] MIR Profile Rules does not work
Known Issues in 4.4.0-RC23
•[FC] SMs are disconnected from AP with Reason: 48 (COMMUNICATION LOST) when traffic is transmitted
•PPPoE MTU size limits should depend from Ethernet MTU
What are some of my tips for getting the most out of your ePMP deployment (or any vendors deployment)?
If you are running 3k don’t run mixed mode in production just yet unless you are prepared to submit tickets and bug reports. Also, 3k users run the latest beta firmware. Signup for the beta and READ the changelogs. One of the things on a recent thread on the Facebook Cambium Users group was some users being vocal about a small number of things fixed. If they read the changelog you would see a lot more was mentioned.
A good rule of thumb is your APs and SMs should be the same firmware version. Not everyone in your whole network has to be the same. You can have one tower or sector on version 4.4.0-RC23 and another sector on 126.96.36.199. The key is each SM attached to an AP should be the same version as the AP. Once you start mixing weird results can happen.
Read the changelogs. In the current changelog for 4.4.0-RC23 I count 47 bug fixes and 14 known issues, some of the highlights I mentioned above. With a point upgrade like this, I would expect some major improvements and lots of them. I always like to mention highlights in my posts like this because it helps those of you who are busy to pick out some significant things which may interest you. There may be some I don’t mention which are essential as well. You should have someone on your team who reads the changelogs. Reading changelogs can save you much heartache, especially when it comes to known issues. One of the things I like about the Cambium changelogs is they mention the tracking number. If you have opened up a case and it is a verified bug you will receive a tracking number. This tracking number allows you to keep the vendor accountable. If you don’t see this in your other vendors, push them to do this. The vendor may already be doing this internally. Most software devs have ways to track their bugs internally. Push them to publish known and fixed issues, with tracking numbers in their changelogs.
Some of the issues in changelogs may never affect you and may be nitpicky things. A good vendor will not “pad” their changelogs with fluff like “changed a spelling error here”. These are fairly insignificant and just add to the reason why some users ignore changelogs.
How has this helped me in the real world? Knowing what was fixed in a changelog allows me to decide if this is a software version which needs to be rolled out. Do the pros outweigh the cons? Is this a bleeding edge platform where I need to be running the latest in order to get the best benefit? You will find the new kid on the block is the one who gets the most development time. The platform needs to reach a certain level of maturity as fast as it can. If you have these in production or are testing then running the latest code is the way to go. As the platform becomes more mature, running the bleeding edge code isn’t as desirable. You reach a point where you can wait longer between software upgrades.
I have always been of the philosophy where my devices are doing as little as they possibly can. What do I mean by this? I have dedicated functions to devices in the network. My Access Points are not doing firewalling, QoS, and other things. If they are it is at a very basic level. I want each device to excel at its function. This leaves more horsepower to do its core function(s). It also lessens bugs and conflicts between software processes. This is where many of the bugs show up. If your device is doing 4 things, then you have times the problem than if it’s doing just one thing. However, this is the real world and you have to stretch your budget as far as you can. Just be aware of adding more functions to a device can cause compatibility issues. Keep It Simple Stupid (KISS). Network design and philosophy play a huge role in how a device behaves.
By combining all of the above you can work out an internal philosophy which allows you to tailor it to your business needs. If you are running the latest hardware platform in production for whatever reason then have it do dedicated functions until the software is mature. This will lessen the impact of bugs. As the product matures you can turn on more functions. Turns the dials and knobs as some would say. If you are just testing it then turn it all on and try and make it break. But submit tickets to the vendor. This may seem like you are doing “their job” but this is part of the investment in the platform.
While this article started out being about Cambium, you can apply the philosophies to any vendor you want to put in your network.
Get training and certification on Cambium ePMP, cnPilot, and other cambium products.
Cambium talks about using the spectrum analyzer
ePMP GPS Sync Radio devices that have an onboard GPS contain two banks of flash memory which each contain a version of software.
The version of software last installed onto the device flash memory (using software upgrade procedures) is configured in the Active Bank. This software will be used by the device when the device is rebooted.
Just a quick video on doing a manual upgrade of ePMP firmware. Both a GPS radio and a NON GPS radio. Nothing fancy.