Límites de velocidad A2P SMS por destino: cómo acordarlos y gestionarlos
Un límite de TPS declarado no garantiza la entrega. Aprende a precisar su alcance, controlar las colas por destino y evaluar señales operativas sin confundir aceptación con entrega.
Un TPS declarado no es una garantía de entrega
TPS suele usarse para expresar mensajes por segundo, pero el número anunciado solo sirve para operar cuando se sabe qué mide, dónde se aplica y bajo qué condiciones. No hay un límite universal que pueda deducirse únicamente del país, el operador o el tipo de conexión: hay que confirmarlo con quien administra la ruta y dejar constancia de su alcance.
También hay que separar las etapas del envío. Una respuesta de aceptación confirma, como máximo, que una solicitud fue admitida en ese punto de la cadena; no demuestra por sí sola que el SMS llegó al teléfono. Los estados posteriores, incluidos los DLR, deben interpretarse según su origen y nivel de verificación.
- Trata el TPS comunicado como una condición que debe aclararse, no como una promesa general de entrega.
- Registra por separado la admisión de solicitudes y los estados posteriores del mensaje.
- No extrapoles el valor de una ruta a otros destinos, operadores o remitentes.
Qué precisar antes de configurar el tráfico
Solicita una definición escrita del ámbito del límite y de cómo se mide. Aclara si corresponde al país, a un operador, a una ruta, a un remitente, a una cuenta o a una sesión. Pregunta además si cambia según el tipo de tráfico, por ejemplo OTP, transaccional o marketing legítimo, y qué ventana temporal se utiliza para calcularlo.
La conexión no sustituye ese acuerdo. SMPP define aspectos del intercambio entre una aplicación y un SMSC, y HTTP describe la semántica de solicitudes y respuestas; ninguna de esas especificaciones, por sí sola, establece un TPS garantizado para una ruta A2P ni confirma la entrega móvil.
- Destino y operador o grupo de operadores al que aplica.
- Identificador de ruta, cuenta, remitente y tipo de tráfico incluidos.
- Unidad, ventana de medición y tratamiento de solicitudes rechazadas.
- Límite por sesión y límite agregado, si existen ambos.
- Condiciones aplicables a ráfagas, concurrencia, pausas y cambios de capacidad.
- Códigos de respuesta y contacto operativo para incidentes o ajustes.
Distinguir tasa sostenida, ráfaga y concurrencia
No asumas que una tasa nominal significa que se puede enviar ese volumen de forma continua. Pide que el proveedor defina si el valor es sostenido, un máximo instantáneo o una media durante una ventana determinada. Si admite ráfagas, solicita sus condiciones y duración; si limita sesiones o solicitudes simultáneas, registra esos límites por separado.
La evidencia disponible no permite recomendar valores universales para esos parámetros. Si el proveedor no puede definirlos, marca la condición como no confirmada y evita diseñar el sistema alrededor de una interpretación optimista.
- Documenta cada parámetro por separado; no reduzcas todos los límites a un único TPS.
- Distingue tasa de mensajes, número de solicitudes simultáneas y sesiones de conexión.
- Anota si el límite se comparte entre destinos, remitentes o conexiones, o si el proveedor aún no lo ha aclarado.
Diseñar controles de admisión y colas por destino
Organiza el tráfico en colas que correspondan al ámbito real de cada límite. Si un proveedor confirma límites distintos por operador o ruta, evita que una cola global oculte el exceso en uno de esos grupos. Antes de poner el control en producción, verifica cómo se identifica el destino y qué ocurre con mensajes cuyo enrutamiento todavía no está resuelto.
La tasa de salida debe poder ajustarse sin descartar mensajes silenciosamente. Define qué se mantiene en cola, qué se reintenta y cómo se evita que los reintentos amplifiquen una situación de saturación. Los criterios concretos dependen del acuerdo y del comportamiento observado; no hay una configuración universal que pueda recomendarse sin esos datos.
- Asocia cada cola a un límite confirmado y conserva esa relación en la configuración.
- Establece una regla explícita para pausar, reanudar y reintentar tras rechazos.
- Registra cambios de tasa y configuración para relacionarlos con los resultados.
- Asegura que las prioridades de tráfico no anulen las restricciones del destino.
Leer las señales operativas con contexto
Una subida de rechazos o de latencia en la respuesta de aceptación puede indicar que se está alcanzando una restricción, pero no identifica por sí sola la causa. Comprueba si coincide con un cambio de volumen, ruta, sesión o configuración, y solicita al proveedor la interpretación de los códigos de respuesta. No atribuyas automáticamente el problema a un límite de TPS.
Supervisa también la profundidad y antigüedad de las colas, las solicitudes aceptadas frente a las rechazadas y los estados posteriores disponibles. La latencia de admisión y el DLR describen etapas distintas; un DLR recibido no debe presentarse como verificación independiente de recepción en el teléfono si no existe esa verificación.
- Rechazos: contabiliza por código, destino, ruta y periodo.
- Latencia: separa el tiempo de respuesta de la API o sesión de los estados posteriores.
- Colas: observa profundidad, antigüedad y ritmo de vaciado.
- Estados: distingue aceptación, DLR y cualquier confirmación de recepción realmente verificable.
Probar de forma gradual y consentida
Antes de una prueba, acuerda con el proveedor el destino, el remitente, el tipo de tráfico, la ventana, la tasa de inicio y las condiciones para detenerla. Usa únicamente mensajes legítimos y destinatarios que hayan consentido el tráfico, cumpliendo las reglas aplicables. No aumentes la carga sobre destinos reales sin autorización explícita.
Incrementa el volumen de forma controlada, registra cada cambio y detén la prueba ante señales acordadas de error o saturación. Una prueba demuestra el comportamiento observado bajo esas condiciones; no convierte el resultado en capacidad productiva garantizada ni en evidencia aplicable a otras rutas o periodos.
- Acuerda por adelantado el alcance y los criterios de parada.
- Mantén constantes las variables que no estés evaluando y documenta cualquier cambio.
- No uses una prueba no autorizada como sustituto de una confirmación contractual.
Responder a una posible saturación
Ante un aumento sostenido de rechazos, latencia o cola, reduce la tasa de admisión y sigue el procedimiento acordado. Si el deterioro continúa, pausa el tráfico afectado cuando corresponda y contacta al proveedor con datos concretos. No aumentes automáticamente la concurrencia ni aceleres reintentos: sin conocer las reglas de la ruta, esas acciones pueden empeorar la presión o dificultar el diagnóstico.
Conserva una cronología del incidente: hora, destino, ruta, volumen, cambios de configuración, códigos recibidos y evolución de las colas. Pide confirmación de si se alcanzó un límite, si hubo una condición operativa distinta o si el límite vigente cambió. Escala por los canales acordados y registra la respuesta.
- Reduce la tasa afectada y evita reintentos agresivos no acordados.
- Aporta códigos de error y métricas segmentados por destino y ruta.
- Solicita una decisión operativa y una confirmación escrita de cualquier cambio de límite.
- Reanuda gradualmente conforme al procedimiento acordado.
Revisar límites y conservar evidencia
Mantén un registro versionado que separe las condiciones declaradas por el proveedor de lo observado en producción. Incluye fecha de confirmación, alcance, parámetros, excepciones y responsable de validar cualquier cambio. Si las métricas difieren de lo acordado, solicita una revisión; no sustituyas el límite contractual por un máximo observado en una prueba breve.
Revisa la ficha cuando cambien la ruta, el destino, el remitente, la sesión o el patrón de tráfico, y también tras incidentes relevantes. BulkSMSMarket está construyendo una plataforma empresarial para descubrir, comparar, comprar, vender y gestionar capacidad A2P SMS; sus tarjetas numéricas públicas son demostrativas hasta que se conecten datos contractuales de rutas. Por ello, no deben tratarse como límites comerciales activos.
- Conserva por separado el límite declarado, la configuración aplicada y la evidencia observada.
- Registra el periodo y las condiciones de cualquier prueba o incidente.
- Revisa el acuerdo con el proveedor antes de modificar la capacidad operativa.
Preguntas frecuentes
¿Existe un límite TPS universal para SMS A2P por país?
La información disponible no permite establecer un valor universal. Confirma el límite con quien administra la ruta y documenta a qué destino, operador, remitente, sesión y ventana de medición aplica.
¿Que la solicitud haya sido aceptada significa que el SMS se entregó?
No. La aceptación indica que la solicitud fue admitida en un punto del proceso, pero no prueba por sí sola la entrega al teléfono. Interpreta por separado los estados posteriores y el grado de verificación que ofrecen.
¿SMPP o HTTP fijan la velocidad garantizada de una ruta?
No según la evidencia disponible. SMPP y HTTP especifican aspectos del intercambio técnico, pero sus especificaciones no establecen por sí solas una capacidad A2P garantizada por destino.
¿Qué hago si no están definidos los límites de ráfaga o concurrencia?
Pide una definición escrita y registra esos parámetros como no confirmados hasta recibirla. No infieras su valor a partir del TPS nominal ni de una prueba aislada.
¿Una prueba exitosa demuestra la capacidad sostenible de producción?
No necesariamente. Solo describe el comportamiento observado bajo las condiciones de esa prueba. El resultado no garantiza capacidad futura ni se puede extrapolar automáticamente a otros destinos, rutas o periodos.
Fuentes consultadas
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)Internet Engineering Task Force
- 3GPP specifications by series3GPP
- ITU-T Recommendation E.164International Telecommunication Union
- GSMA networks resourcesGSMA