Availability Is Not Deliverability: How to Measure Three Layers of A2P SMS Route Health

An available route is not always operationally healthy

In A2P SMS operations, calling a route “available” can conceal three different questions. Is the technical connection operational? Does the system accept submitted messages? Do messages generate a delivery outcome that can be interpreted and reconciled? A positive answer to the first question does not automatically answer the other two.

An SMPP session can be established, respond to keepalive checks, and remain open while a route experiences submit rejections, a buildup of pending requests, latency degradation, or a drop in DLRs. Likewise, an accepted submit can mean that the SMSC accepted the message over the SMPP connection, not that the recipient received it.

A2P SMS route availability and deliverability should therefore be assessed as a set of related but non-equivalent signals. Separating them prevents one favorable or unfavorable metric from dominating a decision that requires context.

• Do not use an active session as a substitute for delivery.
• Do not count accepted, queued, or submitted requests as delivered messages.
• Do not treat the absence of a DLR as automatic proof of non-delivery without reviewing the route’s agreed behavior and reconciliation process.
• Compare results across homogeneous populations; do not combine synthetic tests and production traffic into one percentage.

The three measurement layers

The most useful operational model separates route health into three layers. The first is technical availability between the systems exchanging traffic. The second is acceptance of each submit request. The third is the subsequent delivery outcome communicated through the available mechanisms.

Each layer needs its own identifiers, time windows, metrics, and internal thresholds. It also requires a precisely stated conclusion: “connectivity confirmed,” “submit accepted,” and “final DLR received” describe different facts and should not be substituted for one another.

• Layer 1: technical availability. Measures session status, connectivity, responses, and response times.
• Layer 2: traffic acceptance. Measures submit responses, synchronous rejections, pending requests, queues, and timeouts.
• Layer 3: delivery outcome. Measures DLRs, final statuses, intermediate statuses where available, and latency to outcome.

Layer 1: technical availability is not proof of delivery

In SMPP, enquire_link and enquire_link_resp are used to check the health of the communications path and operation of the application connection between the ESME and SMSC. They are appropriate signals for verifying whether the session responds, detecting connectivity losses, and measuring the response time of that exchange.

These signals do not prove that a message has been routed to a mobile network, that the destination is reachable, or that the subscriber has received an SMS. The SMPP model itself provides separate mechanisms for requesting and carrying delivery receipts.

Connectivity measurement should record the session lifecycle and maintenance events without extrapolating those results to the delivery layer.

• Session establishment and closure times.
• Bind results and session errors.
• enquire_link sends, received responses, losses, and response time.
• Reconnects, outage duration, and timeout frequency.
• Events separated by account, connection, declared route where applicable, and time window.

Layer 2: what traffic acceptance demonstrates

Acceptance answers a narrower question than delivery: did the receiving endpoint accept this submit request at this time? In the SMPP flow, a successful response to a submit request can evidence acceptance of the message by the SMSC through the connection. The eventual outcome requires subsequent tracking, usually through a Delivery Receipt requested for the message.

In API-based messaging platforms, there is an equivalent distinction: a request can be accepted or queued before the message is sent to an upstream carrier and before a delivery or non-delivery confirmation exists. Treat each transition as a stage, not as a retrospective guarantee.

Capacity should not be inferred from an open bind alone either. SMPP does not define a universal maximum number of outstanding operations; it depends on the SMSC implementation. As a result, an apparently available route can degrade as concurrent requests increase.

• Record submit response codes and synchronous rejections.
• Measure response timeouts and pending or unacknowledged requests.
• Observe queue progression and submit failures where the interface exposes those states.
• Associate each submit with its message identifier, normalized destination, sender, content or content class, route, and timestamp.
• Assess acceptance under authorized, controlled load; an isolated test does not characterize sustained capacity.

Layer 3: DLRs and the limits of delivery evidence

An SMSC Delivery Receipt is a signal generated by the SMSC when it detects the final state of a registered message. In SMPP, it can be received through deliver_sm or data_sm and includes useful fields for correlation and interpretation, such as the receipted message identifier, message_state, and, where present, network_error_code.

