The Short Message Service Centre is the piece of mobile network infrastructure that every SMS passes through. It receives messages, holds them, and delivers them onward when it can. Almost every surprising behaviour in SMS traces back to that one design decision.
What does store and forward mean?
That the network takes responsibility for the message before the recipient is reachable.
When a message reaches the SMSC, the SMSC accepts it and answers the sender. Delivery to the handset happens separately, when the handset is registered on the network and able to receive. If it is switched off, in a tunnel, or out of coverage, the message waits at the SMSC and is delivered when the handset reappears.
This is why SMS behaves the way it does when the recipient is unreachable. There is no connection to fail. The message is somewhere, and it will be attempted again.
It is also why accepting a message is not delivering it. The SMSC's acknowledgement means the network has the message, and that is a different claim from the handset having it. What is a delivery receipt covers how much of the difference you can actually observe.
How long does it hold a message?
Until its validity period expires, and then it stops.
Every message carries a validity period, and once it passes the SMSC discards the message rather than retrying indefinitely. That is the mechanism behind an expiry event: not a failure to send, but a deadline reached with the handset never becoming reachable.
The period is set by whoever submits the message and bounded by the carrier's own policy, so it is a per-network fact rather than a universal figure. The practical consequence is worth designing for: a one-time passcode that arrives four hours late is worse than one that never arrives, and a short validity period is how you prevent it.
Where does the SMSC sit relative to me?
Several steps away, and you will not connect to one.
The SMPP reference names the roles in the chain: your application is an External Short Message Entity, anything routing between is a Routing Entity, and the message centre is the destination the protocol talks to. In practice a message from an application reaches an aggregator or provider, which holds the carrier relationships, which reach the SMSC on the recipient's network.
Two things follow. Your provider's acceptance of a message is not the SMSC's acceptance of it, and the SMSC's acceptance is not delivery. Each hop has its own answer, and a status that looks final at one hop is provisional at the next. Why is my message accepted but not delivered works through that ladder.
The other is that the SMSC belongs to the recipient's carrier, not to you or your provider. Behaviour differs between them: how long they hold messages, how they report failures, whether they report anything truthful at all.
Why does this matter for a sender?
Because it explains the three things that most often look like bugs.
- Late delivery. The handset was unreachable and the SMSC held the message. Nothing failed.
- An expiry rather than a failure. The validity period ran out before the handset came back.
- A receipt that does not match reality. The SMSC reports what it believes, and what it believes about the last hop is not always right. Some networks report delivered on handing the message onward.
None of these is fixable from the sending side, which is the useful conclusion. They are properties of a store-and-forward network, and the sensible response is to design for them: keep time-critical messages short-lived, treat a receipt as evidence rather than proof, and do not build a flow that assumes delivery is synchronous.