SMS Decoding in MikroTik: PDU, Message Concatenation for Developers

Decoding SMS on MikroTik: Parsing PDU and Concatenating Long Messages

Receiving and processing SMS via MikroTik RouterOS unlocks powerful monitoring and automation features. This article dives into extracting messages using an email script, decoding PDU for accurate text display, and concatenating multi-part SMS. It's tailored for Android app developers seeking a solid technical implementation.

Extracting SMS Data from MikroTik

Starting with RouterOS 7.15, you get full access to SMS details, including PDU (Protocol Data Unit), via the /tool/sms/inbox/print detail command. PDU packs all the metadata and encoded message text. For automation, go with direct API integration using the mikrotik-java library or fetch data via email with a custom script.

The script formats each SMS as a JSON string and emails it to your specified address. Here's a sample entry:

{"phone":"+79011234567","timestamp":"2026-03-09 21:30:51+03:00","message":"some text","pdu":"07919761980644F0040B919720481784F50000623090120315211BF377BB0CA297F17410FDFE06DDDF72F21C34AFC3E16F391D","source":"usb2,0","type":"class-0"}

Your app then parses this JSON, creating Sms objects for further processing.

PDU Structure and Initial Parsing

PDU is a hexadecimal string holding service fields and user data. Decoding kicks off by converting the HEX string to a byte array—after stripping non-hex characters and ensuring even length.

Key steps in initial PDU parsing:

• SMSC (Service Center Address): First byte shows the SMSC address length.
• First Octet: Sets PDU type, including the UDHI flag (User Data Header) for multi-part messages.
• Originating Address: Sender's number, with length and format details.
• PID (Protocol Identifier): Typically 0x00 for standard SMS.
• DCS (Data Coding Scheme): Crucial field dictating text encoding (7-bit, 8-bit, or UCS2).
• SCTS (Service Centre Time Stamp): Timestamp when the message was received.
• UDL (User Data Length): Length of user data, interpreted based on encoding.

Handling Multi-Part Messages and Encodings

If the First Octet has the UDHI flag set (bit 0x40), it's part of a long message. This triggers a User Data Header (UDH) with details for reassembling parts: message ID, total parts, and sequence number.

UDH processing algorithm:

• Determine header length and type (8-bit or 16-bit reference).
• Extract part sequence number for reassembly.
• Adjust data index and text length based on encoding.

For 7-bit encoding, UDH takes up a set number of septets that you skip before decoding text. Use this formula:

private static int getUdhSeptetsCount(int udhLen) {
    return (udhLen * 8 + 6) / 7;
}

For UCS2 and 8-bit, just subtract the header from total data length.

Decoding Message Text

The final step: convert bytes to readable text using DCS. Main encodings and handling:

• UCS2 (UTF-16BE): Triggered by DCS bits 2–3 as 10xx. Decode with StandardCharsets.UTF_16BE.
• 8-bit Data: Matches DCS 01xx, for binary data or alternate encodings.
• 7-bit GSM: Default for Latin and basic chars; needs a custom septet-to-byte unpacker.

Once decoded, display the text in your app or feed it into event notifications and logic.

Key Takeaways

• RouterOS 7.15+ exposes PDU for total SMS control.
• Multi-part messages need UDH handling for proper concatenation.
• DCS field sets text encoding and decoding method.
• Email-script automation streamlines external system integration.
• Proper HEX string cleanup and boundary checks avoid parsing errors.

— Editorial Team