A final DLR is evidence closer to a delivery outcome than a submit response, but it remains a signal from the messaging ecosystem, not universal and independent proof of reading, interaction, or verified receipt on the handset. The specific semantics and scope of confirmations depend on the network, provider, and implementation.

Intermediate states deserve separate treatment. They can indicate, for example, an initial failed attempt while the message remains held for further attempts. Their support is specific to the SMSC and provider implementation; do not assume that every route emits them or treat their absence as necessarily being a failure.

• Retain the submit identifier and the identifier referenced in the DLR to reconcile events.
• Separate final DLRs from intermediate notifications.
• Measure the time from acceptance to DLR, as well as the proportion of DLRs received within an internally defined window.
• Classify statuses according to the contractual and technical documentation for each integration; do not force equivalences across different vocabularies.
• Describe “delivery DLR received” without turning it into “read confirmed” or “independent handset receipt.”

Designing legitimate, controlled synthetic tests

Synthetic tests help detect changes in behavior before they broadly affect traffic, but they should be performed only to authorized destinations and with compliance controls in place. Their value comes from keeping variables known, not from attempting to reproduce the full diversity of commercial traffic.

Use test destinations under your control or with explicit authorization. Normalize numbers to E.164 to reduce formatting ambiguity and maintain consistent segmentation by country or international destination. Keep an inventory of destinations, applicable authorization, intended route, sender, and content profile used.

Design cases that make it possible to compare the same signal over time. If destination, sender, text, and route all change at once, it will be difficult to attribute the cause of a variation.

• Define an authorized set of test destinations and review it periodically.
• Test connectivity, submit, DLR correlation, and time to outcome separately.
• Keep message content legitimate, non-deceptive, and appropriate under applicable policies.
• Change one dimension at a time: destination, operator, sender, content type, or declared route where applicable.
• Record test-case version, time, identifiers, synchronous responses, asynchronous events, and observations.
• Do not turn a test result into a guarantee for all destinations, senders, or traffic types.

Complementing with production without mixing populations

Production traffic provides real coverage of destinations, senders, and operational situations that synthetic testing does not reproduce. However, it includes variability: campaigns, OTP peaks, content changes, consent differences, handset behavior, and applicable policies. It is therefore useful for observing patterns, but requires segmentation before attributing a cause to the route.

Keep synthetic and production results as separate populations. A simultaneous decline in both groups can justify a priority investigation. A deviation in production only may require reviewing changes in traffic mix, sender, content, or destination first, before concluding that connectivity or delivery has degraded.

Monitoring should retain persistent identifiers and reconcile asynchronous events. If a callback is missing, the absence of the event should not immediately become a conclusion; where the available interface permits status lookup, use it as part of the reconciliation process.

• Label every record as synthetic or production.
• Segment production by destination, operator where known, traffic type, sender, content or template, and declared route where applicable.
• Do not directly compare a single-destination test with a multi-segment campaign.
• Review the status of messages that remain without a terminal outcome within the defined operational window.
• Retain evidence of configuration changes, incidents, and traffic adjustments alongside the metrics.

Metrics and patterns that require attention

The dashboard should display separate time series for each layer. A single availability figure can conceal that the connection is healthy while submits are rejected, or that submits are accepted while the proportion of observed final DLRs declines.

Look for changes against a comparable baseline, not just isolated absolute values. Comparison is meaningful when it preserves the same destination group, operator where available, sender, content profile, declared route, and time period. Changes in traffic mix can create an apparent degradation signal without connectivity being the cause.

Patterns of interest include stable connectivity with declining DLRs, increasing synchronous rejections with healthy sessions, growth in pending requests, longer submit or DLR latency, and a concentration of adverse outcomes in a single combination of destination, sender, or content.

• Connectivity: proportion of operational sessions, keepalive losses, reconnects, and response latency.
• Acceptance: proportion of successful responses, rejections by code, timeouts, pending requests, and submit response time.
• Delivery: proportion of final DLRs received, status distribution, time to DLR, and messages without a reconciled outcome.
• Segmentation: E.164 destination, operator where available, sender, traffic type, content or template, declared route, and test or production population.
• Evidence: correlatable identifiers, timestamps, available error codes, and associated operational changes.