Transbordo de tráfego A2P SMS: guia operacional
Saiba como avaliar uma rota alternativa perante uma insuficiência temporária de capacidade, limitar o tráfego desviado e registar decisões sem confundir um DLR com a confirmação de receção no terminal.
O que o transbordo resolve — e o que não resolve
O transbordo é uma política que distribui ou admite parte do tráfego por uma rota alternativa quando a capacidade disponível na rota principal é insuficiente. O objetivo é gerir essa insuficiência temporária; não torna automaticamente equivalente uma rota alternativa nem demonstra que a mensagem chegou ao terminal.
Convém distingui-lo de outros mecanismos. O failover costuma descrever a mudança perante a indisponibilidade de uma rota. O fallback é a utilização de uma opção alternativa quando uma operação ou condição definida falha. O backpressure limita ou retém a entrada para não sobrecarregar um sistema. O planeamento de TPS procura dimensionar antecipadamente a procura e a capacidade. Estes termos podem sobrepor-se numa implementação, pelo que a equipa deve documentar que condição desencadeia cada ação.
- Antes de desviar tráfego, definam se a causa é capacidade insuficiente, indisponibilidade, falha de conectividade ou outro erro.
- Não tratem todas as rejeições como saturação: um código ou uma mensagem de erro deve ser interpretado de acordo com a documentação acordada com cada ligação.
- O transbordo não corrige problemas de permissões, remetente, conteúdo, destino ou configuração.
Confirmar o sinal antes de desviar
A evidência disponível não estabelece uma lista universal de códigos de rejeição que permita distinguir a saturação de outras falhas. Por isso, a primeira tarefa operacional é acordar com cada fornecedor ou ligação como são representadas as rejeições por falta de capacidade e que outros erros podem ser semelhantes.
Analisem o sinal em conjunto com o contexto: volume oferecido, respostas da ligação, dimensão e evolução das filas, disponibilidade observada e confirmação da capacidade na alternativa. Uma fila crescente pode indicar pressão, mas, por si só, não demonstra que a causa esteja na rota. Se a causa continuar ambígua, limitem ou suspendam o envio de acordo com a vossa política interna, em vez de presumirem que o desvio resolverá o problema.
- Conservem a resposta original e a respetiva marca temporal; não a reduzam a uma categoria genérica sem guardar os detalhes.
- Verifiquem se a rota alternativa tem capacidade confirmada para o destino e o tipo de tráfego antes de lhe encaminharem carga.
- Separem as falhas de capacidade dos erros de formato, autorização, remetente, conectividade e destino, quando a documentação da ligação o permitir.
Definir os critérios de elegibilidade antes de ativar a rota
A rota alternativa deve estar autorizada para o tráfego em causa. Antes de a utilizar, verifiquem o destino, o remetente, o conteúdo e a classe da mensagem, de acordo com os acordos aplicáveis e as regras em vigor. Não presumam que uma rota disponível para um país, operador ou tipo de tráfego também aceita automaticamente os restantes.
A disponibilidade técnica também não comprova que a mensagem seja permitida ou que exista consentimento. O transbordo deve manter os controlos de conformidade, consentimento e preferências que aplicam na rota principal.
- Documentem os destinos e remetentes aceites por cada alternativa com informação contratual ou técnica atualizada.
- Confirmem que o conteúdo e a classe de tráfego são compatíveis com a ligação e com as regras aplicáveis.
- Se não houver evidência suficiente sobre a elegibilidade, excluam esse tráfego da política de transbordo até a verificarem.
Definir limites e limiares sem inventar valores padrão
Não existe aqui um limiar universal comprovado para ativar o transbordo. Os valores devem ser definidos com base nos dados próprios, na capacidade acordada e nos objetivos operacionais. Especifiquem que métrica desencadeia a decisão — por exemplo, rejeições confirmadas por falta de capacidade ou evolução da fila —, durante que janela é avaliada e quem pode ajustar a política.
A histerese ajuda a evitar mudanças repetidas entre rotas quando uma métrica oscila perto do limiar: pode definir-se uma condição de entrada e outra, distinta, para deixar de desviar. Este é um princípio de conceção, não um valor prescrito. Também devem existir limites de volume ou velocidade para evitar que a alternativa receba mais tráfego do que a capacidade confirmada permite.
- Escolham janelas de observação de acordo com o comportamento medido e a latência dos sinais disponíveis.
- Definam limites explícitos por rota e, quando aplicável, por destino ou classe de tráfego; não excedam a capacidade confirmada.
- Definam condições distintas para iniciar e terminar o desvio, bem como a pessoa ou equipa responsável pela decisão.
- Revejam os limites após alterações de capacidade, configuração ou acordos; não apresentem parâmetros internos como padrões do setor.
Evitar duplicados quando o resultado é incerto
Se o envio pela rota principal ficar num estado incerto, reenviá-lo por outra rota pode resultar numa segunda entrega. A evidência fornecida não permite afirmar que exista uma regra universal para evitar duplicados nem que todas as ligações utilizem a mesma semântica de estados.
Definam uma política explícita para estados ambíguos e baseiem-na na documentação das ligações. Antes de reenviar, registem que resultado é conhecido e qual não é. Não interpretem a ausência de um DLR como prova de que a mensagem não foi entregue, nem assumam que a aceitação pela ligação equivale a entrega.
- Distingam entre mensagem rejeitada, aceite pela ligação, pendente e resultado desconhecido, sempre que a interface o permita.
- Acordem com os responsáveis pelas rotas como tratar cada estado antes de automatizarem novas tentativas ou desvios.
- Se não conseguirem determinar o resultado anterior, adotem uma política conservadora que evite reenvios automáticos sem justificação.
Monitorizar a alternativa e interpretar os DLR com cautela
Durante o transbordo, comparem o volume oferecido com o aceite por cada ligação e acompanhem as rejeições, as filas, a latência disponível e os estados reportados. Analisem os resultados por destino e classe de tráfego para detetar se o problema está concentrado e evitar que um sinal agregado oculte uma falha específica.
Um DLR é um estado comunicado pela cadeia de entrega. Por si só, não deve ser tratado como prova independente de que a mensagem foi recebida no terminal. Conservem a definição do estado fornecida pela ligação e distingam o que o sistema reporta daquilo que pode ser verificado de forma independente.
- Registem, por rota, as quantidades oferecidas, aceites e rejeitadas, além dos estados e das marcas temporais disponíveis.
- Acompanhem a latência e a disponibilidade observadas sem transformar uma medição isolada numa garantia futura.
- Comparem a rota principal com a alternativa segundo critérios coerentes e discriminados por destino, quando os dados o permitirem.
Parar, regressar à rota principal e escalar
O fim do transbordo também deve ser definido antecipadamente. Especifiquem que evidência indica que a rota principal recuperou capacidade, durante quanto tempo essa condição deve manter-se de acordo com a vossa janela de observação e como evitar um regresso prematuro. Não são fornecidos valores universais para estes parâmetros.
Parem ou reduzam o desvio se a alternativa atingir o seu limite, apresentar sinais de degradação ou deixar de ser elegível para o tráfego. Escalem quando não for possível confirmar a causa, a capacidade ou o estado das mensagens e mantenham o tráfego sujeito aos controlos operacionais e de conformidade existentes.
- Utilizem condições de saída diferentes das condições de entrada para reduzir as oscilações entre rotas.
- Assegurem que o regresso à rota principal é gradual ou controlado, de acordo com a capacidade confirmada e a conceção do sistema.
- Escalem de acordo com as responsabilidades e os acordos definidos previamente; não presumam que uma mudança de rota resolverá uma falha de origem desconhecida.
Manter um registo auditável
Um registo útil permite reconstruir o que foi observado, por que motivo foi tomada uma decisão e o que aconteceu depois. A evidência disponível não estabelece campos obrigatórios; cada organização deve, por isso, defini-los de acordo com as suas necessidades operacionais, de conformidade e de conservação.
Como base prática, associem a decisão ao intervalo observado, à rota afetada, ao destino ou grupo de tráfego relevante, aos sinais consultados, ao limite aplicado, à pessoa ou sistema que autorizou a ação e às horas de ativação e desativação. Guardem também as respostas e os estados disponíveis, distinguindo os dados reportados dos factos verificados.
- Conservem a causa atribuída e as evidências que a sustentam, incluindo a resposta técnica original, sempre que possível.
- Registem o volume de tráfego desviado e os resultados observados, sem os transformar numa garantia de entrega.
- Anotem alterações manuais, exceções, escalamentos e a justificação para voltar a tentar ou não reenviar mensagens com resultado incerto.
- Revejam o registo após o incidente para ajustar a política com base nos dados próprios e na capacidade confirmada.
Perguntas frequentes
Quando convém ativar o transbordo de tráfego A2P SMS?
Quando a insuficiência de capacidade é sustentada por sinais interpretáveis e a capacidade e a elegibilidade da rota alternativa estão confirmadas. Se a causa da rejeição for incerta, não a classifiquem automaticamente como saturação.
Que limiar de transbordo deve ser utilizado?
Não existe aqui um valor universal comprovado. Definam-no com base nos dados próprios, na capacidade acordada, nas janelas de observação e numa condição de desativação distinta; limitem sempre o tráfego à capacidade confirmada para a alternativa.
Um DLR confirma que o SMS chegou ao telemóvel?
Por si só, não deve ser tratado como prova independente de receção no terminal. Interpretem o estado de acordo com a semântica comunicada pela ligação e distingam-no de uma verificação independente.
Deve reenviar-se por outra rota um SMS com resultado incerto?
Não automaticamente, sem uma política acordada: o reenvio pode gerar duplicados, e a ausência de um estado conclusivo não demonstra que a primeira tentativa não tenha sido entregue. Consultem a semântica da ligação e registem a decisão.
A BulkSMSMarket oferece atualmente transbordo automático em produção?
A informação disponível descreve uma plataforma em desenvolvimento para descobrir, comparar, comprar, vender e gerir capacidade A2P SMS, além de conectividade HTTP e SMPP e consultas HLR. O backend público de encaminhamento em tempo real ainda não está disponível; não se deve presumir que o transbordo automático seja uma funcionalidade ativa.
Fontes consultadas
- 3GPP specifications3GPP
- ITU-T E.164International Telecommunication Union
- GSMA resourcesGSMA