n A2P SMS travels a defined path: your application binds to an SMSC or aggregator over SMPP as an ESME and issues a submit_sm; the SMSC stores the message, queries the destination operator's HLR to locate the subscriber's serving MSC, delivers it to the handset (MT), and returns a delivery receipt back up the same chain. Every hop can degrade delivery, sender ID, or receipt.
Want the one-paragraph version first? See our answer on what an SMSC is. This article is the end-to-end walkthrough behind it.
The cast of characters
Before tracing the path, it helps to name the components and what each does. Three acronyms carry most of the story: the SMSC, the ESME, and the HLR. Two directions matter: MT and MO.
SMSC — the store-and-forward engine
The Short Message Service Centre (SMSC) is the operator-side server that accepts a message, stores it, and forwards it to the recipient — the node defined around the SMS transfer protocol in 3GPP TS 23.040. It is not a dumb relay: it holds the message until the handset is reachable, retries within a validity period, and generates the status report. When you send through an aggregator, you are talking to its SMSC (or a gateway in front of one); the terminating operator runs its own SMSC that performs the final delivery.
ESME — your application on the wire
An External Short Messaging Entity (ESME) is any application that connects to an SMSC to send or receive SMS — your OTP service, your campaign platform, your alerting system. Over SMPP, the ESME opens a persistent TCP session with a bind (transmitter, receiver, or transceiver), then issues submit_sm to send. The SMSC replies with a submit_sm_resp carrying a message_id, and later pushes a deliver_sm back to the ESME for inbound messages and delivery receipts. The ESME is the client; the SMSC is the server.
MT vs MO — which way the message flows
Mobile-Terminated (MT) is a message delivered to a handset — the direction almost all A2P traffic travels: an OTP, an alert, a shipping update landing on a phone. Mobile-Originated (MO) is a message a subscriber sends from a handset, which is how two-way replies, keyword opt-outs, and STOP requests reach your ESME as a deliver_sm. A delivery receipt (DLR) rides the MT return path even though it flows back toward you.
| Component | Role in the delivery path |
|---|---|
| Application / ESME | Your software; binds to the SMSC over SMPP and issues submit_sm to send MT messages |
| SMSC (aggregator side) | Accepts, validates, and stores the message; selects a route to the destination operator; returns the message_id and, later, the DLR |
| Interconnect / SMS hub | Carries the message between the aggregator and the terminating operator across one or more hops |
| Terminating operator SMSC | Receives the message on the operator network and drives final delivery to the subscriber |
| HLR | Home subscriber database; answers 'where is this number served right now?' with the serving MSC/VLR address |
| MSC / VLR | The switch currently serving the subscriber; pages the handset and delivers the MT message |
| Handset (MS) | Receives the message and returns an acknowledgement that becomes the delivery receipt |
Store-and-forward: why the SMSC exists
SMS is asynchronous by design. The recipient may be switched off, out of coverage, or in a call with no signalling window free. Rather than fail, the SMSC accepts the message, persists it, and takes ownership of delivery — this is store-and-forward. It attempts delivery, and if the subscriber is unreachable it queues the message and retries on a schedule until either delivery succeeds or the message's validity period expires. When the network later signals that the handset is available again, the SMSC is prompted to try once more. That durability is the whole point of a message centre, and it is why an SMS 'sent' is not yet an SMS 'delivered' — two states your DLR feed must keep separate.
Trace an A2P SMS from app to handset
Here is the full journey of a single MT message — say, a login OTP sent from a bank in Riyadh to a subscriber on a GCC network — from your code to the phone and back.
- Your application authenticates and opens an SMPP bind to the aggregator/SMSC as an ESME, then sends a submit_sm containing the destination MSISDN, the sender ID, the encoding, and the text.
- The SMSC validates and stores the message, assigns a message_id, and returns it in the submit_sm_resp. At this point the message is accepted, not delivered.
- The SMSC selects a route to the destination operator — ideally a direct interconnect, otherwise a path through one or more SMS hubs.
- The message reaches the terminating operator's SMSC on the destination network.
- That SMSC queries the operator's HLR (a MAP SendRoutingInfoForSM) to find where the subscriber is currently served — the address of the serving MSC/VLR.
- The HLR returns the routing information; the SMSC forwards the message (MT-ForwardSM) to that MSC.
- The serving MSC pages the handset over the radio network and delivers the message (the MT delivery).
- The handset acknowledges receipt; the acknowledgement propagates back and the terminating SMSC generates a delivery report.
- The delivery receipt travels back up the interconnect to the aggregator's SMSC, which pushes it to your ESME as a deliver_sm (or a webhook) carrying the original message_id and a final status.
The signalling steps 5–7 — the HLR lookup and the MT-ForwardSM to the serving switch — happen inside the operator's SS7/Diameter core, using the MAP operations of the mobile network. You never see them directly, but they are the reason a message can be 'accepted' in milliseconds yet take longer to actually land: the terminating network has to locate a moving subscriber before it can deliver.
The HLR: locating a moving subscriber
The Home Location Register is the master database of a subscriber's identity and current whereabouts on their home network. Because people roam and move between switches, the terminating SMSC cannot assume where a number is served — it asks the HLR, which returns the serving MSC/VLR so the message can be forwarded to the right switch. This is the same lookup used, on its own, for number validation: an HLR query tells you whether a number is live, ported, or roaming before you ever send. When routing is clean, that lookup is one internal signalling exchange; when a message crosses several intermediary networks first, the query only happens after all those hops, which adds latency and more points of failure.
Direct routes vs multi-hop aggregation
The path above is the ideal: your ESME to an SMSC that hands off on a direct interconnect to the terminating operator. Reality is often longer. On a multi-hop aggregation route, the message passes through a chain of resellers and SMS hubs before it reaches the destination network — and every hop is a node that can rewrite, delay, or drop something. Three things degrade as hops accumulate:
- Reliability: each intermediary is another queue, another firewall, and another party whose route to the operator may be a grey route that gets blocked without warning. More hops means more variance in delivery rate.
- Sender-ID preservation: alphanumeric sender IDs and registered headers can be overwritten or stripped by an intermediary, so a message that left as your brand can arrive from a shared long number — a real risk in GCC markets where operators require pre-registered sender IDs.
- DLR fidelity: a genuine operator delivery receipt loses meaning across hops. Intermediaries may return a gateway-level 'delivered' that only means 'I passed it on', not that the handset received it, so your status report stops reflecting ground truth.
This is why the number of hops between your API and the terminating operator is the single most useful question to ask a provider. A direct route preserves the sender ID, returns an operator-level DLR, and completes the HLR-to-handset sequence without third parties in the middle. Operators and enterprises that need to see the full chain — accepted, routed, delivered, receipted — rely on an ESME and CDR view that reconciles every submit_sm against its final DLR, and on a carrier-grade SMSC gateway that terminates traffic directly rather than reselling it onward.
BroadNet has run direct routes since 2003 — 1,000+ operator connections across 200+ countries at a 99.99% platform SLA, sustaining up to 30,000 SMS/sec per node. If you bind as an ESME over SMPP or terminate through our SMSC gateway, you get direct routing with operator-level delivery receipts, not a multi-hop chain that quietly rewrites your sender ID.
Frequently asked questions
How does an SMSC deliver an SMS?
The SMSC uses store-and-forward: it accepts and stores the message, then queries the terminating operator's HLR to find the subscriber's serving MSC/VLR. It forwards the message (MT-ForwardSM) to that switch, which pages the handset and delivers it. If the handset is unreachable, the SMSC queues and retries within the message's validity period, then generates a delivery receipt.
What is an ESME?
An ESME (External Short Messaging Entity) is any application that connects to an SMSC to send or receive SMS — an OTP service, a campaign platform, an alerting system. It binds to the SMSC over SMPP as a client and issues submit_sm to send mobile-terminated messages, while the SMSC pushes deliver_sm back for inbound replies and delivery receipts. In short: the ESME is your software on the wire.
What is the path an A2P SMS takes from app to handset?
The application binds to an aggregator/SMSC as an ESME and sends submit_sm. The SMSC stores the message and routes it — directly or via SMS hubs — to the terminating operator's SMSC. That SMSC queries the HLR for the serving MSC, forwards the message there, and the switch pages the handset (the MT delivery). The handset's acknowledgement returns as a delivery receipt back up the same chain.
References
- 3GPP — TS 23.040, Technical realization of the Short Message Service (SMS): 3gpp.org
- SMPP — Short Message Peer-to-Peer protocol specification (ESME-to-SMSC): smpp.org
- BroadNet — what an SMSC is and the SMPP integration guide.
- BroadNet — ESME and CDR platform and the SMSC gateway.