EG915N-EU – Duplicate incoming SMS: two +CMTI URCs and the same message stored in both SM and ME

IoT Modules LTE-A Module
,
1

Hello,

I am seeing duplicated incoming SMS on an EG915N-EU and would like to understand whether this is expected behaviour or a known issue.

Module: Quectel EG915N
Firmware: EG915NEUAGR03A09M16

-– Problem —

A single SMS sent to the module results in TWO stored messages. Sender, text and service centre timestamp (SCTS) are identical, but they are stored as two separate records: one in SM and one in ME.

-– Steps to reproduce —

  1. Module restored to factory defaults.
  2. Only AT+CMGF=1 issued. No CNMI, CSMP or CPMS configuration at all.
  3. One single SMS sent to the module from another phone.

-– Observed behaviour —

Two URCs are received for one incoming message:

+CMTI: “ME”,0
+CMTI: “ME”,0

Listing with the default active storage (SM):

AT+CMGL=“ALL”
+CMGL: 0,“REC UNREAD”,“+9054xxxxxxx”,“26/09/01,13:43:10+12”
Test1
OK

AT+CPMS=“SM”,“SM”,“SM”
+CPMS: 1,35,1,35,1,180
OK

AT+CMGL=“ALL”
+CMGL: 0,“REC READ”,“+9054xxxxxxx”,“26/09/01,13:43:10+12”
Test1
OK

Switching to ME:

AT+CPMS=“ME”,“ME”,“ME”
+CPMS: 1,180,1,180,1,180
OK

AT+CMGL=“ALL”
+CMGL: 0,“REC UNREAD”,“+9054xxxxxxx”,“26/09/01,13:43:10+12”
Test1
OK

So there is one copy in SM and one copy in ME, both with the same SCTS (26/09/01,13:43:10+12).

The read status differs between the two copies: listing SM marked its copy as REC READ, while the ME copy was still REC UNREAD afterwards. This confirms these are two distinct stored records, not the same record listed twice.

I also noticed that AT+CPMS=“SM”,“SM”,“SM” returns 1,180 for the third pair, so mem3 appears to stay on ME and does not accept “SM”.

-– Questions —

  1. Do the two +CMTI URCs mean the network actually delivered the SMS-DELIVER twice, or is this a firmware storage behaviour that writes a single delivery into both SM and ME?

  2. With factory default settings on this firmware, is AT+CNMA acknowledgement required? What are the default CSMS and CNMI values on EG915N, and can a missing CNMA cause the network to re-deliver?

  3. Could this be related to SMS over IMS and CS/SGs delivery running in parallel? Is there a recommended AT+QCFG setting for SMS format or IMS on this module?

  4. Why does mem3 not accept “SM” in AT+CPMS? Is mem3 restricted to ME on EG915N?

  5. Is there a newer firmware release that addresses duplicate SMS delivery or storage behaviour?

Any guidance would be appreciated. I can provide raw PDU output (AT+CMGF=0, AT+CMGL=4) of both records or a full AT log if that helps.

Thank you.

2

Hi Selim,

Thank you for the detailed information.

Based on the observed behaviour, the two +CMTI URCs together with one SMS stored in SM and another in ME indicate that the module is processing the SMS as two separate storage events. This can be related to duplicate delivery from the network, for example through different SMS delivery paths such as IMS and CS/SGs, or a network-side retransmission.

Regarding AT+CNMA, with the factory default AT+CSMS=0 and AT+CNMI=2,1,0,0,0, CNMA acknowledgement is not required. The module handles the acknowledgement internally when the SMS is stored and reported through +CMTI. Therefore, a missing AT+CNMA under the default configuration should not cause SMS re-delivery.

For troubleshooting, you can temporarily disable IMS with:

AT+QCFG="ims",2

Then reboot the module and check whether the duplicate SMS behaviour still occurs. If the duplication disappears, this would indicate that IMS/CS-SGS SMS handling may be involved.

Regarding mem3, the EG915N firmware restricts the received-message storage to ME, which is why the third parameter remains at a capacity of 180 even after AT+CPMS="SM","SM","SM".

I have sent the latest firmware to your email. Please check your email and use it for testing.