What SMS is, and why it still matters
- Works on every phone. No app, no data plan, no account. If the SIM is registered, it can receive SMS. This is because SMS rides on the signalling channels of the network, not the voice or data channels.
- A2P traffic dominates. OTP codes, banking alerts, delivery notices, appointment reminders — sent by applications, not people.
- Built on trust. Designed in the 1980s for a closed club of operators. That legacy shapes routing, fraud and security to this day.
A short history
- 1984 — Friedhelm Hillebrand tests typical messages; almost all fit in 160 characters ("perfectly sufficient").
- 1992 — First SMS, "Merry Christmas", sent by Neil Papworth from a PC to a phone on Vodafone.
- 1993 — Nokia ships the first phones that can send SMS (same network only).
- 1994 — First A2P: Vodafone UK sends share-price alerts to business users.
- 1999 — SMS works between different operators; texting explodes.
Store and forward: the SMSC owns the message
The SMSC is the post office. The core principle has four steps: 1. Accept — the SMSC acks the sender as soon as the message is stored. 2. Attempt — it looks up the recipient and tries delivery. 3. Retry — on temporary failure it keeps the message and retries, or waits for an "alert" that the phone is back. 4. Expire — it drops the message when the validity period runs out.
"Accepted" by the SMSC never means "delivered" to the phone. That gap is exactly what delivery reports (DLRs) are for.
The six SMS message types (3GPP TS 23.040, transfer layer)
| TPDU | Direction | Purpose |
|---|---|---|
| SMS-SUBMIT | Handset → SMSC | Sender submits a new message |
| SMS-SUBMIT-REPORT | SMSC → handset | Ack or error for the submission |
| SMS-DELIVER | SMSC → handset | The message arriving at the recipient |
| SMS-DELIVER-REPORT | Handset → SMSC | Recipient's ack or error |
| SMS-STATUS-REPORT | SMSC → handset | Delivery report back to the original sender |
| SMS-COMMAND | Handset → SMSC | Operation on a stored message (e.g. delete) |
Message structure, encoding and billing
One SMS carries 140 octets (1120 bits) of user data. How many characters that is depends on the encoding:
| Encoding | DCS | Single SMS | Per part (concatenated) | Use |
|---|---|---|---|---|
| GSM-7 (7-bit) | 0x00 | 160 chars | 153 chars | Plain Latin text — default, cheapest |
| 8-bit binary | 0x04 | 140 bytes | 134 bytes | Binary payloads, OTA / provisioning |
| UCS-2 (Unicode) | 0x08 | 70 chars | 67 chars | Non-Latin scripts, emoji |
One emoji or one non-GSM character turns the whole message into UCS-2, so 160 → 70 characters. That is the #1 cause of "why did my message cost 3 SMS?".
UDH (User Data Header) — when a message is longer than one SMS, 7 octets at the start of each part carry the concatenation info: a reference number, the total number of parts, and this part's sequence number. The handset reassembles the parts. So a 400-character GSM-7 message = 3 parts (153 + 153 + 94) = 3 billable SMS.
Billing models: - Per Submit — pay for every accepted segment, delivered or not. - Per Delivered — pay only for segments confirmed by a DLR.
Billing disputes usually come from: encoding (segment miscount, often an emoji), client campaigns (long texts/emoji → more segments), or a real platform discrepancy (escalate). The fix is always: compare CDRs (submitted vs delivered) against the invoice.
A2P vs P2P — know the difference cold
| P2P (person-to-person) | A2P (application-to-person) | |
|---|---|---|
| Sender | subscriber with a SIM | business system |
| Volume | a few a day | thousands to millions |
| Direction | two-way | almost entirely one-way |
| Content | unique each time | templated, repetitive |
| Recipients | people they know | lists, no relationship |
| Priced as | consumer bundle | wholesale termination |
| Network via | operator's own SMSC | aggregators, carriers (us) |
This distinction is the heart of SMS fraud: fraudsters try to send A2P traffic at P2P prices (grey routes, SIM farms).
Remember this (Module 1): SMS rides signalling channels, works on any phone, and is store-and-forward — "accepted" ≠ "delivered". 140 octets per SMS: 160 GSM-7 / 70 UCS-2 chars; one emoji makes the whole message Unicode. Long messages split via UDH into billable parts. A2P = business bulk at wholesale price; P2P = people at consumer price.