Hi,

I have a strange issue with my LHG LTE6 kit. It works fine for a few hours and then it gets slower and slower until I restart lte1 interface, after the restart it gets back to normal.

I recently upgraded OS to: 7.12.1 and interface to: MikroTik_CP_2.160.000_v021 but it did not help.

Does anyone face the same issue?

Thanks,
Michal.

Upgrade to 7.15.3. There have been quite a bit of LTE fixes there.
I would try that first.

I did it - thanks!

hey - still the same. I noted that the whole router became incredible slow and then internet is slow as well. After the interface restart everything goes back to normal. I can't even work with terminal until I restart the lte1 interface.

Here is the screenshot of pings (before and after restart).

Does anyone faced the same issue, it is so irritating...

You might be losing Carrier Aggregation (CA) when the LTE modem (UE) deactivates a secondary carrier to save power because full aggregation isn’t needed when data usage is low and the device doesn’t require the full bandwidth. This can also happen at the base station for the same reasons, depending on location, network performance, and resource utilization.

When CA is established or downgraded, there are often delays of several seconds before communication is fully set up. There are ways to work around this by sending payload packets at regular intervals once CA is fully established, using BDF or similar packet streams to maintain all channels.

Check the current CA channels in use with WinBox: Interfaces -> LTE -> Cellular -> Primary Band + CA Bands

It's worth noting that if you use RoS Netwatch with LTE Carrier Aggregation (CA), you might run into issues. This happens if the Netwatch's test probe re-enable CA, causing a long delay before it receives it's first response and consequently triggers the down-script event. In that sense, RoS Netwatch is flawed, as it would need a pre-test script that sends payload data before performing the actual probing.

Hi,

I set Band to 7 (as it gave me the best results) and do not use aggregation. Do I miss anything here?

Before you made those changes, did you check if CA was really the underlying problem? Just so you know, if you disable CA, your transfer speed will be significantly limited.

My guess would also be to undo that locking to band 7 first.
Let it decide by itself.

Sometimes a band with worse perceived parameters can actually perform better.

Thanks - I will check and report back.

Yeah this is the downside of "band locking"... When you set something like Band 7, it does not "failover" to another band. And tower may be "steering traffic" to use another band if band 7/whatever becomes congested.

One thing to do is add a /tool/netwatch using type=icmp that pings google or something. This keeps some (even if marginal) traffic flowing over the LTE link. How much the avoid tower deallocating resources for CA/bandwidth, I dunno but simple and cannot hurt. Also, /tool/netwatch also give you some stats on latency/etc, which is often a good indicator of LTE tower performance (latency generally goes up, when available bandwidth goes down).

We're managing a bunch of LTE/NR CPEs and have figured out that you need at least two payload packets per second to keep CA running. Some operators skip the ICMP traffic in this. So far, what’s been working best for us is sending BFD Hello packets (24-byte payload) every 300 ms, ie about three packets per second.

I’ve had a similar issue with my LTE setup before. It sounds like it could be a memory leak or something with the interface that’s causing the slowdown. Have you tried checking the system logs to see if anything stands out before you restart? Sometimes a simple reset of the whole unit can help too, rather than just the LTE interface.

Some issue with the band locking seems more likely to me. LTE Band in interface is not some "band preference", it filters other bands from being used.
But, if it were a memory leak, that be easy to check /system/resource before rebooting.
Now since this seems to happen a regular intervals, that seems more like a network-side thing.

- [...] you need at least two payload packets per second to keep CA running.
- Some operators skip the ICMP traffic in this. [...]
- BFD Hello packets (24-byte payload) every 300 ms, ie about three packets per second.

Good info. FWIW, there is also a DNS check in /tool/netwatch in very recent V7s too, that generate UDP. I run a different netwatchs types, but BGP hello is a good idea.

It is a bit of a cat-and-mouse game with these towers/etc. And since part of CA, beyond more bandwidth, is shifting load to other bands. Dropping a band to force CPE like LHG to actually use CA... seems like something the LTE network might do to keep the primary bands clear if possible.

It is a bit of a cat-and-mouse game with these towers/etc. And since part of CA, beyond more bandwidth, is shifting load to other bands. Dropping a band to force CPE like LHG to actually use CA... seems like something the LTE network might do to keep the primary bands clear if possible.

Yeah, but things have actually been pretty stable for us over the last couple of years, with only a few occasional CA channel changes, likely due to base station maintenance. The three NMOs we use today behave almost identically when it comes to allocating and deallocating channels for CA. When it comes to CPEs from Mikrotik, we initially had major issues with Netwatch, but that completely disappeared after switching to OOB management using BGP and BFD tuned to a 300 ms tx rate.

I removed band lock and here is what happened:


Prior restart:
Band 7


After restart
Band 7, similar connection parameters. Same tower...


and the log file

Do you use detect internet ?
Most will advice to disable it.

Beside update of update RouterOS to the latest version, upgrade also you modem firmware. I had in past also some issues with unstable connection, due to old firmware.
However the best thing which you might do is replace LHG LTE6 to LHGG or ATL LTE18. I see significant improvement in connection stability, so do speed.

Beside update of update RouterOS to the latest version, upgrade also you modem firmware. I had in past also some issues with unstable connection, due to old firmware.

And RouterBOOT in /system/routerboard - not sure it changes... but with LTE latest with 3 versions aligning on stable is my strong recommendation to start. I generally use the "auto-update=yes" in /system/routerboard - so after RouterOS upgrade, rebooting a 2nd time will apply the firewarm automatically - so you don't forget.

However the best thing which you might do is replace LHG LTE6 to LHGG or ATL LTE18. I see significant improvement in connection stability, so do speed.

True, in US, just having Band 66 dramatically changes speeds... but since the ATL does not support US bands at all, that LHG LTE6 actually be a better choice ironically since it get part of Band 66 (Band 4).

But in most parts of the EU/world, I'm sure the LHGG or ATL be a dramatic improvement since it can use extended bands.

I think OP knows where the tower is located, but generally it's helpful to do some homework with cellmapper.net to see what bands are available in your area. There are other sites, and some countries even publish cell towers/bands, so some googling to find the band your carrier uses is pretty helpful in deciding on a new device. Maybe there is 2nd tower to point it at that may be more stable?

Also can enable some more logging if not done so already, that may give more clues. This will add a new memory group for "lte" logs with debug info (still memory, but does not clutter mainly logs): If it keeps happening & with the "3 versions" of LTE, RouterOS, and RouterBOOT all aligned to 7.16.1 (current stable).... I'd open a support case, and make sure to include a supout.rif BEFORE restarting the modem. And if enabled the above logs, the debug logs would be included in the supout.rif.