I added this tech article today. Check it out on our support site:
With so many options of NAT, Router, Bridged, etc., it can be overwhelming to create the correct architecture for your first Baicells LTE deployment the first time. To facilitate this for you, I created a Baicells LTE HowTo Knowledge Base article that outlines the best fit scenario for LTE deployments for WISPs. You can read the article HERE.
As someone that has organized and lead technical training for more than ten years, I can say I have been asked this question many times. The commonality is that most people are self-taught, and use certain products in the daily conduction of their jobs, and feel like formal training doesn’t have sufficient value to warrant the time off from work, or the expense associated with it. I would like to take a few moments today to outline what I believe the benefits of formal training are. This post is timely because we have just such an opportunity coming up in July at ISP Supplies, but more on that later.
No one likes to admit they are weak in any area, yet just like muscles, not using a skill every day leads to weakness. A training program allows you to strengthen those skills, that each employee needs, to improve and brings all employees to a higher level so they all have similar skills and knowledge. You get sharper, the network runs better and everyone benefits.
Consistency and Performance
Training programs are structured to present the greatest amount of information in the least amount of time. This means you get the opportunity to see all the features of a product, or system rather than just the ones you regularly use. In the process, students almost always learn a new or more efficient way to perform a function. This leads to consistency and repeatability which increases efficiency. Once again, things just work better.
Employees that are subjected to training opportunities perform at a higher level than those that have to seek out training on their own. This fact speaks for itself.
The value of attending a training even is not just the material, it is the chance to network with other professionals in your area of expertise and thereby create relationships that benefit you today and in the future.
I began the post with the words “just such an opportunity” and now I want to invite you to gain the benefit that only formal training can provide by attending our fun and educational Summertime Cookout With Cambium Networks There is more information and the opportunity register HERE. I hope you can make it!
We are excited about the latest product from Baicells, the Nova 436. We received our first shipment late last week and this new LTE Base Station has some really cool features, never before seen from Baicells and not at this price point. The Nova 436 is the first Baicells LTE product to deliver carrier aggregation, even across discontiguous channels. Carrier aggregation is used in LTE-Advanced in order to increase the bandwidth, and thereby increase the bitrate or throughput. This is critical for the upcoming CBRS bands, where “PAL” and “GAA” channels allocated by the SAS may not be contiguous.
Quick Facts: Max peak rate of the aggregated carriers is 224 Mbps DL. Fully featured, these ship with everything you need (except antenna and power cabling) which lets you rack up more savings and simplify ordering and delivery
The Baicells dual carrier base station has some significant advantages over the competition:
One Gig-E copper AND one Gig-E SFP Cage: In split sector mode, the Nova dual carrier base station has independent 20 MHz channels. This is 2x the capacity our main competition only splits with two 10 MHz carriers. Lower weight and less power draw than others, so it’s less expensive to build battery back up support. Better pricing and still no games. No feature restrictions, so you get what you pay for. And, of course, unlike our competition, our Novas come with GPS, modules, and everything needed all for one low price.
The New Nova 436 may also be used in “split sector” mode for maximum footprint and capacity in one package. And, unlike competitive products, each carrier can have as high as 20 MHz of independent channel width. In split sector, you utilize two of the bas station antenna connectors to serve one sector and the other two to serve a second sector. This is a great way to cover 360 degrees with one base station and without an omni. As your cell density increases, you can add a second base station and do carrier aggregation, and increase your total capacity tremendously. This allows operators to “grow into” LTE.
The Nova 436 is available now at ISP Supplies. We are a full service Baicells distributor, ready to serve your LTE needs.
HaloB is a feature that Baicells LTE introduced in February of 2018. Any Baicells eNodeB (eNB) can be purchased with or upgraded to HaloB through software feature activation. A HaloB eNB eliminates the transport layer between the Evolved Packet Core (EPC) and the eNB by embedding a “Lite EPC” directly on the eNB. Therefore, critical control plane signaling is kept local.
With HaloB installed, S1 (transport) failures are eliminated. This removes wireless PTP backhaul failures, fiber outages, or routing mistakes from causing customer service disruption. CloudCore is still available for OMC monitoring and upgrade functions, as well as the BOSS HSS functions. SIM card activation and bandwidth package assignment are still performed by the BOSS. Operators using the Baicells API for billing software integration will see no change. When a UE attempts to attach to a HaloB eNB, the HaloB contacts the BOSS to verify the IMSI is valid and active and collects the bandwidth packages. All information is downloaded to the HaloB memory bank. Once stored, the UE will remain attached indefinitely. In the event of an eNB or UE reboot, attachment only needs to check the local HaloB memory data for the UE to reattach.
SIM card IMSIs can attach to multiple HaloB eNBs, and each will store the SIM data for future attachments. In the event of a rare CloudCore outage, new installs may not be able to attach during the outage if the SIM data has never been downloaded from the BOSS before. This is not a mission-critical event in most cases and once the CloudCore connection is resumed, the HaloB eNB will collect the SIM data for the new install and commence attachment.
- Operators entering the world of fixed LTE wireless have a lower initial investment.
- The simplified structure means there is no need for professional design and maintenance.
- The self-configuration, plug-and-play deployment model means a shorter time-to-market (TTM) and faster return-on-investment (ROI).
- Operators can provide a Layer 2 environment for SMEs and LAN gaming.
- The eNBs and the core network functions are decoupled.
- The control plane is processed within HaloB; user equipment will always be online.
What does Halo B Cost?
Per eNodeB: BAICELLS-HALOB-1 $249.99
Per 10 eNodeB’s: BAICELLS-HALOB-10 $1999.99.
There’s a million ways to do this on the wiki and the web but none of them fit my particular application. Let me explain:
1. The weak point in my network was an AirFiber 24 upstream from the tower I am connected to wirelessly. This is the link that goes down in heavy rain causing an outage at our office to PROVIDER1. We have a backup connection through a second provider that is slower but being 5GHz doesn’t drop in the rain, PROVIDER2.
The network is like this:
2. Simple floating static routes with check gateway doesn’t help because on PROVIDER1 we never drop our 5GHz connection to the tower, it’s the upstream link that fails.
3. I tried recursive routes and it works but the failover was still lacking and seemed sporadic at best.
4. When failover did occur, the VOIP PBX would hold the connection open through the dead provider and some phones in the office wouldn’t work at all, rebooting the phone was the only solution. We tried a ton of solutions and never got it to work consistently.
The solution that works the best is as follows. I am using a combination of static routes, firewall rules and Netwatch scripts. Here it is:
The Netwatch script watches 126.96.36.199 (a public DNS server). If it goes down:
- It changes the distance on the default router to PROVIDER1 to 20 making it inactive. Now all traffic defaults through PROVIDER2.
- It emails me that the gateway has changed. Please not you must set up your email server IP, and any authentication in /tools e-mail first.
- It clears any connections to my VOIP gateway, thereby causing them to re-establish, interestingly calls do not drop!
- When pings return, it sets the distance on the default route through PROVIDER2 back to 1 making it the active route and then clears all connections to the VOIP gateway again.
/tool netwatch add comment=CheckCon down-script="/ip route set [find comment=\"\ PROVIDER1\"] distance=20\r\ \n/ip route set [find comment=\"PROVIDER2\"] disabled=no\r\ \n/tool e-mail send to=\"YourEmailAddress\" body=\ \"Connection with PROVIDER1 Lost, Switched to PROVIDER2\" \ subject=\ \"Lost connection with PROVIDER1\"\r\ \n/ ip firewall connection remove [find dst-address=\"\ YourVoipGatewayIP\"]" host=188.8.131.52 interval=5s timeout=2s \ up-script="/ip route set [find comment=\"PROVIDER1\"] distan\ ce=1\r\ \n/ip route set [find comment=\"PROVIDER2\"] disabled=no\r\ \n/tool e-mail send to=\"YourEmailAddress\" body=\ \"Connection with PROVIDER1 Regained, Switched back to PROV\ IDER1\" subject=\"Regained connection with PROVIDER1\"\r\ \n/ip firewall connection remove [find dst-address=\"\ YourVOIPGatewayIP\"]"
Next we need to ensure we can only ping our test host through the PROVIDER1 connection. This is done with a static route through PROVIDER1:
/ip route add comment="Force test pings through PROVIDER1" dst-address=184.108.40.206 / gateway=220.127.116.11
Next we need to comment our default routes.
/ip route add comment=PROVIDER1 distance=1 gateway=18.104.22.168 scope=\ 11 add comment=PROVIDER2 distance=10 gateway=22.214.171.124
Next we need to ensure that no pings to our test ip go through PROVIDER1 only:
/ip firewall filter add chain=output comment=/ "Drop pings to 126.96.36.199 if they go through PROVIDER2" \ dst-address=188.8.131.52out-interface=ether2 action=drop
As I write this it is pouring rain outside and I have observed it go down 3-4 times and even with people on the phone, calls continue and we haven’t lost the network. I am loving this!
The number one concern I have heard thus far before we transition a select group of WISPs (Wireless Internet Service Providers) from WiFI or TDMA to LTE is “How can I afford LTE?” and the question is valid. The costs are high, very high, astronomically high in fact when compared to the “disruptively priced” gear from others we have enjoyed and loved in the past. My response to the question “How can I afford Telrad Networks LTE?” is really another question and that is “How can I NOT afford Telrad LTE?”
Think about it this way. When I was a full time WISP operator, we kept careful stats on the number of calls for service versus the number of installs. I am not talking about tire kicker calls, I mean people that called, credit card in hand wanting to buy what we were selling. We found that we were only serving 20% of those qualified customers and losing 80%. Seriously, qualified customers, ready to read you their credit card number and close the deal today and agree to pay you every month, same day, same amount, and we had to tell them no 80% of the time? Why?
Well, I can tell you it was not because we had a line of sight problem, it was because our WiFI and TDMA unlicensed equipment had a line of sight problem. You see, what had happened is we accepted the shortcomings of the technology and began to believe LOS (line of sight) was the ONLY way.
Fortunately all that has changed and Telrad is leading the charge. All that remains is a path to take the same gear our competitors, the big cell carriers have relied upon to take our customers, equipment that doesn’t have a LOS problem, and “WISPatize” it. That is exactly what Telrad is doing.
We are WISPs and we know how to do what others won’t, or can’t or don’t understand and that is serve the unserved and underserved with the most cost effective, creative method we can.
So, as we evolve into the WISPatized LTE model, here’s another way to start small and transition into something huge. Think about it like this, when you make the switch to LTE, even starting small and begin to crush your competitor’s LOS solution, you will take his customers and the revenue increase will fund the transition of the remainder of your LOS network to NLOS.
In that vein, here’s a solution to get you started small at first and the best part is it doesn’t involve an omini! It allows nearly 360 degree coverage day one with only one base station radio and two sectors. Understand it has some shortcomings:
- It is not 100% true 360 degree coverage, after all we are using two 65 degree sectors that provide up to 120 degrees of coverage, not 180 degrees. There will be two pie shaped gaps, but those will get filled soon enough. Be smart, position those gaps facing an uninhabited prairie or forest.
- This solution is not without signal loss. Splitting the 4×4 MIMO into two 2×2 MIMO sectors will cost you 3 dB of signal. That’s a lot, I get that. Remember the rule of 3’s in RF theory? Every 3 dB doubles your power, remove 3dB and halve your power.
The advantage here is that day one, one base station, two antennas and you have great close-in coverage with antennas you will reuse for Phase II.
One base station, two sectors, 2×2 MIMO
Phase II is to add a second BST and increase your range incrementally and fill the entire 360 degree area with no more gaps.
Two base stations, four sectors, 2×2 MIMO
Phase III is to add one or two more BST’s. With 3 BST’s you are now full 4x MIMO, get back your lost 3 dB, increase your range and increase your density.
Four base stations, four sectors, 4×4 MIMO
With 4 BST’s you will be able to increase your number of subs on this single tower to something approaching 400 depending on your bandwidth packages.
It’s not a perfect plan but it will work and that’s what WISPs do, make it work. I hope this helps increase your knowledge and gets the creative juices flowing to transform your WISP into the next generation.
Good question, one I was also asking myself when I set up a large Mikrotik CAPsMAN network. A moving laptop would hang onto a -85 signal when a -70 was available. It did not make sense. So, after some research I found some ideas to help you.
When you are walking between access points (assuming they have the same wireless SSID name and same security), you may find that your wireless client, that is your laptop like a mobile phone is still sticking to the distant device and will not roam to the nearest device.
How roaming works:
Roaming is purely a client decision. The wireless client is responsible for deciding it needs to roam, and then detecting, evaluating, and roaming to an alternative AP. WLAN standards bodies (such as IEEE) and industry bodies (such as Wi-Fi Alliance) do not specify when a client should roam, or how the client roams.
So, roaming or not roaming, it is totally decided by your wireless client’s roaming algorithm. Different wireless client vendors’ roaming algorithms are also different and are not generally published.
There is no role played by AP in this client roaming process. So, your best option is to configure your wireless client to achieve fast roaming for you. Some NIC vendors give some mechanism to control this roaming behavior, specifically Intel.
In Intel, it is known as roaming aggressiveness and this setting allows you to define how aggressively your Wi-Fi client roams to improve wireless connection.
Here are the configuration methods on Intel WNIC:
You can go to control panel -> network and internet -> network connection and choose the wireless connection. Right click the wireless connection and choose properties. Click configure and choose Advanced and choose roaming aggressiveness. Typically there are 5 options. Here are the explanations of these five options:
Lowest: Your wireless client will not roam. Only significant link quality degradation causes it to roam to another access point.
- Medium-Low/Medium-High: Allow Roaming.
- Medium: Balanced setting between not roaming and performance.
- Highest: Your Wi-Fi client continuously tracks the link quality. If any degradation occurs, it tries to find and roam to a better access point.
It is still possible on the Mac, just not as elegant. Open a terminal window and type the following command all on one line then Enter. You will need the administrator password of course since this has to run as the root user:
sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/A/Resources/airport prefs joinMode=Strongest
This is a letter from Patrick Leary at Telrad, I thought worth sharing.
We all know LTE has first been created for the needs of giant mobile operators first. That means the LTE enhanced packet core (called the EPC in LTE-speak) includes a host of features fixed operators may NEVER need, like translating diverse 3G backends into a standardized LTE core. Who wants to pay for that? Not me and certainly not you. As well, being mobile centric first, LTE out of the box EXCLUDES certain things fixed operators like and use, such as Layer 2 services.
Being the first and so far ONLY company out there in the LTE space mainly focused on the fixed space, Telrad is the tip of the spear trying to innovate and idealize the solution for WISPs and other local and regional fixed-focused operators. It has been a struggle. EPC are things that can run deep into 6 figures and we had to find a way for the economics to make sense for your models.
Complicating this, because we use an SDR platform, Telrad is able to do something no other vendor on the planet has done: offer the EPC as a hardware-less, software feature EMBEDDED into each base station as an option. That’s super cool, meaning smaller operators won’t need to shell out for a full centralized EPC. But, that also means we’ve made our lives more difficult because options are another SKU to manage.
We now think we’ve got it as refined as possible and here’s the key to what we’ve done:
Dividing up the EPC functionality to allow for operators to purchase ONLY the features you need, and allowing that granularity to be applied to EITHER the embedded or the centralized EPC models.
So what’s been made granular (and priced much smaller per function)? These are things that in the traditional LTE world are often found as individual appliances. Our centralized core can include them all in one appliance for 1/10th or less of what traditional EPCs can cost. Now we’ve even made it MUCH more affordable than even that, by taking the subsets of EPC functionality and providing them as distinct SOFT modules that can be purchased ala carte into either the embedded or centralized Telrad EPCs. Here are examples:
– Don’t want AAA or need Radius? Fine. We now have a feature called iHSS, which allows MAC level authentication.
– Want to use your Radius, but NOT use our implementation? Don’t get iHSS. Instead get the IWK module, which enables internetworking with an external Radius AAA server.
– Planning ONLY to do best effort or apply a single policy across all subscribers? Fine, no need to have the PCRF functionality of an EPC.
– Want to implement distinct and varied service flows and other QoS services? We’ll offer iPCRF as a module.
These are examples. If you used all the functionality, it would still not cost you any more than how things were first initially priced, even if purchased in pieces, so there is no nickel and diming. The difference is, if you need LESS, you’ll be investing less.
Those of you with firm LTE quotes on the table? We’ll need to revisit them, as the numbers will drop. Those with only estimates at this point? That’s worst case and we’ll get you revisions as you get nearer to pulling the trigger.
One last thing….and it is another big one. With LTE comes the entirely new NMS. Better, lighter, simpler, less cost. I’ll be doing another mail on that as soon as I can.
Java Home Directory Fail Issue on Ubuntu – RESOLVED
For those of you who’re building your Ubuntu from scratch or even if you did like me and install UniFi on an AirVision NVR, , you might or might not get this after installing UniFi Controller
*Setting Java Home….fail
If that do happen, this might be because since the new Ubuntu, the name of the Java homedir changed according to the CPU architecture used and UniFi is using a hard-coded variable for the Java path in its startup script for some reason. You should change the homedir by editing the init script. (We won’t get into much detail about what is init)
1. Open the init script
sudo nano /etc/init.d/unifi
2. Scroll down with your arrow key, look for a variable called
3. Add your instance architecture type after that string.
For example, I’m using amd64bit in my instance, the string should become
DO NOT touch anything else.
4. After the edit just enter Ctrl-X and it will ask you wheter it should save or discard the change. We of course want to save it. Press Y, and press ENTER to save it with the same file name. The nano editor will close
5. Do this string to restart our UniFi Controller.
sudo service unifi restart
6. You suceed when you see
* Starting Ubiquiti UniFi Controller unifi [ OK ]