Outbound messaging is where the invoice is generated and where the assumptions are made. A gateway that accepts a batch instantly has not sent anything; it has agreed to send, and what happens between acceptance and delivery decides both the delivery rate and the cost of the campaign.
This guide covers the outbound path specifically: how queue depth behaves under load, how to pace a batch at a rate the network accepts, what a failed delivery actually costs, and how the outbound stream should share a chassis with anything else the deployment runs.
What happens between submitting a batch and delivering it?
It queues, paces, transmits and reports, in that order.
Each stage has its own failure mode, and only the last one is visible in a delivery report.
The queue holds submitted messages until a channel is free. Its depth is the deployment’s buffer against a burst, and it is also the measure of how long a message may wait. The pacing stage decides how fast messages leave the queue, and it is the setting that determines whether the network accepts the traffic or begins rejecting it. Transmission occupies a channel for the duration of a send. Reporting records the outcome per message, which is the only stage that produces evidence.
The consequence of this sequence is that a low delivery rate can originate at any of the four stages, and the corresponding remedies are different. Queue saturation calls for more channels. Pacing errors call for a slower rate. Transmission failures point at the module or the SIM. Reporting gaps make all three indistinguishable, which is why the evidence stage is worth building before the others are tuned.
How deep should the outbound queue be?
Deep enough for a burst, inside the window.
Queue depth is a policy decision expressed as a number, and it follows from the delivery commitment rather than from the hardware.
The calculation is a division with a comparison. Divide the acceptable wait time by the average time to transmit one message per channel, multiply by the channel count, and the result is the queue depth that can be absorbed without exceeding the window. Where the burst exceeds that figure, the excess will be delivered late, and the decision is whether late is acceptable or whether the deployment needs more channels.
Two properties make a queue usable rather than merely present. It should be bounded, so that a runaway submission cannot fill storage. And it should be observable, so that queue depth is a metric rather than a discovery. A deployment that monitors queue depth can see a campaign approaching its limit; one that does not learns about the limit from recipients.
Where the deployment carries time-bounded messages such as verification codes, the queue should be separated from the campaign queue rather than shared with it. A code that waits behind a marketing batch has failed, whereas a marketing message that waits is merely delayed, and the two should not compete for the same capacity.
How should a batch be paced?
At the rate the network accepts, established by measurement.
Pacing is the single setting that most affects whether a campaign completes or fails.
The accepted rate is not the rate the hardware can achieve, and it is not a constant. It varies by operator, by time of day, and by the composition of the traffic. The practical method is to increase the send rate in steps during a test batch and record the point at which acknowledged delivery stops keeping pace with submission. That point, less a margin, is the rate to use.
Three signals indicate the rate is too high. Delivery reports lag further behind submission as the batch progresses. A growing proportion of messages fail with errors that reflect network rather than module handling. And the failure rate falls immediately when the rate is reduced, which distinguishes a pacing problem from a module fault.
The counter-intuitive consequence is that sending slower often delivers more, because a queue draining at the accepted rate completes while one that overruns the network produces failures that have to be retried. Where a campaign has a deadline, the rate that matters is the fastest rate at which delivery is acknowledged, not the fastest rate at which submission succeeds.
What does a failed delivery actually cost?
The segment, the retry, and the consequence.
Only the first two appear in a messaging invoice, which is why the third is usually unmeasured.
The direct cost is the segment that was sent and not delivered, plus the segment sent again. The indirect cost depends on what the message carried: an authentication code that never arrives becomes a support contact, a delivery notification that never arrives becomes a call to a depot, and a marketing message that never arrives becomes a lost impression rather than a complaint.
That asymmetry explains why the three categories should be measured separately rather than as a single delivery rate. A deployment reporting one figure for all traffic cannot distinguish a marketing delivery rate from a transactional one, and the first is tolerable at a level the second is not. Where the gateway log attributes outcome per message, the three figures can be produced from the same record.
Retries deserve a policy rather than a default. A message that fails because a channel was briefly unavailable should be retried; a message that failed because a number is invalid should not, because the retry consumes a channel and produces the same result. Distinguishing retryable from permanent failures is what prevents a small number of bad numbers from consuming a disproportionate share of capacity.
Where the deployment carries commercial traffic, the operational expectations for consent and opt-out handling are described by M3AAWG and, for the North American market, by the CTIA. A retry policy that ignores an opt-out received between attempts creates a compliance problem as well as a delivery one.
How should outbound share a chassis with other traffic?
Reserve channels for anything time-bounded.
Outbound campaigns are the workload most likely to consume every available channel, which is why they need boundaries.
Three boundaries are worth configuring. A port group reserved for inbound and time-bounded traffic, so that a campaign cannot occupy the channels a reply or a verification code needs. A concurrency cap on the campaign group, so that it drains at a rate the network accepts rather than at the maximum the hardware allows. And a separate queue for time-bounded messages, so that they are not sequenced behind a campaign.
Where the deployment runs several customer campaigns on one estate, the boundaries should be per customer rather than global. A global cap means one customer’s campaign can consume the shared allowance, and the customer whose campaign was delayed has no way of knowing why.
The published SK-SMS Gateway range provides the port and SIM configurations to allocate these groups deliberately, from the 8-port, 32-slot configuration at $450.00 where a small estate needs a higher SIM ratio, to the 32-port models where channel count is the binding constraint.
What should be monitored on the outbound path?
Queue depth, accepted rate, delivery by category.
Three metrics distinguish a deployment operating near its limit from one that has already exceeded it.
- Queue depth over time. A depth that rises during a campaign and drains afterwards is healthy; one that rises and stays raised indicates the drain rate is below the submission rate.
- Accepted rate against submitted rate. The gap between the two is the diagnostic that separates a hardware limit from a network limit.
- Delivery outcome by message category. Transactional, authentication and marketing traffic measured separately, because a single combined figure hides the category that matters.
- Registered channel count during a batch. A count that falls during transmission points at power or module problems rather than at the network.
Item four belongs on the list because it is the check most often omitted and the one that explains an otherwise puzzling delivery decline. A pool that loses modules during a batch reports a lower delivery rate without reporting a fault, and the two symptoms are indistinguishable unless the channel count is being watched.
Where the campaign spans several days, record the pace and the accepted rate alongside the result. A later campaign that behaves differently can then be compared against a known starting point rather than against an impression, and the difference between a genuine change in network acceptance and a change in the deployment becomes visible.
Where the deployment must reference an equipment framework, the ETSI standards catalogue covers the network and equipment side, the messaging behaviour is specified by 3GPP, and the numbering that recipients see follows ITU Recommendation E.164.
Conclusion
The outbound path is a queue followed by a pacing decision, and the pacing decision matters more than the hardware specification. Queue depth should be sized from the delivery commitment, bounded, and observable; the send rate should be established by measurement rather than by default; and delivery outcomes should be measured by message category rather than as a single figure. A failed delivery costs the segment, the retry, and the consequence of the recipient not receiving it, and only the first two appear on an invoice.
Boundaries matter as much as tuning. A channel group reserved for time-bounded traffic, a per-customer concurrency cap, and a separate queue for verification messages prevent a campaign from consuming the capacity that something with a commitment needs. The published configurations from the 8-port, 32-slot model at $450.00 upward provide enough scope to allocate those groups deliberately rather than contending for a single pool.
Measure your accepted rate before you set a campaign pace. Send your batch sizes, deadline and delivery categories to service@telarvo.com, or review the published models on the SMS gateway solution pages.
FAQ
Why does sending slower deliver more messages?
Because a queue draining at the rate the network accepts completes, while one that overruns the network produces failures that have to be retried. The fastest rate at which submission succeeds is not the fastest rate at which delivery is acknowledged. Measure the accepted rate by increasing submission in steps and watching for the point where delivery stops keeping pace.
How large should the outbound queue be?
Size it from the delivery commitment: divide the acceptable wait by the average time to transmit one message per channel, multiply by the channel count, and that is the depth absorbable within the window. Keep the queue bounded so a runaway submission cannot fill storage, and monitor its depth so the limit is a metric rather than a discovery.
Should transactional and marketing messages share a queue?
No. A verification code that waits behind a marketing batch has failed, while a marketing message that waits is merely delayed. Separate queues let the time-bounded workload be sequenced independently, and separate measurement lets each category’s delivery rate be assessed against the standard that applies to it rather than against an average.
Why does the delivery rate fall partway through a campaign?
Check three things in order: whether the queue is draining more slowly than it fills, whether the send rate exceeds what the network accepts, and whether registered channel count falls during transmission. The third indicates a power or module problem rather than a network one, and it is invisible unless the channel count is being monitored during the batch rather than before it.