Help
Frequently Asked Questions
Messaging basics for integrators and enterprise customers
What is SMPP?
SMPP (Short Message Peer-to-Peer) is a binary protocol used by applications, aggregators, and enterprises to inject and receive SMS traffic with a mobile operator or SMS hub. Instead of sending messages through a web form, your platform opens a persistent TCP session (a bind) to the SMSC and exchanges PDUs (protocol data units) for submit, deliver, and status reporting.
Typical SMPP flows:
- Transmitter (TX) — send mobile-terminated (MT) SMS to handsets
- Receiver (RX) — receive mobile-originated (MO) messages and delivery receipts
- Transceiver (TRX) — both directions on one session
Simmcomm supports SMPP 3.4 and 5.0 with configurable throughput, TLS, alphanumeric and numeric sender IDs, and real-time delivery notifications. SMPP is the standard choice for high-volume, low-latency integrations; our REST API offers the same routing for HTTP-based systems.
How do SMS encodings work?
An SMS is not a free-form text field — each message is carried in a fixed-size user data field (140 octets). The alphabet used to represent your text determines how many characters fit in that space. The gateway selects an encoding from the message content (or from options such as transcode_gsm on our API).
GSM-7 (GSM default alphabet)
The most compact encoding. Covers basic Latin letters, digits, and common punctuation as defined in GSM 03.38. Characters in the extension table (for example €, [, ], |) consume two character positions because they require an escape sequence in the septet stream.
UCS-2 (Unicode)
Used when the text contains characters outside the GSM-7 set (for example emoji, Cyrillic, or many accented letters that have no GSM mapping). Each character is encoded as a 16-bit code unit, so capacity is roughly half that of GSM-7.
8-bit (Latin-1 / ISO-8859-1)
Raw 8-bit data — often used for binary payloads or legacy Latin-1 text. Treated as octets rather than a 7-bit character count. Support varies by operator; Simmcomm routes GSM-7 and UCS-2 for typical A2P traffic.
| Encoding | Single SMS | Each part (concatenated) | Notes |
|---|---|---|---|
| GSM-7 | 160 characters | 153 characters | 7 octets reserved for concatenation header in multipart messages |
| UCS-2 | 70 characters | 67 characters | 3 UCS-2 code units (6 octets) used for the header in multipart messages |
| 8-bit Latin-1 | 140 octets | 134 octets | 6 octets reserved for concatenation header |
Use our API /simulate endpoint to preview encoding, segment count, and billing length for a message before sending live traffic.
Concatenated (multipart) SMS
When your text exceeds the single-SMS limit, the handset still shows one continuous message, but the network delivers it as several linked SMS parts. A User Data Header (UDH) is prepended to each part with a concatenation reference (message ID and part index), so the phone reassembles them in order.
Because the header consumes space, each part holds slightly fewer characters than a standalone SMS (see table above). Operators and handsets typically support up to 10 parts per concatenated message (longer chains are possible in the spec but rarely used in practice).
Examples
GSM-7 — 200 characters
- Part 1: 153 characters + UDH
- Part 2: remaining 47 characters + UDH
- Total: 2 SMS parts billed
UCS-2 — 100 characters
- Part 1: 67 characters + UDH
- Part 2: remaining 33 characters + UDH
- Total: 2 SMS parts billed
GSM-7 with extended characters
A message of Hello €€€ counts as 12 characters for length calculation (the three euro signs use the extension table and count as two each), even though it displays as 9 glyphs. Always validate length with the target encoding — not just visible character count.
Maximum practical size (GSM-7, 10 parts)
Up to 1,530 characters (10 × 153) in a standard 10-part concatenated GSM-7 message.