A campaign has a deadline, and the deadline is what a modem pool has to be sized against. The question is not how many messages a 32-port unit can send in a day but how many it can deliver before the campaign stops being worth running.
This article sets out how to tell a burst campaign from a sustained one, how to derive a port count from launch-day volume, how per-number policy determines the SIM estate behind the ports, and how to pace the traffic so the network accepts it rather than punishing it.
Is the campaign a burst or a sustained load?
The shape decides the sizing method.
A burst delivers a defined list in a short window, while a sustained campaign sends at a steady rate over days or weeks, and the two need different calculations.
A burst is sized from the list length and the window: a list of twenty thousand contacts with a four-hour window requires a sustained rate of about eighty-three messages per minute. A sustained campaign is sized from the daily volume and the per-number allowance, because its constraint is the policy that limits how much any one number may carry rather than the window. Applying the wrong method produces either a large pool that sits idle or a small pool that misses the deadline.
Most real campaigns are a mixture, and the mixture is worth stating explicitly. A launch might burst to a purchased list and then run sustained follow-ups to the responders, which means the pool has to cover the burst and the background traffic at the same time. Sizing for one and discovering the other is the usual reason a campaign runs late. The message framework behind both is defined in ETSI TS 123 040 and 3GPP TS 23.040.
| Campaign shape | Sized from | Constraint that binds |
|---|---|---|
| Burst to a list | List length divided by the window | The window |
| Sustained over days | Daily volume divided by the per-number allowance | The per-number policy |
| Mixed launch plus follow-up | The burst, plus the background rate | Whichever is tighter |
| Repeating weekly | The weekly peak, not the average | The peak day |
How do you derive 32-port modem capacity from real estate marketing alert volume?
Divide the required rate by the per-SIM rate.
The calculation is short and it depends on two measured figures rather than on any specification: the required rate from the campaign list and its window, and the paced per-SIM rate measured on the operators in use.
The required rate comes from the list and the window. The per-SIM rate comes from measuring what a single subscription can carry on the operators in use while maintaining its delivery ratio. The second figure is the one that is usually assumed rather than measured, and it is the figure that determines whether a 32-port pool can meet the deadline or whether a larger tier is needed. A pool whose ports are adequate but whose SIMs are the constraint will simply deliver more slowly.
Headroom belongs in the calculation for two reasons specific to campaigns. A campaign is usually run once, so there is no later opportunity to absorb the peak, and a port or a subscription that is out of service during the window reduces the rate at the worst moment. Sizing so that the required rate occupies a defined share of capacity is the simplest way to build that in. As displayed on the site, the TYH 32-port modem pool is listed at $270 and the SK-SMS Gateway 32-32 at $1,160, so the step to a larger tier is a known figure that can be compared against the cost of missing the window.
Per-number policy and its effect on the SIM estate
The estate size is a policy outcome, not a port count.
Where each subscription may carry a defined volume in a period, the SIM estate is the peak volume divided by that allowance, and it is frequently larger than the port count suggests.
That relationship is what makes campaign sizing different from general capacity planning. A 32-port pool with four SIM slots per port can hold a hundred and twenty-eight cards, and if each card may carry a modest daily volume, the estate ceiling follows from the policy rather than from the hardware. A campaign that needs more numbers than the pool can hold will be paced by the estate even though the ports are idle.
Two levers change the ceiling. Centralised SIM storage makes it practical to hold a larger estate and to rotate through it, and a compliant per-number policy that has been measured rather than guessed raises or lowers the allowance per card. Both decisions belong in the campaign plan, because the plan is what determines whether a given pool can meet a given deadline.
Pacing so the network accepts the traffic
Pacing is a campaign requirement, not a courtesy.
A pool that submits as fast as it can will produce a burst the network may reject, and rejected traffic has to be resent inside the same window.
The pacing decision has three parts. The first is the interval between messages on the same number, which determines how one subscription appears over time. The second is the rotation across the estate, which determines how evenly the load is spread. The third is the per-prefix ceiling, which prevents a burst to one destination range from consuming the whole campaign’s capacity. Together they determine whether the achievable rate is close to the theoretical one or well below it.
The campaign schedule should therefore be built from the paced rate rather than from the raw rate, and the difference between the two is usually the reason a campaign takes longer than the arithmetic suggested. Where the deadline is fixed, the pool has to be sized from the paced figure, which means measuring the paced rate once before the campaign is scheduled.
Two campaign-specific factors belong in the same calculation. A campaign usually runs once, so a rate that is adequate on paper but leaves no margin has no later opportunity to recover, and a subscription that is actioned during the window reduces the achievable rate at the worst possible moment. Both argue for a headroom figure that is larger than the one a steady-state deployment would choose.
Consent and opt-out under campaign pressure
Pressure is where consent records fail.
A campaign that runs against a purchased list without a category-specific consent record is the deployment that generates complaints and, in some markets, enforcement.
The engineering requirement is a consent record that names the category the recipient agreed to, and a platform that refuses to send a marketing category message without it. A withdrawal has to suppress the category immediately and survive a change of platform, because the obligation follows the person. Where the processing falls within the European framework, the reference points are the regulation on EUR-Lex and the guidance collected by the European Data Protection Board; the equivalent rules differ in other markets and are decided by the compliance owner.
Two practical controls reduce the risk under deadline pressure. The first is a pre-send check in the sending path that refuses a batch whose consent category does not match the list it was built from. The second is a small test send to a sample before the full list, which catches a list that was built against the wrong category while the campaign can still be stopped. Record-keeping practice for the consent and suppression records is covered in NIST SP 800-92.
How do you measure against the campaign deadline?
Measure completion against the clock, not the queue.
The useful figure is the time by which a defined proportion of the list has been delivered, and it should be recorded during the campaign rather than reconstructed afterwards.
A campaign that is behind schedule looks healthy from a queue depth perspective, because the queue is deep and moving. The figure that reveals the truth is the delivery rate measured against the list: at the current rate, how many hours remain, and does that fit inside the window. Recording that projection at intervals during the campaign allows a decision to be made while there is still time to route traffic differently.
Two supporting measures complete the picture. The delivery ratio by destination area identifies whether the pace is limited by the network rather than by the pool, and the per-number volume identifies whether the estate is being used evenly. Both are available from the same per-message record that the deadline projection needs.
A capacity worksheet
The worksheet converts a campaign list and a deadline into a pool size and a schedule. It works from measured per-SIM rates rather than from a specification, and it produces the figure the campaign is planned against rather than a range of options.
- Campaign shape: burst, sustained or mixed.
- List length after de-duplication and consent filtering.
- Window available, and the required rate it implies.
- Measured per-SIM rate at the installed position.
- Paced rate after interval, rotation and per-prefix limits.
- Ports required, from the paced rate rather than the raw rate.
- SIM estate allowed by the per-number policy.
- Headroom as a policy share of capacity, and the larger tier’s list price for comparison.
The worksheet produces a decision about the tier and a schedule that the campaign can be planned against. Where the paced rate means a 32-port pool cannot meet the window, the honest options are a larger tier, a longer window or a smaller list, and the arithmetic is what makes the choice explicit rather than discovered on deadline day.
Size from the paced rate and the window. Send your list length, window and per-number policy to service@telarvo.com, or review the published configurations on the SMS modem range and the SK-SMS Gateway range. 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
How many messages can a 32-port modem pool send in an hour?
There is no single figure, because the achievable rate depends on the per-SIM rate measured on the operators in use and on the pacing policy applied. Two deployments with identical hardware can differ by a large factor. Measure the paced rate on a sample and use that figure for planning. The measurement should be repeated whenever the operator mix changes.
Do we need a larger pool or more SIM cards?
Whichever the measurement identifies as the constraint. If the paced rate per SIM is the limit, more SIMs or different operators raise the ceiling without adding ports. If the ports are saturated, the pool size is the constraint. The two are diagnosed from the same per-message record, which is why that record is worth building first. The record also shows which operator and which subscription carried each message, which is where the constraint usually sits.
Can a campaign run to a purchased list?
Only where the recipients have consented to that category of message, and the consent must be evidenced rather than assumed. Marketing categories normally require their own permission, separate from any service message. Confirm the applicable rules for each market with the compliance owner before the list is used. The consent basis belongs with the list, not with the campaign. Keep the evidence with the list so that a later campaign can be checked against the basis it was built on.
How do we know mid-campaign whether we will meet the deadline?
Project from the delivery rate rather than from the queue. At the current paced rate, calculate the hours remaining and compare that with the window. Recording the projection at intervals allows traffic to be routed differently while there is still time, which a queue-depth view will not reveal. The projection also gives an early warning of a rate that has fallen.
{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “How many messages can a 32-port modem pool send in an hour?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “There is no single figure, because the achievable rate depends on the per-SIM rate measured on the operators in use and on the pacing policy applied. Two deployments with identical hardware can differ by a large factor. Measure the paced rate on a sample and use that figure for planning. The measurement should be repeated whenever the operator mix changes.”
}
},
{
“@type”: “Question”,
“name”: “Do we need a larger pool or more SIM cards?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Whichever the measurement identifies as the constraint. If the paced rate per SIM is the limit, more SIMs or different operators raise the ceiling without adding ports. If the ports are saturated, the pool size is the constraint. The two are diagnosed from the same per-message record, which is why that record is worth building first. The record also shows which operator and which subscription carried each message, which is where the constraint usually sits.”
}
},
{
“@type”: “Question”,
“name”: “Can a campaign run to a purchased list?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Only where the recipients have consented to that category of message, and the consent must be evidenced rather than assumed. Marketing categories normally require their own permission, separate from any service message. Confirm the applicable rules for each market with the compliance owner before the list is used. The consent basis belongs with the list, not with the campaign. Keep the evidence with the list so that a later campaign can be checked against the basis it was built on.”
}
},
{
“@type”: “Question”,
“name”: “How do we know mid-campaign whether we will meet the deadline?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Project from the delivery rate rather than from the queue. At the current paced rate, calculate the hours remaining and compare that with the window. Recording the projection at intervals allows traffic to be routed differently while there is still time, which a queue-depth view will not reveal. The projection also gives an early warning of a rate that has fallen.”
}
}
]
}