A travel update is worth nothing if it arrives after the passenger has already left for the airport. The delivery window is measured in minutes, and that single fact determines the capacity, the redundancy and the message design.
This article sets out why the window is short, how volume concentrates around disruption, how to plan capacity for a bad day rather than an average one, and how the message design has to survive a queue.
Why is the delivery window for high-frequency travel update SMS measured in minutes?
Because the passenger can still act on it.
A gate change, a delay or a cancellation is useful while the passenger can still act on it, and the window closes when they leave, board or stop checking.
That makes travel updates closer to an alert than to a notification. The consequence is that every component of the path is inside the deadline, including the interval between the operational event being recorded and the message being submitted. A system that detects the change quickly and then sends slowly has the same effect as one that detects slowly, and the two are often confused because only the sending side is measured. The message framework that carries the update is defined in ETSI TS 123 040 and 3GPP TS 23.040, and the subscription states that determine whether a message can be delivered at all are defined in 3GPP TS 24.301.
The measurement that matters is therefore end to end: from the operational event to the message being delivered, expressed as a distribution rather than an average. A system with a two-minute median and a twenty-minute tail fails the passengers in the tail, and the tail is where the complaints come from.
| Stage | What it contributes to the deadline | Typical failure |
|---|---|---|
| Operational event recorded | The start of the clock | The event is noticed late |
| Message generated | Template and list resolution | Slow lookup against a large passenger list |
| Submission | Queueing and pacing | A campaign occupying the queue |
| Delivery | Network and handset | A subscription that cannot receive |
Volume concentration around disruption events
A disruption generates more messages than the event that caused it.
One cancellation produces an initial notification, then rebooking confirmations, then updates, and the volume arrives in a single burst.
The concentration is the reason travel messaging is hard to size. A normal day might carry a few thousand updates across the estate, while a single disruption at a hub produces tens of thousands of messages in an hour to passengers who are all in the same place and all waiting. The peak is not a multiple of the average; it is a different shape entirely, and it is what the design has to accommodate.
Two properties of the burst matter. It is geographically concentrated, because the affected passengers are usually at or heading to the same location, which concentrates the destination ranges the messages go to. And it is time-bounded, because the value of the messages falls away within hours. Both point at the same design conclusion: the capacity has to be available when the event happens rather than scalable on demand, and the pacing has to prioritise the messages whose window is closing.
Capacity planning for a bad day
Size from the disruption, not from the schedule.
The planning figure is the largest realistic burst, divided by the window in which those messages have to be delivered.
That figure is uncomfortable, because sizing for a hub disruption produces an estate that is idle on ordinary days. The alternatives are worth stating honestly: accept a longer delivery time during a major disruption, route the burst to a provider, or hold local capacity that is idle between events. Each is a legitimate choice, and the decision belongs with the operator of the service rather than with the infrastructure team, because it is a decision about what the operator promises during disruption.
Where the answer is a combination, the routing policy should be explicit: which messages always go over the owned estate, which overflow to a provider, and who decides when the threshold is crossed. A hybrid that is not documented converges on whichever path is easiest to send through, which is the state most operators discover during an incident rather than before it.
Redundancy for a time-critical path
The path needs a second route, and the queue has to be above both.
Redundancy in this service is about route diversity rather than about a spare unit, because the failure that stops a burst is usually an operator or a route rather than a device.
Three failure modes are worth designing against. An operator problem that removes a large share of the estate, which a second operator addresses. A site problem that removes the connectivity the estate depends on, which a second location addresses. And a demand burst larger than the estate, which a provider path addresses. The queue has to sit above all of the paths so that a failure leaves the work where a surviving path can collect it, and messages in flight have to be suppressed for duplicates during a switch.
The switch trigger should be based on evidence rather than on a timer alone. A trigger based on the delivery time distribution responds to what passengers are experiencing, while a timer is a backstop. Where the deployment also carries routine marketing messages, the redundancy design should exclude them: a burst should not be able to consume the capacity reserved for the disruption path.
Message design that survives a queue
Short, self-contained and actionable.
A message that needs a second message to be understood is a message that fails when the second one is delayed.
Three design rules follow. The message should carry the decision, not a reference to a decision: the gate, the new time, the instruction, in the message itself. It should not require a link to be useful, because the passenger may be in a queue or on a plane with no data, and a link in a message that appears to come from an airline is also the pattern used by fraud. And it should identify the passenger’s reference in a way that is meaningless to anyone else who sees the screen.
Message length interacts with the queue in a way that is easy to miss. Longer messages are split into segments, and a multi-segment message requires every segment to arrive before the passenger sees anything, which increases the chance that a delayed or lost segment leaves the recipient with nothing. Keeping the update inside a single segment is a reliability decision as well as a cost one, and it is worth checking the character budget under both encodings before the template is finalised.
Reconciling delivery with the operational timeline
The message is part of the operation, not a report on it.
Reconciling the two shows whether the information reached the passenger in time to matter, which is the only figure that describes the service.
The join requires an identifier generated by the operator and carried through both the operational record and the message. With it, the operator can measure the interval between the event and the delivery for each affected passenger, and can see whether the tail of that distribution coincides with the passengers who subsequently complained. That comparison is what turns a complaint into an improvement: the tail usually has a cause, and the cause is usually a specific destination range, a specific route or a specific list that resolved slowly.
The record also has to survive the platforms involved, because the question is asked weeks later and the sending platform may have changed. Record-keeping practice for the operational logs is covered in NIST SP 800-92, and fault management concepts including thresholds and clearing conditions are organised in ITU-T M.3400.
A capacity outline
The outline works from the operational event to the delivered message, because the interval that matters is measured end to end across several systems. It is written around the worst day rather than the average one, and it produces the capacity the disruption scenario requires.
- Measure the operational-to-delivery interval end to end, as a distribution.
- Estimate the largest realistic burst from the largest hub disruption in the last two years.
- Divide the burst by the window to obtain the required rate, and compare it with the owned estate.
- Decide the routing policy for overflow, and who authorises the switch.
- Establish route diversity across operators, and site diversity where it is justified.
- Keep service messages out of the promotional queue.
- Design each message to be self-contained and to fit in a single segment.
- Reconcile the operational record with the delivery record on a schedule, and review the tail.
The outline produces a design that is uncomfortable on paper and correct in operation, because sizing for a disruption means holding capacity that a quiet week does not need. The alternative is a documented decision to accept a slower response during a major event, which is a legitimate choice provided it is made deliberately and stated where the service promises are written.
One further measurement belongs in the plan: the rate at which the operational side can generate messages. A disruption that produces updates faster than the platform can compose and submit them is limited by the upstream process rather than by the estate, and the fix is a template and a lookup that resolve quickly rather than more capacity. Measuring both sides of the boundary is what tells an operator which constraint applies.
Size from the disruption and measure end to end. Send your peak burst estimate, window and current routing policy to service@telarvo.com, or review the published configurations on the SK-SMS Gateway range and the SMS gateway solution page. Telarvo publishes the SK-SMS gateway range, the TYH modem pools and the TGW SMS machine on its product pages, and the configurations referenced above come from those listings.
FAQ
Is SMS becoming obsolete for travel updates?
It is not, and the reason is specific to this use case: a short message reaches a passenger who has not installed the airline’s application and who may be offline, which is exactly the situation a disruption creates. Other channels have grown alongside it rather than replacing it. Record which channels each passenger has available, because the fallback design follows from that rather than from a general preference.
How fast does a travel update need to arrive?
Fast enough that the passenger can still act, which is a service decision rather than a technical one. Once the window is decided, the engineering task is to measure the interval from the operational event to delivery and to keep the tail of that distribution inside it, since the tail is where the complaints come from. Set the window with the operational team rather than with the technical team, because the interval that matters is the one the passenger experiences.
Should travel updates include a link?
The message should be useful without one, because the passenger may be offline and because a link in an unexpected message is the pattern used by fraud. Where a link is included, the message should also state the essential decision — the gate, the time or the instruction — so that it remains actionable on its own. Review the wording with the security team before a campaign, because a link in an unexpected message trains passengers to distrust the channel.
How do we know whether the update arrived in time?
By joining the operational record with the delivery record on an identifier generated by the operator. That produces the interval per passenger and shows whether the slow tail coincides with the complaints, which is the comparison that identifies the cause. Keep the join key stable across the operational and delivery records, because a key that changes per campaign cannot be compared over time.