LTE18 and CA

Hi,

So I am one of the unhappy users of LHG LTE18 with operator being LMT. Or rather was.
This is about well known trouble with CA channels not being brought up when traffic increases on Quectel EG12/EG18 modems.

And the solution is simple:
/interface/lte at-chat lte1 input=“AT+QCFG="rrc",4”
followed by reboot.

I don’t know details as to why this is the way it is, either LMT does not support R9 of RRC protocol or there is bug in Quectel’s implementation or there is some other miscommunication between UE and eNB, but kicking RRC revision down to R8 solves the problem.
It might help with other Mikrotik’s LTE12 and LTE18 devices and other operators having the same issue.

Interesting. Not in Latvia, but there have been fews posts about this problem…

Seem there is a problem and theory has ranged from signal strengh, MIMO-ness, cell towers power down CA at night, carrier CA logic, and bugs in firmware. See also: http://forum.mikrotik.com/t/lte-ca-not-stable/161412/8

I know, I have read all those posts back and forth and have stirred up techies at LMT and at the end after reading about how CA is supposed to work and Qectel AT command manual, I tried kicking down modem’s RRC from default R9 to R8 and it started to work as expected.

LHG LTE18 does have only 2 antennas, while EG18 supports 4, which means that under perfect conditions full potential of EG18 will not be used and 1.2Gbps claimed data rate most likely is a lie, but in my case at least having reliable CA band bring-up is sufficient.

just tested on LMT LTE18, does not seem to work … I still loose all CA bands in about 20 minutes and they never return… is there something else you might have modified through AT commands?

No modifications, try speedtest or similar and see if they come back. Normally CA bands should be brought up only on demand.

I’ve been having CA issues for a while now and I kind of know when they work and when not :slight_smile: I did set rrc to 4, rebooted, after 15-20 min CA are gone and downlink usage does not seem to have any effect. Cell monitor also reports only primary band…
Are you 100% sure that changing rrc was the only thing you did? I have a hunch that it might have something to do with CQI reporting back to network and the reported number is lower than tower expects… but this is a wild guess…

Absolutely positive it’s the only thing. Latest firmware though. Was on the phone with LMT tech and he reassured that even though there are only two antennas, everything gets reported back as it should. Maybe signal levels are just way too low?

I was trying this on my indoor backup unit… maybe the signal indeed was too weak. I just enabled it on my outdoor Mikrotik ATL LTE18 and it seems that it does not drop CA bands anymore. I mean the bands are persistant even if there is no DL traffic. Looks very good. Will see if CA bands are still there in the morning…

We will to some more tests together with LMT to see what could cause that.

Looks like this “hack” helped LHGG LTE 18
lmtca.png
will monitor

Tower is 7.8km away

I can also confirm that this works. Haven’t lost any band during the night.

I would call this more of a workaround rather than solution though, let the MT and LMT guys do their thing.

One thing that confuses me, is that LTE Rel8/Rel9 supports max 300Mbps DL rate, Quectel EG18 is being advertised as Rel12 device and capable of 1.2Gbps DL rate yet any higher RRC setting than 5 fails with error. Is Quectel lagging behind their promises with firmware?
And major difference between LTE Rel8 and Rel9 in regards of MIMO operation is beam forming at eNB, so maybe under conditions where more or less reliable trialateration of UE is not possible (my specific case and probably most use cases for LHG devices), beam forming fails at eNB and no additional bands can be received at UE? Just thinking aloud.

Got contacted by LMT already to try enabling RRC=5 back, they changed something at the tower. Will try that in an hour and let you know the results…
However this seems to me more quectel related, because you can find similar issues in their forum with different carriers… so this is not something LMT specific…

Definitely Qeuctel is the one looking shady here (and MT by association a little :slight_smile: ), not LMT.

rrc=4 does not work for me.
The strange is that some month ago CA was always connected for weeks, then I got ATL for a test, which also drops CA, now I am connected back to Chateau LTE18 (LMT) with 2 external antennas and now CA drops. Only change I have made is RouterOS upgrade from 7.8 to 7.9rc3, but doubt that it should be connected. Anyway, all hopes on MT + LMT testing. Will change back to rrc=5 for now.

For some reason rrc=4 did not work for me at the beginning. But after several restarts and interface up/downs it suddenly started to work. Not sure why, maybe try unplugging power for a few seconds after setting rrc to 4…

Keep in mind, this is not magic pill that will make signal appear where it is not, this merely slightly changes the way CA Bands are managed. If signal levels of other bands are below usable, there will be no CA anyway.

Another interesting observation - I am running stress test with rcc=4, 20s DL, 20s delay. It works for few hours, CA bands are brought up and torn down, as they should. Until it doesn’t. My primary band is B20@10MHz, which sucks, but that is life. When CA works as expected, I see B1 and B3 signals from the cell I am attached to along with other more distant cells. But when CA stops working, all I see in cell monitor, is B20 signals. Interface disable/enable cures this. Another pointer at Quectel not doing a great job?

So, I’ve switched back to rrc=5 as per LMT request and it seems that it’s running much more stable now after they changed something on their end. CA bands are released/assigned as needed and I always get full CA capacity when downloading. Will see if this still works in the morning…

I also got a call from LMT and apparently EG18 reports Rel12 capabilities to network and all this changing RCC thing most likely is correlative, not causative. The jury is still out what is causing this behavior.