SMS Failure Vodafone Ireland on LTE

Our config works fine on UK LTE networks, sending SMS on LTE. Vodafone Ireland has working VoLTE but there is no SMS service using the EG91. The SIM can send SMS using 2G but we need a solution to IMS/LTE SMS.

If we force the module to 2G or 3G at+cmgs works. However, on LTE, the modem waits the full timeout period and returns CMS error 350.

We can no longer set the sms_domain_pref to use CS as Vodafone Ireland have closed their 3G network.

I’ve tried a number of things but I’ve run out of ideas. I suspect other territories’ Vodafone networks may have similar issue.

at+qcfg=“ims”
+QCFG: “ims”,1,1

Following up on the possibility that Vodafone is using IMS for SMS transport on LTE, what do these AT commands return?

AT+QMBNCFG="List"
AT+CGDCONT?
AT$QCPDPIMSCFGE?
AT+CGPADDR

I can’t answer these in full as I’m back in the UK.

I selected the vodafone Germany mbn and set at+cereg=2 to observe network changes. It successfully sent SMS on LTE without changing network. However, with this mbn the VoLTE doesn’t work. The VoLTE works fine on Vodafone Ireland with the ROW_default file.

The CGDCONT is identical apart from the SOS context missing from the Vodafone Germany mbn setup. I tried deleting this from the ROW mbn setup and obviously it did nothing.

My plan is to go through every config setting and compare the ROW setup to the Vodafone Germany setup to see if I can find the difference. Ideally though there would be a way to simply decide the mbn file to see what’s in there. Is that possible?

Make sure you have “ims” set as the APN for context 2.

Then ensure IMS is enabled for that context using:

AT$QCPDPIMSCFGE=2,1

A hard modem reset may be required for that to take effect.

Then the AT+CGPADDR command should show context 2 active (with an IP address).

These are steps I took to get SMS working over NR5G on Vodafone Australia. They use IMS for NR5G here, but not for LTE.

ims is definitely set in both configurations as context 2. It must be working as the VoLTE works and it receives messages when locked onto LTE. It just cannot successfully send messages on LTE with this network.
The same configuration works fine on UK EE and 3 with ims on context 2.
It’s just odd the way it works with the German mbn file but the VoLTE doesn’t work.

Are you sure those networks are using IMS for SMS on LTE?

If IMS, are they using the same MBN file?

I have more than a passing interest in this, as I’m the lead developer/maintainer for the SMS subsystem of the ROOter project. We aim to support SMS (PDU-mode) on all modems and world networks.

There’s always the possibility that you’re up against an obscure modem firmware bug.

My Quectel RM500Q-AE with Vodafone AU SIM also auto-selects the “Germany-VoLTE-Vodafone” MBN file when Autosel is enabled.

I’ve manually selected its generic MBN file “ROW_Commercial” instead for testing.

With the “ims” APN in context 2, and IMS enabled on context 2 with AT$QCPDPIMSCFGE=2,1 I find that context 2 does get an IP address:

AT+CGPADDR
+CGPADDR: 1,"100.72.190.158"
+CGPADDR: 2,"2405:6E00:02C0:FF8D:6D83:40AB:C562:7641"
+CGPADDR: 3,""
OK

I can both send and receive SMSs via IMS over NR5G with this configuration.

Hi I went back to Ireland…

Both the context 1 and 2 have IPV4 IP addresses and the VoLTE works with the:

AT+QMBNCFG=“Select”,“ROW_Generic_3GPP”

…binary file. The SMS doesn’t. It receives SMS via LTE it just encounters an error sending them.

I need to make my own MBN file as there is no way of setting this, for example, via AT commands:

