EG25 SMS CMCS operation in CMGS PDU mode

Hello, I’m trying to handle large messages via SMS by sending a chain of PDUs to an EG25.

Sending single PDUs via the AT+CMGS=, cr/lf, wait for “>” send the PDU, send cntl-z mechanism works fine.

Long message segmentation (CMCS) is not working for me. TS 27.005 and TS 23.040 are somewhat vague about how the AT interface is used for CMCS PDUs.

My assumption is that I should send each PDU using the same mechanism as I do for single PDU and that the modem should give me a response for each AT+CMGS command sequence. Instead I get no response after I send cntl-z and after a few minutes will get and error 350 from the modem.

The Gemini AI has suggested that the mechnism is:

  • Send the first PDU using the “AT+CMGS=, cr/lf, wait for “>” send the PDU, send cntl-z” mechanism
  • Send the remaining PDUs each followed by a cntl-z and the modem will detect when it has recveived the last PDU in the chain.
    The gemini method eventually gets an error 304.

Below are 2 PDUs I’ve used for testing.
0055000B917130359791F00008A84105003302010046006F007200200063006F006E0063006100740065006E00610074006500640020006D0065007300730061006700650073002C00200074006800650020006D00

0051000B917130359791F00008A80B05003302026100780069006D0075006D

Does the EG-25 support SMS-CMCS? If so, how should the PDUs be sent? Do you see a problem in the way the PDUs are encoded?

May thanks,
Ken

Correction. AT commands are terminated by the single <CR> character. There should be no <LF> present.

You must implement payloads of >140 bytes as concatenated. You will need to split the message into numbered parts, and encode those parts correctly as User Data Headers, reducing the actual message payload per message part. You must turn the UDHI bit on in the PDU-type octet as well.

Each message part is a stand-alone SMS as far as the modem is concerned. They are sent and received as such.

You must choose between using 8-bit and 16-bit message reference numbers.

See 3GPP 27.040, section 9.2.3.24.1 and other appropriate sections.

Every make and model of cellular modem supports concatenated messages in PDU-mode. Implementation is entirely in the hands of the programmer, and not the modem.

You’ll likely appreciate help along the way.

I should have had a good look at your PDUs before my earlier reply. I see that you understand about concatenated messages, and have tried to code this.

It appears to me that you’ve not got the User Data field correct. The modem will have failed the PDU on a simple syntax check.

You’ve given 0x41 (65 decimal) as the User Data Length. Because you’re using 8-bit (unicode) data, this should be the total number of bytes/octets following the UDL. But it’s not.

There may be other problems in the UDH, and I’ll be checking further as and when I get time.

1 Like

Thanks, but don’t put too much effort into this. I’ve found a nice PDU library that seems to do a mu better job at encoding for CMCS.
Ken

This is your UDH length and content.

05
00
33
02
01
00

I expect it to look more like this one I decoded from elsewhere:

05	UDHL: the next 5 octets are UDH (header)
00	concatenated message using 8-bit numbering
03	information element length (3 octets follow)
1F	concatenated message number 1F hex (31 decimal)
02	there are 2 parts to this message
01	this is part 1
1 Like

Many thanks! That is very useful. I had hoped that the gemini AI generated code would be closer to the spec than it was. I should have broken down the UDH myself.