Dial x402

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.

TermDefinition
PSTNThe worldwide public telephone network, interconnecting landline, mobile, and VoIP carriers
Circuit switchingA dedicated communication path established for the duration of a call
Packet switchingData broken into packets routed independently across a shared network
Signaling planeThe 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

NodeFull NameRole
SSPService Switching PointOriginates and terminates signaling messages; typically the mobile switching center (MSC) or local exchange
STPSignal Transfer PointRoutes SS7 messages between nodes; acts as a signaling router
SCPService Control PointDatabase node that provides call-handling logic (e.g., toll-free number lookup, local number portability)
SMSCShort Message Service CenterStores, routes, and forwards SMS messages; the core relay for all SMS traffic
HLRHome Location RegisterMaster database of all subscribers on a mobile network — stores IMSI, service profile, and current VLR location
VLRVisitor Location RegisterTemporary database at each MSC holding subscriber records for currently attached (roaming or local) users

Key SS7 Protocol Layers for SMS

ProtocolFull NameFunction
MAPMobile Application PartProvides operations for SMS delivery, HLR/VLR interrogation, subscriber authentication, and location updating
TCAPTransaction Capabilities Application PartSupports remote procedure calls between SS7 nodes; MAP messages are carried inside TCAP transactions
SCCPSignaling Connection Control PartProvides logical addressing (Global Titles) and connectionless/connection-oriented transport for TCAP/MAP
MTPMessage 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 Handset

What 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:

  1. Bind — The ESME authenticates with the SMSC. The bind type determines message direction:

    • bind_transmitter — send only
    • bind_receiver — receive only
    • bind_transceiver — send and receive on the same connection
  2. Submit — The ESME sends a submit_sm PDU 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.

  3. Submit Response — The SMSC responds with submit_sm_resp, returning a message ID that can be used to correlate delivery receipts.

  4. Delivery — When a mobile-originated message arrives for the ESME, or when the SMSC has a delivery receipt, it sends a deliver_sm PDU to the ESME.

  5. Enquire Link — Periodic heartbeat PDUs (enquire_link / enquire_link_resp) keep the TCP session alive and detect stale connections.

  6. Unbind — Graceful session teardown.

Key SMPP PDUs

PDUDirectionPurpose
bind_transceiverESME → SMSCAuthenticate and open bidirectional session
submit_smESME → SMSCSubmit an outbound SMS for delivery
submit_sm_respSMSC → ESMEAcknowledge submission, return message ID
deliver_smSMSC → ESMEDeliver an inbound SMS or delivery receipt to the application
deliver_sm_respESME → SMSCAcknowledge receipt of delivered message
enquire_linkEither directionKeepalive heartbeat
unbindEither directionGracefully 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.

PropertySMSOTT Messaging
TransportSS7 signaling network (carrier-operated)Public internet (TCP/TLS, WebSocket, QUIC)
AddressingE.164 phone number (MSISDN)Phone number, email, username, or device token
Store-and-forwardSMSC (carrier-operated)Cloud servers operated by the app provider
EncryptionNone (plaintext within carrier network)End-to-end encryption (Signal Protocol for WhatsApp/Signal; iMessage uses custom E2E scheme)
Max message size160 characters (7-bit GSM) / 140 bytesEffectively unlimited (text, images, video, files)
Recipient requirementsAny mobile phone with carrier serviceBoth parties must have the same app installed (or RCS-capable device)
Delivery guaranteeHigh — reaches any mobile number globallyDepends on recipient having the app, internet access, and compatible platform
Carrier dependencyFully dependent on carrier infrastructureIndependent; 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

  1. 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.

  2. 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.

  3. 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.

  4. 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 → Recipient

For 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 TypeFormat ExampleRegistrationTypical Use
Local 10DLC+1 (512) 555-0199TCR brand + campaignA2P messaging, customer notifications
Toll-free+1 (800) 555-0199Toll-free verificationCustomer support, 2FA, marketing
Short code55555CSCA short code applicationHigh-volume alerts, two-factor authentication
Alphanumeric senderMYCOMPANYCarrier-specific approvalOne-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.

On this page