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.
Founded by two telecommunications veterans in 2018, Atheral is building customer-centric white- label and wholesale cloud solutions for Internet Service Providers that decrease end-user churn and increase profitability while being geo-redundant, highly available, and scalable. We focus on redefining technology in the cloud to minimize capital expenses while providing a predictable operating cost.
Atheral’s core white-label Voice over Internet Protocol (VoIP) platform is simple, flexible, and feature- rich with unique US-based support resources. Atheral is the only white-label VoIP wholesaler that focuses on WISPs while providing a customized branded experience for their end-users. Pricing, just like our platform, is feature-rich and straightforward:
- Unlimited local and long-distance calling in the United States, Mexico, and Canada
- One telephone number per user and e911 registration
- Branded customer-facing documentation
- 140+ Softswitch features
- Our companion Android and IOS softphone app
Why should a WISP care about VoIP?
- Government Funded Competition – Offering VoIP with your awesome broadband experience protects your ISP from being overbuilt by government-funded competitors or enables you to apply for government funding to expand your coverage area.
- Customer Stickiness – Customers that purchase value-added services are more likely to stay customers, especially when they are satisfied with those services.
- High Margin – While phone service in the home may be declining, VoIP is growing by leaps and bounds in the business community with the VoIP industry seeing ~21% annual growth through 2025. All those added users equal high margin for you – the average VoIP reseller sees margins in the 40%-65% range.
As the number of WISP LTE deployments increase, there are many things WISPs will need to be mindful of. One such item is properly supporting antenna cables. LTE systems are more sensitive to cable issues. In a previous blog post, I talked about pim and low-pim cables. One of the things that can cause low pim is improperly mated cables. If cables are not supported they can become loose over time. Vibration from equipment or even the wind can loosen connections.
How do we support cables?
We can take a cue from the cellular industry. The following are some examples of proper cable support. Thanks to Joshua Powell for these pics.
Where can you get these?
A good place to start are sites like sitepro1 or Tessco has a selection.
So the next time you are planning your LTE deployment think about cable support.
An older post but still relative. Figured I would re-post this.
Cambium and CTIconnecxt put on a webinar about ePMP 3000 today. This should be available online at one point. Look for it in the Cambium forums.
Some notes I took
-ePMP 3000 offers Simultaneous MIMO downlink transmission
-You will be able to use the beamsteering antenna with the 3000. Cambium is working on the software to make this work.
-3000 has a dedicated receiver chip. This allows you to run the spectrum analyzer in realtime. Also has “edetect on steroids” which shows more information than the current edetect.
-Sector is a 4X4 90 degree sector with beamforming. Achieves and extra 3db in the downlink.
Beamforming vs Beamsteering
Beamsteering is for dealing with interference.
Beamforming is for downlink gain.
-Cambium mentioned the concept of Azimuth Delta. This is groups of SMs in terms of how the AP talks to groups. The gave an example on a google earth plot. In a nutshell, when you have gain in one direction it takes advantage of the null in different directions. More to this, but that is for another post.
-“Sounding” -Sends a special packet and gets feedback from the subscriber. Determines how the phase shift works and other things.
-Elevated clients beta is coming to make the elevated clients work with the 3000.
I hope distributors work out a smaller cold shrink for the sma connectors on the ePMP Ap radios. Weatherproofing these properly will be an issue due to the close proximity of the connectors. I have not seen the connectors on a sector to see how those will be. This is where folks could take a page from the coldshring that comes with the Baicells gear or the cables with the integrated boot some distributors sell.
Network Time Protocol (NTP) is a service that can be used to synchronize time on network connected devices. Before we dive into what NTP is, we need to understand why we need accurate time.
The obvious thing is network devices need an accurate clock. Things like log files with the proper time stamp are important in troubleshooting. Accurate timing also helps with security prevention measures. Some attacks use vulnerabilities in time stamps to add in bad payloads or manipulate data. Some companies require accurate time stamps on files and transactions as well for compliance purposes.
So what are these Stratum levels I hear about?
NTP has several levels divided into stratum. All this is the distance from the reference clock source. A clock which relays UTC (Coordinated Universal Time) that has little to no delay (we are talking nanoseconds) are Stratum-0 servers. These are not used on the network. These are usually atomic and GPS clocks. A Stratum-0 server is connected to time servers or stratum-1 via GPS or a national time and frequency transmission. A Stratum 1 device is a very accurate device and is not connected to a Stratum-0 clock over a network. A Stratum-2 clock receives NTP packets from a Stratum-1 server, a Stratum-3 receives packets from a Stratum-2 server, and so on. It’s all relative of where the NTP is in relationship to Stratum-1 servers.
Why are there levels?
The further you get away from Stratum-0 the more delay there is. Things like jitter and network delays affect accuracy. Most of us network engineers are concerned with milliseconds (ms) of latency. Time servers are concerned with nanoseconds (ns). Even a server directly connected to a Stratum-0 reference will add 8-10 nanoseconds to UTC time.
My Mikrotik has an NTP server built in? Is that good enough?
This depends on what level of accuracy you want. Do you just need to make sure all of your routers have the same time? then synchronizing with an upstream time server is probably good enough. Having 5000 devices with the same time, AND not having to manually set them or keep them in sync manually is a huge deal.
Do you run a VOIP switch or need to be compliant when it comes to transactions on servers or need to be compliant with various things like Sox compliance you may need a more accurate time source.
What can I do for more accurate time?
Usually, a dedicated appliance is what many networks use. These are purpose built hardware that receives a signal from GPS. the more accurate you need the time, the more expensive it will become. Devices that need to be accurate to the nanosecond are usually more expensive than ones accurate to a microsecond.
If you google NTP Appliance you will get a bunch of results. If you want to setp up from what you are doing currently you can look into these links:
One of the problems installers run into on a few networks we manage is having the right tools to properly test a new install. Sure, an installer can run a test to speedtest.net to verify customers are getting their speed. Anyone who has done this long enough knows speedtest.net can be unreliable and produce inconsistent results. So, what then? Or what happens if you need to by-pass customer equipment easily? Most installers break out their laptop, spend a few minutes messing with settings and then authenticating themselves onto the network. Sometimes this can be easy, other times it can be challenging.
In steps the Mikrotik mAP.
What you are about to read is based on a MUM presentation by Lorenzo Busatti from http://routing.wireless.academy/ with my own spin on it. You can read his entire presentation on the mAP in PDF at : https://mum.mikrotik.com//presentations/US16/presentation_3371_1462179397.pdf . The meat of what we are talking about in this article starts on Page 50. If you want to watch the video you can do so at https://www.youtube.com/watch?v=VeZetH9uX_Y . The focus of this article starts around 21:00.
I have taken Lorenzo’s idea and have several different versions based upon the network. In most of our scenarios, the ethernet ports are what plug into the CPE or the customer’s equipment, and the technician connects to the mAP over wifi. This post covers using the mAP as an installer tool, not a traveling router. Lorenzo covers the travel option quite well in his presentation.
In this post, we focus on networks which use PPPoE. PPPoE networks usually are the ones who take much time to set up to diagnose. What we have done is set up an uncapped user profile that is available on every tower. Authentication can be done with local secrets or via radius. Depending on your IP design the user can get the same IP across the network, or have an IP that assigned to this user on each tower/routed segment. We could do an entire article on IP design.
On our Mikrotik, we setup ether1 to have a PPPoE client running on it. When the installer plugs this into the customers CPE the mAP will automatically “dial-out” and authenticate using the technician user we talked about earlier. Once this connection has is established, the mAP is set to turn on the red “PoE out” light on the mAP using the following code.
/system leds add interface=pppoe-out1 leds=user-led type=interface-status
Note. Our PPPoE interface is the default “pppoe-out1″ name. If you modify this, you will need to modify the led setup as well to match.
The red light gives the technician a visual indicator they have authenticated and should have internet. At the very least their mAP has authenticated with PPPoE. There are netwatch scripts mentioned in the above presentation which can kick on another LED indicating true internet reachability or other functions. In our case, we can assume if the unit authenticates with the tower, then internet to the tower is up. While this isn’t always the case if the Internet is down to the tower you quickly know or the NOC quickly knows. At least you hope so. We chose the PoE out led because we are not using POE on this setup and a red light is noticeable.
Once the technician has a connection they can connect to an SSID set aside for testing. In our case, we have set aside a “COMPANY_TECH” SSID. The tech connects to this on their laptop, and they are online. Since this is a static profile, you can set it up just like a typical customer, or you can give the tech user access to routers, APs or other devices. Our philosophy is you set up this SSID to mimic what a customer account experiences as closely as possible. It goes through the same firewall rules and ques just like a typical customer.
To further enhance our tool we can set up a VPN. This VPN can is accessible from the laptop with a second SSID named “COMPANY_VPN”. Once the technician switches over to this SSID they have access, over a preconfigured VPN on the mAP, to the network, from where they can access things customers can not, or at least should not be able to access. Many modern networks put APs, and infrastructure on separate VLANs not reachable from customer subnets. The VPN comes in handy here. You can access these things without changing security. If you plan on using this router internally, the type of VPN you choose is not as important as if you plan to modify the config so you can travel as is the case with the above MUM presentation. If you plan to travel an SSTP VPN is the most compatible. If it’s just inside your network, I would suggest an l2tp connection with IPsec.
Our third configuration on this is to set up the second ethernet port to be a DHCP client. This setup is handy for plugging into the customer router for testing or for places where DHCP is the method of access, for example, behind a Baicells UE. If your network does not use PPPoE, you could have one ethernet be a DHCP client, and the other be a DHCP server. We have found having the technicians connect wirelessly makes their lives easier. They can plug the unit in and not have to worry about cables being too short, or getting behind a desk several times to plug and unplug things.
So why go through all this trouble?
One of the first things you learn in troubleshooting is to eliminate as many variables as you can. By plugging this into your CPE, you have a known baseline to do testing. You eliminate things such as customer routers, customer PCs, and premise wiring. The mAP is plugged directly in CPE, whether it be wired or wireless. Experience has shown us many of the troubles customers experience are traced back to their router. Even if you provide the router, this can eliminate or point to that router as being a source of the problem if a technician needs to visit the customer.
Secondly, the mAP allows us to see and do more than your typical router. From the mAP we can run the Mikrotik bandwidth test tool from it to the closest router, to the next router inlines, all the way out to the internet. A while back I did an article titled “The Problem with Speedteststs“. This article explains many of the issues testing just using speedtest.net or other sites. Being able to do these kinds of tests is invaluable. If there are four Mikrotik routers between the customer and the edge of your network all four of them can be tested independently. If you have a known good host outside your network, such as the one we provide to our clients, then you can also test against that.
Having a Mikrotik test tool like this also allows you access to better logging and diagnostics. You can easily see if the ethernet is negotiating at 100 meg or a Gig. You can do wireless scans to see how noisy or busy 2.4GHZ is. You have easy to understand ping and traceroute tools. You also have a remote diagnostic tool which engineers can remote into easily to perform tests and capture readings.
Thirdly, the mAP allows the installer to establish a good known baseline at the time of install. You are not reliant on just a CPE to AP test, or a speedtest.net test.
How do we make this portable?
You may have noticed in my above pictures I have an external battery pack hooked up to my mAP. I am a fan of the Anker battery packs
Distributors such as ISP Supplies and CTIconnect have the mAP.
Finally, you will need a USB to MicroUSB cable
If you want you can add some double sided tape to hold the mAP to the battery pack for a neat package. I like the shorter cable referenced above in order to have a neat and manageable setup.
No matter what gear you use for delivering Internet to your customers, the mAP can be an invaluable troubleshooting tool for your field staff. I will be posting configs for Patreon and subscribers to download and configure their mAPs for this type of setup, as well as a road warrior setup. In the meantime, we do offer a setup service for $200, which includes the mAP, battery, USB cable and customized configuration for you.
If you are looking for a U.S. stocking distributor of ALG products check out ISP Supplies
The following are results from a series of tests of AGLcom’s parabolic dish antennas on an existing link that is 5.7 miles long. The link typically passes 80-90Mbs with a TX capacity of 140 Mbs and radios used are Ubiquiti AF5X operating at 5218 Mhz. A full PDF with better Readability can be downloaded here..
The tests were taken in stages:
- 1) The normal performance of the link was recorded.
- 2) The 2′ dish at one end, B, was replaced with the AGLcom, C, dish and the link reestablished.The link performance was recorded.
- 3) The 2′ dish at the other end, A, was replaced with the AGLcom, D, dish and the link reestablished. The link performance was recorded.
- 4) The setting on the AF5xs were adjusted to optimize the link performance with data recorded.
- 5) The 2′ dish, B was put back in the link and the performance was recorded.
- 6) The ACLcom C was put back into place.
The tables below do not follow the test order as the third line of data was actually the last test performed.
A-Jirous JRC-29EX MIMO
B-Jirous JRC-29EX MIMO C-AGLcom – PS-6100-30-06-DP D-AGLcom – PS-6100-29-06-DP-UHP
Table 1 is the signal strength results of the various dishes on the link. The first line, A-B, is the original Jirous to Jirous. A is the first two columns of the link and are the A side and the last two columns are the B side on the link. What is of interest is that exchanging B to C in the second line brought the signal deviation between the channels to only 1db and 0 db as seen in Table 2. The third line was a result of replacing the horn on the A dish and optimizing the setting on the AF5X radios. This changed the signal by around 7db and improved the link capacity, Table 3. Clearly, the A dish had a problem with the original horn.
In the fourth line, D-B, the signal strength improved as well at the signal deviation on the two channels, Table 2 first two columns. This link was not optimized. The fifth line, D-C is both AGLcom dishes which improved the bandwidth, Table 3, and the signal deviations, Table 2. The final line, D-C, was the previous line optimized. The signal strengths moved closer together and the bandwidth improved.
Link Ch0 Ch1 Ch0 Ch1
- A-B -73 -76
- A-C -73 -74
A*-C -64 -66
- D-B -63 -62
- D-C -62 -62
D*-C -60 -60
-70 -74 -71 -71 -65 -66 -59 -59 -58 -58 -61 -61
Signal Strength (* optimized data) Table 1
Table 2 has four data columns, the first two being the measured results and the latter two being the measured difference from theory. The Jirous and AF5X calculators were used for the theory signals. Clearly the signal approached the theoritical limit with the optimization and with the change of dishes. The optimization improved the signal by ~9db for the link that we replaced the horn on the Jirous and by ~2db for the AGLcom link.
Link dSig dSig A-B 3 4 A-C 1 0 A*-C 2 1 D-B -1 0 D-C 0 0 D*-C 0 0
dSig dSig -16.5 -17.4 -17.0 -15.0 -8.0 -9.0 -13.3 -5.3 -7.0 -4.3 -5.0 -6.0
Signal strength variation from theory Table 2
The band width improvement was more obvious, Table 3, from 22 Mbs to 39 Mbs for the RX and 144 Mbs to 141 Mbs TX for the link with the horn replacement. The bandwidth improvement for the optimization of the AGLcom link was from 61Mbs to 66Mbs RX and from 211Mbs to 267Mbs for TX.
The bandwidth improvement from the original, optimized link to the AGLcom link is from 61Mbs RX to 67Mbs and from 210Mbs TX to 267Mbs. There is a clear improvement for the AGLcom link over the Jirous link.
- A-B 22.5
- A-C 39.0
- D-B 61.4
- D-C 60.6
BW-TX 144.6 141.4 210.0 211.0 215.0 267.6
The data supports a measurable improvement in both signal strength and bandwidth with the use of the AGLcom dishes. However, it is difficult to quantify the improvement. The Jirous dishes were identical whereas the AGLcom dishes were not. One of the jirous dishes was under performing initially but was repaired for the last tests. Additional testing is needed to provide accurate data analysis and performance comparison. The best performance tests would involve identical AGLcom dishes, ideally two links, one each of both types of dishes.
Cambium has a pretty good tutorial on their community forums on setting up PPPoE between Mikrotik and Cambium radios acting as clients.
#packetsdownrange #epmp #mikrotik