Performance issues with BGS5 during Connector.open() when no connection can be made | Thales IoT Developer Community
October 1, 2018 - 4:57pm, 5010 views
Hi,
I would like to state up front that during normal scenario's, my BGS5 modem behaves as expected. It connects to the GSM network, and periodically sends data to a central server, using a TCP connection created using Connector.open(). On the device that has the BGS5 modem, there is another module (MCU) that is reachable from the Java Application running on the BGS5. This integration also works fine under normal conditions. There are a bunch of threads running on this device that all gather information, or perform some actions, side by side.
This is my device:
ATI1
Cinterion
BGS5
REVISION 01.100
A-REVISION 00.000.21
I would now like to go into details about what is going wrong:
When the modem is not capable of creating a connection (because there is bad coverage) the modem, and the Java Application running on top of it, seems to be locking up/freezing. As a result, all threads of the java application seem to be locking/freezing, until the Connector.open() method throws an exception, 60 seconds later (the Exception is typically: "java.io.IOException: Profile could not be activated"). Let me be explicit: all threads (even those that have nothing do to with networking) are halted until the Connector.open() method finishes.
This causes a lot of timing problems with the other threads, and even some crashes in the MCU that does not know how to handle the java-application-free.
This situation can be replicated for me by having two threads running.
- A thread that prints a value every second.
- A thread that tries to open a Connection using Connector.open("socket://[Server]:[Port];bearer_type=gprs;access_point=[APN];username=[APNUSERNAME];password=[APNPASSWORD]")
To simulate the network problems, you could issue the command AT+COPS=2, to deregister GPRS. You should now see that the first thread that prints a value be halted, until the Connector.open method ***** out.
Is this known behavior? If so, is there a workaround? I need to be able to have all my concurrent threads operating normally, without them freezing whenever I have a connection issue (which would be happening unpredictably).
Hello,
Thank you for the detailed description. There was such a problem already detected. It was fixed, but the version that you have does not contain the fix yet.
And unfortunately it is currently the latest official software for BGS5 release 1 modules. There is release 2 firmware available and it should also contain this fix but the new hardware is required. I think that you could contact your local Gemalto office with this problem - you can find the contact data here: https://www.gemalto.com/m2m/where-to-buy
As for the workaround you should check the network state before making a data connection.
Best regards,
Bartłomiej
Hi Bartlomiej,
You indicated that for the BGS5 Release 1, this problem was not yet fixed (but only for release 2). Can you provide a timeline for when Release 1 will receive the fix for this problem? I understand having to support two branches of code is cumbersome, but I can also see that a big bug like this merits fixing. In addition, since the solution for Release 2 is known, it should be (relatively) easy to backpatch this solution to Release 1.
As far as the workaround is concerned, I think I need some improved understanding. I think it means that I should wait for the Bearer State of the APN to be "UP", before I initiatiate a data connection. All the other BearerControlState constants indicate that opening of the data connection will fail.
Additional question: I have heard that I am able to append ";timeout=15" to the Connector.open() argument, to change the default timeout that I observed (this default being 60 seconds). Is this correct? Is there documentation about this feature? I could not find anything in javadocs for javax.microedition.io.Connector and javax.microedition.io.SocketConnection.
Hello,
It was fixed in both release 1 and 2 but the current public version of release 1 does not yet contain this fix. That's why my advice was to contact the local Gemalto technical sales. We don't publish any timelines for the future releases on the forum.
For the workaround you should at least test the network registration with AT+CREG? command to detect if the module is registered. You might also test the signal quality with AT+CSQ for 2G and AT^SMONI for 3G to detect weak signal and then decide if the connection may be open.
This timeout is the same one that you can configure with AT^SJNET command. It is the number of seconds to wait before the network connection is terminated automatically after having closed the last socket on this connection. So bearer state UP will be changed to DOWN after this timeout and will only be attempted to be changed to UP when you call Connector.open(). You can set 0 in order to keep the connection up but it still can be disconnected by the network at any time.
Best regards,
Bartłomiej
Thank you. I've let the MCU supplier to get into contact with Gemalto about a possible release 1 version upgrade, so that I can permanently fix this issue.
I don't think the AT+CREG? command would only work if it is a reliable indicator of connectivity. I don't think it is, since in my experience I've seen that the device can be reached by Voicecalls just prior to attempting the Connector.open() that subsequently lock up and freezes the entire java application.
I agree with you that AT+CREG may not be enough. That's why I have suggested signal quality measurements with AT+CSQ (RSSI parameter) for 2G and AT^SMONI for 3G (RSCP and EC/n0 parameters). Then you would have to arbitrary choose some minimum values of the signal quality parameters for the connection establishment. That should improve this mechnism.
Hi Bartlomiej,
I understand what you're saying about checking signal quality. What I'm saying from my end is that I don't think checking signal quality will help in the most important cases. What I am (or rather my customers are) experiencing is that in situations where the device should have an unobstructed GSM/GPRS signal, the GPRS connection will nonetheless fail without warning. In these cases, I will have no hint that Connector.open() is not yet ready to be called, and all threads will lock while I am attempting to open the connection..
Hello,
The workaround of course have limitations and may not work in 100% of cases. But I believe that it should do in most cases if you select safe values for signal quality factors. On the other hand if the values are too restrictive it could frequently prevent the app from connecting. It's not a perfect solution.
It's not a good news because you never can be 100% that the connection will succeed before it actually succeeds... The best solution would be to get the software with the fix.
You could also try to use AT commands instead of Java API but it would not be as nice as using pure Java. You could also try to set up some simple connection with AT commands just for test if it won't fail before opening the main Java connection.
Regards,
Bartłomiej
Hello,
I'm having the exact same issue.
If a connection can't be made, the module freezes every thread and only recovers at the timed HW reset that I programmed.
Should I contact the reseller that sold me the BGS5T about the issue and hardware replacement?
Thank you.
Hello,
This is a software problem. But I think that you can contact your reseller. It's been fixed but revision 1 firmware that contains this fix has not yet been released.
Regards,
Bartłomiej
We contacted our reseller about this and the response was that there will be no official firmware (for Rel.1) for the BGS5 Rel.1, which can then be used in production. All currently available beta builds (firmware 1.100 ARN 00.000.27 / 29) contain the fix, but are not completely tested until the release and thus do not receive customer approval.
If you have other information inside gemalto or received from another reseller please let us know.
Kind regards,
Simon
Pages