PLS8: AT+COPS issue in roaming scenario (4G) | Telit Cinterion IoT Developer Community
December 19, 2016 - 6:36pm, 6938 views
I have experimented some problems with this command, in a roaming scenario, trying to connect to 4G. For my project, I usually set a RAT restriction (2G/3G/4G) to the module so that I am sure it's not using a technology different than desired for data transmissions. I set the restriction sending the command AT+COPS=0,2,"0",7 where I just care about using the 4G technology, regardless of the operator to be used. In national scenarios it works like a charm, however, I've found a roaming scenario in which this command takes too long to be issued (no response from the module during a while) having to interrupt it before having the response, many *****, after waiting up to 25 seconds. I've also found that, even when the operator selection command is correctly issued (and answered with an "OK"), module is not able to register to the network, AT+CREG? command always return "Not registered, but searching".
I thought it could be a coverage matter, but, if I issue the AT+COPS=0,2,"0", command, the module takes not too much time to correctly register to the network, even using 4G, which was impossible a while before using the more restricting version of the command.
Any idea about the reason for this different behaviours?
Thanks in advance.
The longer registration time while roaming could be a result of additional communication with the home network.
Have you also checked other commands than AT+CREG?, like AT+CEREG?, AT+CGREG?, AT^SMONI, AT+COPS? after sending AT+COPS=0,2,"0",7 ?
How about the AT+CGDCONT settings? Do you have the proper context configured for the foreign network?
Please also check AT^SCFG? and ATI replies.
After testing the module in a different location (supossed to have worse signal conditions), it finally achieved 4G registration in some cases, but still having problems and taking too much to register.
I understand longer ***** are required in roaming, but I've also let the command AT+COPS=0,2,"0",X take as much time as needed and had also no response at all, having to stop the command after 3-4 minutes.
In those cases where the AT+COPS... finally worked (had previously issued and checked the AT+CGATT=1 command, like always), I've checked the commented commands with these results:
AT+CREG? +CREG: 1,2
AT+CGREG? +CGREG: 1,2
AT+CEREG? +CEREG: 0,4
AT^SMONI=255 ^SMONI: 4G, SEARCH, SEARCH
AT+COPS? +COPS: 0
Same results all the time until it finally registers correctly, which is unusual to happen, time in which commands show:
AT+CREG? +CREG: 1,1
AT+CGREG? +CGREG: 1,1
AT+CEREG? +CEREG: 0,1
AT^SMONI=255 ^SMONI: 4G,2850,7,20,20,FDD,240,**,8508,4D0C805,487,-32768,-108,-7,CONN
AT+COPS? +COPS: 0,2,"PLMN",7
Value "1" for register states is because the used SIM is a roaming one, but it just accepts home network for 4G.
Regarding AT+CGDCONT settings, context configuration is correct. Indeed, data network is used without a problem when finally correctly registered, using the given context config.
The other commands replies:
^SCFG: "Radio/CNS","0" ----> Now changed to "1" and testing...
Note: common smartphones (national SIM) are able to use 4G in the first testing location.
I would like to check if you have the latest firmware on the module. Could you check once again the ATI1 reply? I forgot to add '1' in my previous post and it is necessary to get all the details.
The RSRP (Reference Signal Received Power) value is quite low which could indicate the poor 4G network quality.
It will probably not change anything but you could enable "GPRS/AutoAttach" in SCFG.
Yes, sure, here's the command output:
For the purpose of my application, "GPRS/AutoAttach" feature has to be disabled.
please note that in 4G modules auto attach is by default set to "On". This is important as 4G is Packet Swich only network. If you before register attempts to register exeute AT+CGATT=1 than OK but our tests show that this could lead to register problems - try to enable autoattach to be sure that this does not influence your scenario.
Please also note that in 4G there is something called default bearer - because of that is recommended to leave AT+CGDCONT with <cid> 1 empty - network fill this entry with defult bearer. We noticed that very often network limit apn functionality to 2G 3G only and such apn is not working in 4G.
Normaly we are using to force technology in auto **** such command AT+COPS=,,,x where x is 0,2 or 7 . Maybe your input format AT+COPS=0,2,"0",7 confuse module - it try to search first network "0" ?
Regarding used version - there is newer version for release 2 - 02.011 a-rev 01.010.19 which you can try or even better will be to swich to new Release 3.
Update from REl 2 to Rel3 is possible it can be done only for test purposes -for mass production new Rel3 module has to be ordered as some part of module FW cannot be properly updated.
Thanks for your answer.
I've tested everything you mentioned. Using a <cid> different than "1" made no difference. Using AT+COPS=,,,x command format to force technology didn't appear to change a thing either, however I modified the software to use it like that.
Regarding attach, I've checked that all the ***** (by the moment) the 4G register process fails, attach had been lost (AT+CGATT? returned +CGATT: 0) and if I issue again an attach and it successfully works, next time register is tried, it also works. What is strange to me and I'd like you to clarify me is why the first attach, after being correctly issued and tested to be enabled (AT+CGATT? returns +CGATT: 1) is released without any action carried out by the module.
I also don't understand why this problem could also affect 3G (something I did not mention in my first message). In the first scenario (without applying any of the commented changes), I also had problems for 3G registering, same issue as with 4G, AT+COPS=0,2,"0",2 command never returned on some ocassions, not being able to force technology.
Due to the LTE specifics that Łukasz has described I think that you should test it with auto attach enabled to check if it's not the case here. Was it enabled during the test that you describe in your last post?The attach must have been released by the network.
As the products are being constantly improved I also think that you should use the latest firmware release for testing.
This last test was developed with auto attach disabled. I had previously tested it with auto attach enabled with no luck, same problem with LTE registering (had not yet retried manual attach prior to registration retry, during that old tests). I often issue AT+CGATT=0 (it's an application requirement), even with auto attach enabled, so I thought it was maybe interfering with the auto attach feature in those cases.
Is it common that the network itself releases the attach? It's about 30 seconds between the UE is manually attached and then released (presumably by the network).
Do you know where could I find this new firmware version and its release notes?
Thanks for your support.
Regarding the newer firmware version for release 2 (02.011 a-rev 01.010.19), what are the main differences/improvements in comparison to the one we currently use? Is there any place in which we can find the firmware file and a release notes doc?
Thanks. Best regards,
Normally you should get the new firmware form your module's distributor. If you plan to oder the release 3 modules you should try the release 3 now, otherwise release 2. I could also send you.
As 4G is packet switched only network issuing AT+CGATT=0 will disconnect it.
The network could also try to switch the device to 3G or 2G for example. One of the reasons could be poor 4G coverage in the area.