The hex data are QMI messages without the QMUX header, and is trivial to decode if you have the spec. The Qualcomm docs are not publicly available, but the open source they contributed through the Code Aurora project is. The libqmi project is a good reference, having both the original Code Aurora source and the extrated protocol data in json format: freedesktop.org/wiki/Software/libqmi/
The interesting part of QMUX is already decoded so it isn’t any problem that this is missing: We know that the service is DMS. There is also some redundant decoded info there - the transaction (response) ID are bytes 2 and 3 in Little Endian: 0x002B = 43
The next 2 bytes are the message ID (all multibyte numbers are in LE): 0x5558. I believe this is a vendor specific message (standard messages have much lower IDs), so we don’t have any docs for it. But we can still figure out something based on the message structure. The 2 bytes following the message ID give the length of the rest of the message (TLV data). And as you can see, there are exactly 0x0025 = 37 remaining bytes after the length. Those remaining bytes are a sequence of TLVs having 1 type byte, 2 length bytes and type specific data.
So the first TLV is “02 04 00 00 00 00 00”. This type 0x02 TLV is special, having the same meaning in most QMI messages. It has always length = 4, divided in a 2-byte status and a 2-byte error code. All zeroes, as here, means “success”. You should see this pattern in most QMI responses, and it is a great way to figure out where the message starts and ends as it is usually (always?) the first TLV.
Then there are two message specific TLVs, both with 12 bytes data: 0x11 and 0x10. I don’t know the meaning of those. You’d need the spec of DMS message 0x5558 for that.
But decoding messages with SMS data this way should be possible. Those messages are standard so you can use libqmi as a reference. Look for “WMS”, not “DMS”. DMS is for device management and is useless for your purpose. WMS is the service dealing with SMS. If you find any WMS message id 0x0022 responses in the log, then those are good candidates.
Note that the actual message data most likely is coded as 7bit GSM PDUs, so you’ll have to decode that further after having extracted it from the log. But there are tools for that.