Mikrotik LHGG LTE6 kit (RBLHGGR&R11e-LTE6) freeze cell lock or band lock

Hi everyone,

I use as WinTre mobile operator and my reference bts has 4 bands (B1 B20 B3 B7) and it is 180 meters from me. I have a problem with the kit in question when I go to do either a lock on a specific cell or with the lock on a specific band for the primary.
In practice both if I try to do the command to block at the level of a specific primary cell (I use band 3 because it is the one that gives me the best upload performance compared to the other bands):

[admin@MikroTik] > /interface lte at-chat lte1 input="AT*Cell=2,3,,1650,367"
  output: +CREG: 6,"5f37","03b9db0e",7 $CREG: 6,"5f37","03b9db0e",7,"0b5" +CEREG: 1,"5f37",
          "03b9db0e",7

or at the level of specific primary band:

[admin@MikroTik] > /interface lte at-chat lte1 input="at*cell=1,3,,1650"
  output: +CGEV: NW PDN DEACT 5

after the command is executed, the specific band/cell is regularly set as primary and the secondary band is added (in my case that of a cell in band 7), after a few minutes (about 10/12 minutes, but sometimes even less) the CA is lost, and the internet connection freezes (the session duration counter continues, but you are no longer able to surf):
Screenshot (1240).png
I tried to put both the latest stable of RouterOS (6.48.1) and the beta (7.1beta 3) but the problem remains.
The only way to get it working again is to cancel the commands just given with:

[admin@MikroTik] > /interface lte at-chat lte1 input="AT*Cell=0"                          
  output: +CGEV: ME DETACH

I am attaching more information, after the connection has been restored by the previous command:

[admin@MikroTik] > /system routerboard print
       routerboard: yes
             model: RBLHGGR
     serial-number: D8C40C521E24
     firmware-type: a3700
  factory-firmware: 6.47.1
  current-firmware: 6.48.1
  upgrade-firmware: 6.48.1
[admin@MikroTik] > /system resource print
                   uptime: 43m47s
                  version: 6.48.1 (stable)
               build-time: Feb/03/2021 10:54:22
         factory-software: 6.46.6
              free-memory: 226.5MiB
             total-memory: 256.0MiB
                      cpu: ARMv7
                cpu-count: 2
                 cpu-load: 1%
           free-hdd-space: 2392.0KiB
          total-hdd-space: 16.0MiB
  write-sect-since-reboot: 94
         write-sect-total: 8207
               bad-blocks: 0%
        architecture-name: arm64
               board-name: RBLHGGR
                 platform: MikroTik
[admin@MikroTik] > /interface lte info lte1 once
           pin-status: ok
  registration-status: registered
        functionality: full
         manufacturer: "MikroTik"
                model: "R11e-LTE6"
             revision: R11e-LTE6_V026
     current-operator: 22288
                  lac: 24375
       current-cellid: 62511886
               enb-id: 244187
            sector-id: 14
           phy-cellid: 181
    access-technology: LTE (CA2)
       session-uptime: 12m38s
                 imei: 
                 imsi: 
                 uicc: 
         primary-band: B7@20Mhz earfcn: 3350 phy-cellid: 181
              ca-band: B3@20Mhz earfcn: 1650 phy-cellid: 367
                 rssi: -64dBm
                 rsrp: -95dBm
                 rsrq: -8.5dB
                 sinr: 7dB

Do you have any ideas on how to fix this? Thank you

Your LTE interface firmware is updated?
Your RouterBOARD firmware (Not RouterOS) is updated?

Regards.

In the meantime I had also tried to re-flash the firmware of the LTE module, but I only got that the session only lasted a few more minutes before freezing

with the command:
/interface lte firmware-upgrade

I already had the most recent one, namely the revision: R11e-LTE6_V026

If you mean by winbox:
“System” menu → “RouterBOARD” → “update” button
Yes i’ do

In any case, I opened an RMA and returned the unit in my possession to the seller; and I ordered another from another seller, hoping that the one that will arrive to me does not have the same anomaly.

