How SMS Works: PSTN, SS7, and Message Routing Explained
A technical guide to how SMS messages travel through the PSTN, SS7 signaling, SMSC routing, SMPP protocol, and how virtual numbers connect to carrier networks.
How SMS Works
SMS (Short Message Service) is a text messaging protocol defined by the 3GPP standards body as part of the GSM mobile communications system. Despite being over 30 years old, SMS remains the only text channel with near-universal handset reach — no app install, no internet connection, and no account required on the recipient side. Understanding how SMS works at the network level is essential for anyone building programmable telecom, evaluating message deliverability, or architecting A2P messaging systems.
What Is the PSTN?
The Public Switched Telephone Network (PSTN) is the global collection of interconnected circuit-switched and packet-switched networks operated by telephone carriers. Originally built for analog voice, the PSTN now carries voice, fax, data, and signaling traffic across copper, fiber, microwave, and satellite links.
SMS does not travel over the voice channel. Instead, it uses the signaling plane of the PSTN — specifically the SS7 network — to transfer short text payloads between network nodes.
| Term | Definition |
|---|---|
| PSTN | The worldwide public telephone network, interconnecting landline, mobile, and VoIP carriers |
| Circuit switching | A dedicated communication path established for the duration of a call |
| Packet switching | Data broken into packets routed independently across a shared network |
| Signaling plane | The out-of-band control channel used for call setup, teardown, and supplementary services like SMS |
What Is SS7?
Signaling System 7 (SS7) is the set of telephony signaling protocols that control call setup, number translation, local number portability, prepaid billing, and SMS routing across the PSTN. SS7 operates on a separate network from the voice/data bearer channels.
SS7 Network Nodes
| Node | Full Name | Role |
|---|---|---|
| SSP | Service Switching Point | Originates and terminates signaling messages; typically the mobile switching center (MSC) or local exchange |
| STP | Signal Transfer Point | Routes SS7 messages between nodes; acts as a signaling router |
| SCP | Service Control Point | Database node that provides call-handling logic (e.g., toll-free number lookup, local number portability) |
| SMSC | Short Message Service Center | Stores, routes, and forwards SMS messages; the core relay for all SMS traffic |
| HLR | Home Location Register | Master database of all subscribers on a mobile network — stores IMSI, service profile, and current VLR location |
| VLR | Visitor Location Register | Temporary database at each MSC holding subscriber records for currently attached (roaming or local) users |
Key SS7 Protocol Layers for SMS
| Protocol | Full Name | Function |
|---|---|---|
| MAP | Mobile Application Part | Provides operations for SMS delivery, HLR/VLR interrogation, subscriber authentication, and location updating |
| TCAP | Transaction Capabilities Application Part | Supports remote procedure calls between SS7 nodes; MAP messages are carried inside TCAP transactions |
| SCCP | Signaling Connection Control Part | Provides logical addressing (Global Titles) and connectionless/connection-oriented transport for TCAP/MAP |
| MTP | Message Transfer Part (Levels 1–3) | Physical, data link, and network layers of the SS7 stack; handles reliable hop-by-hop message transfer |
In summary: an SMS-related MAP operation is wrapped in a TCAP transaction, transported by SCCP using Global Title addressing, and routed across the SS7 network by MTP.
How Does an SMS Travel from Sender to Recipient?
The following sequence describes a standard mobile-originated, mobile-terminated (MO-MT) SMS delivery over a GSM/UMTS network.
Step 1 — Radio Access (Sender → BSC)
The sender's handset composes an SMS and transmits it over the radio interface (Um) to the nearest Base Transceiver Station (BTS). The BTS forwards the message to the Base Station Controller (BSC), which manages radio resources for a cluster of towers. SMS uses the SDCCH (Stand-alone Dedicated Control Channel) or SACCH (Slow Associated Control Channel), not the traffic channel used for voice.
Step 2 — MSC Ingestion (BSC → MSC)
The BSC forwards the SMS to the originating Mobile Switching Center (MSC) over the A interface. The MSC authenticates the sender via the VLR and prepares the message for relay to the SMSC.
Step 3 — SMSC Store-and-Forward (MSC → SMSC)
The MSC sends the SMS to the operator's Short Message Service Center (SMSC) using the MAP mo-ForwardSM operation over SS7. The SMSC is a store-and-forward system: it accepts the message, timestamps it, and assumes responsibility for delivery. If delivery fails on the first attempt, the SMSC queues the message and retries according to a configurable schedule (typically up to 72 hours).
Step 4 — HLR Lookup (SMSC → HLR)
The SMSC queries the Home Location Register (HLR) of the recipient's home network using the MAP sendRoutingInfoForSM operation. The HLR returns:
- The IMSI (International Mobile Subscriber Identity) of the recipient
- The MSC/VLR address where the recipient is currently registered
If the recipient is roaming on a visited network, the HLR returns the visited MSC address.
Step 5 — Delivery to Recipient MSC (SMSC → Recipient MSC)
The SMSC forwards the SMS to the recipient's serving MSC using the MAP mt-ForwardSM operation, addressing it via the Global Title returned by the HLR.
Step 6 — Paging and Radio Delivery (MSC → BTS → Handset)
The recipient's MSC pages the handset through the BSC/BTS infrastructure. Once the handset responds, the MSC delivers the SMS over the signaling channel. The handset sends an acknowledgment back through the same path.
Step 7 — Delivery Report (Recipient MSC → SMSC → Sender)
The recipient MSC returns a delivery status to the SMSC. If the sender requested a status report (TP-SRR flag), the SMSC generates a delivery receipt and routes it back to the originating MSC for delivery to the sender's handset.
End-to-End Delivery Summary
Sender Handset
│ (radio / SDCCH)
▼
BTS → BSC
│ (A interface)
▼
Originating MSC/VLR
│ (SS7 MAP: mo-ForwardSM)
▼
SMSC ──── store & queue
│ (SS7 MAP: sendRoutingInfoForSM)
▼
HLR ──── returns recipient MSC address
│
▼
SMSC
│ (SS7 MAP: mt-ForwardSM)
▼
Recipient MSC/VLR
│ (paging + radio delivery)
▼
BTS → BSC
│ (radio / SDCCH)
▼
Recipient HandsetWhat Is the SMPP Protocol?
SMPP (Short Message Peer-to-Peer) is the standard protocol used by applications, aggregators, and CPaaS platforms to inject messages into an SMSC for delivery over the carrier network. While SS7/MAP handles message routing within the carrier infrastructure, SMPP is the external interface through which software systems interact with that infrastructure.
How SMPP Works
An SMPP session operates over TCP/IP between an ESME (External Short Messaging Entity) — the application — and the SMSC. The session lifecycle follows this pattern:
-
Bind — The ESME authenticates with the SMSC. The bind type determines message direction:
bind_transmitter— send onlybind_receiver— receive onlybind_transceiver— send and receive on the same connection
-
Submit — The ESME sends a
submit_smPDU containing the source address, destination address, message body (up to 140 bytes per segment), encoding, and optional parameters like validity period and delivery receipt request. -
Submit Response — The SMSC responds with
submit_sm_resp, returning a message ID that can be used to correlate delivery receipts. -
Delivery — When a mobile-originated message arrives for the ESME, or when the SMSC has a delivery receipt, it sends a
deliver_smPDU to the ESME. -
Enquire Link — Periodic heartbeat PDUs (
enquire_link/enquire_link_resp) keep the TCP session alive and detect stale connections. -
Unbind — Graceful session teardown.
Key SMPP PDUs
| PDU | Direction | Purpose |
|---|---|---|
bind_transceiver | ESME → SMSC | Authenticate and open bidirectional session |
submit_sm | ESME → SMSC | Submit an outbound SMS for delivery |
submit_sm_resp | SMSC → ESME | Acknowledge submission, return message ID |
deliver_sm | SMSC → ESME | Deliver an inbound SMS or delivery receipt to the application |
deliver_sm_resp | ESME → SMSC | Acknowledge receipt of delivered message |
enquire_link | Either direction | Keepalive heartbeat |
unbind | Either direction | Gracefully close the SMPP session |
SMPP version 3.4 is the most widely deployed. Version 5.0 exists but has limited carrier adoption. Most CPaaS providers (Twilio, Sinch, Telnyx, Vonage) abstract SMPP behind REST APIs, but direct SMPP connectivity remains common for high-volume senders and aggregators.
How Do OTT Messaging Apps Differ from SMS?
OTT (Over-The-Top) messaging applications like iMessage, WhatsApp, Signal, Telegram, and Google Messages (RCS) bypass the PSTN signaling infrastructure entirely. Instead of routing through SMSCs and SS7 nodes, OTT messages travel over the public internet using proprietary or standardized IP protocols.
| Property | SMS | OTT Messaging |
|---|---|---|
| Transport | SS7 signaling network (carrier-operated) | Public internet (TCP/TLS, WebSocket, QUIC) |
| Addressing | E.164 phone number (MSISDN) | Phone number, email, username, or device token |
| Store-and-forward | SMSC (carrier-operated) | Cloud servers operated by the app provider |
| Encryption | None (plaintext within carrier network) | End-to-end encryption (Signal Protocol for WhatsApp/Signal; iMessage uses custom E2E scheme) |
| Max message size | 160 characters (7-bit GSM) / 140 bytes | Effectively unlimited (text, images, video, files) |
| Recipient requirements | Any mobile phone with carrier service | Both parties must have the same app installed (or RCS-capable device) |
| Delivery guarantee | High — reaches any mobile number globally | Depends on recipient having the app, internet access, and compatible platform |
| Carrier dependency | Fully dependent on carrier infrastructure | Independent; uses IP layer only |
SMS remains the universal fallback. When iMessage detects that a recipient does not have an Apple device, it falls back to SMS. Google Messages falls back from RCS to SMS when the recipient's carrier or device does not support RCS. This fallback behavior is why SMS continues to serve as the lowest-common-denominator messaging channel.
How Do Virtual Phone Numbers Connect to the PSTN?
A virtual phone number (also called a DID — Direct Inward Dialing number) is a telephone number that is not directly associated with a physical phone line or SIM card. Instead, it is routed programmatically by a CPaaS (Communications Platform as a Service) provider or carrier to an application endpoint via API, SIP, or SMPP.
How DID Provisioning Works
-
Number acquisition — The CPaaS provider leases number blocks from carriers or obtains them from the national numbering plan authority (e.g., NANPA in North America). Numbers may be local, toll-free, or short codes.
-
PSTN routing — The provider configures the carrier's SS7/SIP infrastructure so that calls and SMS destined for the DID route to the provider's platform rather than a physical phone.
-
Application binding — The developer maps the DID to application logic via the provider's API — for example, forwarding inbound SMS to a webhook URL or SMPP connection.
-
Outbound origination — When the application sends an SMS from the DID, the provider's SMSC injects the message into the carrier network with the DID as the source address (MSISDN). The receiving carrier sees the message as originating from a real phone number.
DID Integration Path
Application (REST API / SMPP)
│
▼
CPaaS Platform (Twilio, Telnyx, Sinch, Vonage)
│
▼
Aggregator / Direct carrier interconnect
│ (SMPP or SS7)
▼
Carrier SMSC
│ (SS7 MAP)
▼
PSTN → RecipientFor SMS specifically, the CPaaS provider must comply with carrier registration requirements. In the United States, 10-digit long code (10DLC) numbers used for A2P messaging must be registered with The Campaign Registry (TCR), and the provider must submit brand and campaign information before carriers will allow traffic to flow at A2P throughput levels.
Number Types and Their PSTN Characteristics
| Number Type | Format Example | Registration | Typical Use |
|---|---|---|---|
| Local 10DLC | +1 (512) 555-0199 | TCR brand + campaign | A2P messaging, customer notifications |
| Toll-free | +1 (800) 555-0199 | Toll-free verification | Customer support, 2FA, marketing |
| Short code | 55555 | CSCA short code application | High-volume alerts, two-factor authentication |
| Alphanumeric sender | MYCOMPANY | Carrier-specific approval | One-way branded messaging (not available in US/CA) |
Limitations and Failure Modes
SMS was designed in the 1980s as a secondary use of the signaling channel and carries several inherent constraints:
- 160-character limit — A single SMS segment holds 160 characters in 7-bit GSM encoding or 70 characters in UCS-2 (Unicode). Longer messages are split into multiple segments using the User Data Header (UDH) concatenation mechanism, each consuming a full SMS slot.
- No encryption — SMS content is transmitted in plaintext across every network hop. Carrier employees, SS7 interconnect partners, and law enforcement (via lawful intercept) can read message content.
- SS7 vulnerabilities — The SS7 network was designed with implicit trust between operators. Attackers with SS7 access can intercept SMS messages, track subscriber locations, and perform denial-of-service attacks. This is a known and well-documented risk for SMS-based two-factor authentication.
- Store-and-forward expiry — If the SMSC cannot deliver a message within the validity period (typically 24–72 hours), the message is discarded without further notification.
- Carrier filtering — A2P messages are subject to content-based and reputation-based filtering by carrier spam detection systems. Messages flagged as spam are silently dropped.
Further Reading
- CPaaS & Aggregator Stack — The full routing chain from API call to carrier delivery, including aggregator tiers and interconnect models.
- What Is A2P SMS? — Application-to-person messaging classification, regulatory treatment, and how carriers distinguish A2P from P2P traffic.
SMS & Telecom Knowledge Base
In-depth guides on SMS infrastructure, carrier filtering, 10DLC registration, TCPA compliance, and programmable telecom for developers and businesses.
What Is A2P SMS? Application-to-Person Messaging Explained
Learn what A2P SMS is, how it differs from P2P messaging, regulatory requirements under TCPA, 10DLC registration mandates, and common A2P use cases.