BG96 Time Synchronization by SIB16

Hello, I faced time synchronization issue by BG96.

The issue is that the BG96 does not seem to be receiving or not receiving NITZ-based date/time information from the network even though it has had good reception (IP communication available) for a long period of time (at least 10 days).
Although no detailed logs are kept at that time, we know that BG96 received a “registration denied” message from the network, and from that point on, the date and time information could not be retrieved. We have also confirmed that BG96 completed its registration shortly thereafter and was able to communicate over IP.

To analyze this problem, the radio environment was varied to see if the problem could be reproduced. And we found similar events, although the conditions under which they occurred were different.

I basically use the AT command “AT+QLTS=2” to get the date and time information. As shown in the following log of the AT command, when BG96 was set up in an out-of-range environment and then changed to a weak signal environment, the date/time information could not be acquired, and then, even if the signal environment was made good, the date/time information could not be acquired for a while.
In addition, we confirmed a case in which date/time information could not be acquired even when the environment was changed from out-of-range to in-range.

I am assuming that this event is the failure to retrieve the system information (in particular, SIB16) broadcast by the NW when the BG96 is registered (RRC connection established), is that hypothesis correct?

However, is it possible that there is a case where the RRC connection is established but the system information is not received at that time?

Also, if such an event occurs when a “registration denied” event is received and a connection is established immediately with another nodeB, is there any mechanism to prevent the BG96 from receiving system information internally? (I don’t think this is very likely…)

I would appreciate any advice you could give me on how to solve this issue.

I am connecting to BG96 with the following settings:

  • Japanese carrier (Docomo)
  • LTE Cat-M1
  • Fixed band (Band1/19)

FW version that we using is BG96MAR03A08M1G_21.001.01.001

AT Command log:
[2023-10-20 09:06:19.698] > AT+QLTS=2
[2023-10-20 09:06:19.729]
[2023-10-20 09:06:19.778] +QLTS: “2023/10/20,09:06:19+36,0”
[2023-10-20 09:06:19.778]
[2023-10-20 09:06:19.778] OK
[2023-10-20 09:07:29.367] +CGEV: NW DETACH
[2023-10-20 09:07:29.495] +QIND: “csq”,99,99
[2023-10-20 09:07:29.495]
[2023-10-20 09:07:29.495] +CEREG: 0
[2023-10-20 09:07:56.116] +QIND: “csq”,99,99
[2023-10-20 09:07:56.116]
[2023-10-20 09:07:56.116] +CEREG: 1,“116E”,“2170311”,8
[2023-10-20 09:07:56.229] > AT+QENG=“servingcell”
[2023-10-20 09:07:56.276]
[2023-10-20 09:07:56.542] +QENG: “servingcell”,“NOCONN”,“CAT-M”,“FDD”,440,10,2170311,376,6100,19,3,3,116E,-128,-13,-97,10,4
[2023-10-20 09:07:56.542]
[2023-10-20 09:07:56.542] OK
[2023-10-20 09:07:56.572] > AT+QLTS=2
[2023-10-20 09:07:56.605]
[2023-10-20 09:07:56.654] OK
[2023-10-20 09:07:58.488] +QIND: “csq”,8,99
[2023-10-20 09:11:33.176] > AT+QLTS=2
[2023-10-20 09:11:33.226]
[2023-10-20 09:11:33.259] OK
[2023-10-20 09:11:35.047] > AT+CSQ
[2023-10-20 09:11:35.079]
[2023-10-20 09:11:35.142] +CSQ: 22,99
[2023-10-20 09:11:35.157]
[2023-10-20 09:11:35.189] OK
[2023-10-20 17:28:53.637] > AT+QLTS=2
[2023-10-20 17:28:53.672]
[2023-10-20 17:28:53.722] OK
[2023-10-20 17:28:55.491]
[2023-10-20 17:28:55.524] +QIND: “csq”,22,99
[2023-10-20 18:31:20.866] +QIND: “csq”,99,99
[2023-10-20 18:31:20.866]
[2023-10-20 18:31:20.866] +CEREG: 0
[2023-10-20 18:31:43.697] +QIND: “csq”,99,99
[2023-10-20 18:31:43.697]
[2023-10-20 18:31:43.697] +CEREG: 1,“116E”,“27A0910”,8
[2023-10-20 18:31:43.820] > AT+QENG=“servingcell”
[2023-10-20 18:31:43.865]
[2023-10-20 18:31:44.113] +QENG: “servingcell”,“CONNECT”,“CAT-M”,“FDD”,440,10,27A0910,397,6100,19,3,3,116E,-102,-17,-67,7,-
[2023-10-20 18:31:44.136]
[2023-10-20 18:31:44.136] OK
[2023-10-20 18:31:44.170] > AT+QLTS=2
[2023-10-20 18:31:44.202]
[2023-10-20 18:31:44.248] OK
[2023-10-20 18:31:46.855]
[2023-10-20 18:31:46.863] +QIND: “csq”,22,99
[2023-10-20 18:31:47.079] > AT+CGPADDR=1
[2023-10-20 18:31:47.117]
[2023-10-20 18:31:47.181] +CGPADDR: 1,,
[2023-10-20 18:31:47.181]
[2023-10-20 18:31:47.181] OK

1 Like

based on this AT log , you have registered network successfully , atter that ,pls check the below AT


[2023-11-30_20:13:15:768]+cclk: “80/01/06,00:00:12”

normally the result should be the NITZ time , you get from the network

if you can not get it normally , pls capture QXDM log for more anlysis , it does not include enough info in AT log .

Hello Stephen,
Thank you for response.

I found below fact based on analysis.

1: BG96 requests “Attach Request” to nodeB
2: nodeB sends “Attach Accept” to BG96
3: BG96 sends “Attach Complete” to nodeB
4: After attach process is completed, nodeB sends “EMM Information”.
5: When BG96 gets “EMM Information”, it set internal time and recognized “Time Synced”.

In this case, BG96 does not re-attach process. It only execute RRC re-connection process.
So, BG96 does not recognize “Time Synced”.

I have one question.
Is “EMM Information” the only message the BG96 uses when synchronizing date/time information from the LTE network, or does the BG96 use other date/time reporting information (e.g. SIB16)?

Hello @Stephen.Li-Q

I have 1 additional question.
According to “Quectel_BG96_AT_Commands_Manual_V2.3.pdf”, in Chapter 6.16,
If the date and time are not synchronized, the response to AT+QLTS will output null date and time information as “+QLTS: “”\r\nOK”".
However, in this case, BG96 only outputs the response message “OK”.
Is this behavior of BG96 a bug?
If this behavior is not a bug, can you please provide an application note with the correct specifications?