“QpImsRegConfigDb”: {
“Version”: 3,
“Items”: [
{
“Rat”: 272,
“ApnIndex”: 17,
“ImsServiceInfoString”: “VoLte_Vt_Sms”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},

It’s nothing to do with the IP network/PDP settings. It entirely to do with the detailed ims settings specifically for the SMS

You’ve dug deeper into this than I did, and it looks like you’ve uncovered the cause.

Short of there being an undocumented AT command to overrule this “ImsServiceInfoString” setting, it does look like the only solution is via MBN file content.

Thank you for sharing your findings.

I’m currently working on a SIMCom modem showing exactly this behaviour with a SIM from a provider who’s switched to using IMS for SMS. Receiving works, but sending doesn’t.

I’ve been looking at the binary files for phones. They’re for this chipset but there is loads of data in them for things like the screen setup and video amongst other phone specific items. They won’t work.

I’ve asked for the ROW_commercial_3GPP file from Quectel. A lot of the binary stuff can remain the same as it sets the /NV/items… Settings which you can do with an AT command.

There is specific stuff to do with the SMS though that is different depending on the country even though it’s all Vodafone and it’s written in XML format so can be edited. I’m sure I can get it working if I have a template for these modems.

I’ll try and grab it from the file system of they can’t supply it. I just didn’t have my board with the USB connector on it today. Just the UART.

I got this working. There are a few ways. If your VoLTE works but your SMS doesn’t you can fix it with just some NV write commands. You don’t really need the binary file. Which network is it?

I’ve generally used the ROW_Generic_3GPP file and added NV items. For example the ‘ims_operation_mode’ and ‘qp_ims_reg_config_db’ can be added with just AT+QNVWR…

I also found some binary files which load but do not activate. Still they set up all of the required NV items. Because of the way our system works it’s easier to remotely send NV items than complete binary files so I’ve not used them.

I think I could get the required nv commands for your network from the binary files.

Could you please give a worked example where you succeeded for us to use as a basis?

I support SMS for use on many providers around the world.

Well it’s not easy. I’m still exploring differences between ROW_Generic_3GPP and a phone mbn for Vodafone UK. The phone mbns sometimes load but don’t activate and leave missing NV items. I think you can get everything working with the ROW_generic file by changing the NV items with AT+QNVFW command.

I found with UK Vodafone you have to set the ims_reg_config_db in order to receive SMS via IMS. It’s different from the ROW_generic

To add the items below you need to send:

at+qnvfw=“/nv/item_files/ims/qp_ims_reg_config_db”,0310011105000000882000006702110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010033005000000883000000052000000920000

You also need to understand the format of this item in order to go from the nice json string to the hex above. You can see the version is easy (just 1-byte hex).

The 272 is 1001 (it’s little endian) so is: 0110 which is 272 in hex. The “VoLte_Sms” is represented by 05 and VoLte_Vt_Sms is 07…

You’ll need to active the ROW_Generic file and often you’ll need to reset everything with:

at+qprtpara=3
at+qnvfr=“/nv/item_files/ims/qp_ims_reg_config_db” << you can’t just read then write this because the mostly unused APN characters make it too long.

It’s best to work on a network by network basis.

“QpImsRegConfigDb”: {
“Version”: 3,
“Items”: [
{
“Rat”: 272,
“ApnIndex”: 17,
“ImsServiceInfoString”: “VoLte_Sms”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 8328,
“ApnIndex”: 0,
“ImsServiceInfoString”: “26368”,
“AuthSecType”: 2,
“IpTypeInfo”: 17
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
},
{
“Rat”: 0,
“ApnIndex”: 0,
“ImsServiceInfoString”: “None”,
“AuthSecType”: 0,
“IpTypeInfo”: 0
}
],
“Items2”: [
{
“RatApnFallback”: 0,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 0,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 0,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 0,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 0,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 0,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 0,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 4096,
“ServicePriorityWwan”: 12291
},
{
“RatApnFallback”: 5,
“ServicePriorityWwan”: 0
},
{
“RatApnFallback”: 12424,
“ServicePriorityWwan”: 0
}
],
“AllowedImsSrvOnWlanString”: “20992”,
“AddAllFTs”: 0,
“AcsPriority”: 0,
“ISimPriority”: 0,
“NvPriority”: 146,
“PcoPriority”: 0,
“ImsServiceStatus”: 0,
“ApnNames”: [
“”,
“”,
“”
],

By the way I’m also the original poster Michael Beaver

Thanks for this. I’ve bookmarked it, and hope I don’t have to use it.