Unfortunately, the LHGG that I got from another shop has the same problem as the first one with cell lock and band lock; by default (Routeros 6.47.1 and the lte firmware version R11e-LTE6_V025 the connection remains usable up to about 24 minutes after which it freezes as in the other kit.

Updating the routeros and routerboard to stable 6.48.1, the duration of the session before the freeze is the same as that of the other kit (about 12/14 minutes).

Am I unfortunate I got another loser kit from LHGG or is there some batch with problems?

Try

/interface lte firmware-upgrade lte1 upgrade=yes

Last firmw
026

hello, on this kit I have not yet updated the lte firmware, but since in the other one doing the lte firmware update had not solved, I doubt that this works on this.

At first, update firmware lte module by:
https://wiki.mikrotik.com/wiki/Manual:Interface/LTE#Modem_firmware_upgrade
/interface lte firmware-upgrade lte1 upgrade=yes
Latest one is 026 but support have got a release candidate 027 and if you ask them probably they install it on your hw.

Second, enable LTE LOGs, to detect what happend when you have a “breake of internet”.
/system logging add topics=lte

Finaly, install the LTE Logger : http://forum.mikrotik.com/t/r11e-lte6-2ca-not-staying-connected/136004/22

With that info you can share your logs after reboot and wait 30minutes, good if your problem repeat. You can create a supout.rif and this is good point to send it to support@mikrotik.com too !
For us, you can just save logs to file by: /log print file=log.txt

Good Luck and give us feedback

Hi, thanks for the reply, I just now had some time to devote to tests etc.
I have a question (maybe it’s obvious to you); but how do i install the ros7-lteLogger2.rsc?
Currently I have updated the firmware of the lte module to v26, I have set version 7.1b3 as RouterOS, lte logging enabled; but I stopped on how to install the file. Should I always use the “File” window or do I have to use a different procedure ?.
Thanks for a possible answer.

I generate that file by export commands.
You must use a /import filename.rsc

Thanks, done.
Clearly, because the “anomaly” I have recurs, I must first give the command to do the cell lock or even the one for the band lock for the primary cell; otherwise if I don’t give that command the event never occurs.

yes, you must generate a problem to show it in logs.
Remember that you can do /log print file=log.txt and share that file with information at what time problem exist.

ok

Attached I have put the log with what happens in 30 minutes.

At 09:53:34 local in the log I gave the command for the lock cell of a cell in band 3;

at 10:08:11 given that the CA with the cell in Band 7 had disappeared and the connection had frozen (no ip or domain that can be pinged on the internet despite the fact that the counter remains active and continues as if the connection had not “dropped”) .
I gave the command to cancel that cell lock and then the connection went back to working.

soon I will send the supout.rif file to the email you indicated

[admin@MikroTik] > /system resource print                                   
                   uptime: 14m32s
                  version: 7.1beta3 (development)
               build-time: Dec/02/2020 15:59:47
         factory-software: 6.46.6
              free-memory: 116.7MiB
             total-memory: 256.0MiB
                cpu-count: 2
                 cpu-load: 0%
           free-hdd-space: 2304.0KiB
          total-hdd-space: 16.0MiB
  write-sect-since-reboot: 253
         write-sect-total: 253
               bad-blocks: 0%
        architecture-name: arm64
               board-name: RBLHGGR
                 platform: MikroTik
[admin@MikroTik] > /system routerboard print                                
                ;;; Warning: cpu not running at default frequency
       routerboard: yes
             model: RBLHGGR
     serial-number: D8C40C702E37
     firmware-type: a3700
  factory-firmware: 6.47.1
  current-firmware: 7.1beta3
  upgrade-firmware: 7.1beta3
[admin@MikroTik] > 
[admin@MikroTik] > /interface lte at-chat lte1 input="AT*Cell=0"            
  output: +CGEV: ME DETACH
  [admin@MikroTik] > /interface lte firmware-upgrade lte1                     
  installed: R11e-LTE6_V026
     latest: R11e-LTE6_V026
[admin@MikroTik] >

log2.txt (10.7 KB)

At the LteLogger2 you can enable in second line other parameters like signals to check what changes will happend when you have a freez internet but probably some signals freez and some report a value. Connection is up but no any traffic on it. Rx packages and bytes at lte1… . You can check for more confirmation and digging but this is not requested.

Please register at https://help.mikrotik.com/servicedesk/servicedesk or if you send e-mails to support@mikrotik.com then please use that your e-mail and restore password.
That way you can open/edit/replay/share your case at JIRA.

Please generate a SupOut.rif file and include it in the case to MikroTik vendor. Of course you can just send e-mail with supout.rif, url to this case at forum, this log.txt and description.
For me it’s a the same problem like here: http://forum.mikrotik.com/t/r11e-lte6-2ca-not-staying-connected/136004/1 and http://forum.mikrotik.com/t/v6-46-1-stable-is-released/135478/1

I will mount the LDFR with R11e-LTE6 this week and check it at my location too for veryfication.

I registered on the link and created the ticket (including various information).
In my case, however, compared to that of the user of the link, when I leave everything automatic (without therefore setting the primary cell or band I want) the CA remains on even if the data traffic is almost nil.

The curious thing that with the same RouterOS if I do the cell lock with the same cell of the same bts and obviously the same mobile operator on the other Mikrotik product I have, that is the Chateau LTE 12, the connection does not freeze when I give the cell lock , but stay on without problems; only the counter for the duration of the session every few random minutes resets and restarts, but always without freezing the connection as it happens on both LHGGs that I tried.

Probably affects the fact that on the Chateau there is a Quectel lte chip while on the LHGG there is a Huawei (if I remember correctly).

Chateau base at soldered EG12, you cannot change a lte module.
LHG(G)R base at mPCIe module, R11e-LTE6 who base at.. secret who is on this forum deleted. This SoC is not Quectel etc. Litle and small company.

Bring a feedback if your case will have some new info or you want additional help.

If there will be any news, I will definitely update the post.

Yes, the Chateau has a soldered LTE chip, in fact I wanted to try the new LHGG since it has the possibility of being “modular” as far as the LTE part is concerned, in fact it was my intention (once all the pieces have arrived) to put a Cat16 M.2 EM160R-GL module obviously with its M2 to mini pci adapter :).

It’s working properly like EM12-G, 502Q too :slight_smile:

Yes, a friend of mine put the EM12-G, but since I already had a category 12 with the Chateau I thought that a good compromise was to try to put category 16 (also because I didn’t find that category 18); for the other module if it’s one of those for 5G it’s priced out of budget for me.

In USA we receive more speed with EM160 then EM12-G by differ Bands and CA combinations.

Hi, they replied to the ticket like this:

Hello,

This behavior is caused by the network requesting the device to handover to another cell, but as cell lock is present the device is not able to. The network is moving you from one cellID to the other to evenly distribute the load on the cells. As the device needs to follow the actions specified by the network in return it seems like the data session is dropped. Currently, no fix is available for this example, and might not be that would not contradict LTE technical specification. This information is already provided to the OEM. In these situations, cell lock should not be used.