WirelessBR |
WirelessBr é um site brasileiro, independente, sem vínculos com empresas ou organizações, sem finalidade comercial, feito por voluntários, para divulgação de tecnologia em telecomunicações |
|
SMPP
- SHORT MESSAGE PEER TO PEER |
||
Autor: João Bosco Silvino Júnior |
[Esta página contém muitas figuras. Aguarde a carga se a conexão estiver lenta]
O
protocolo SMPP (Short Message Peer to Peer) é um protocolo aberto,
desenvolvido para proporcionar uma interface para a comunicação de dados
flexível, para a transferência de short messages entre um Short Message
Center (SMSC), GSM USSD (Unstructured Supplementary Services Data) ou outro
tipo qualquer de message center, e uma aplicação SMS, como por exemplo, uma
plataforma de Voice Mail, servidor de E-mail, Servidor Proxy WAP ou outra
gateway de mensagens qualquer.
Nota:
O protocolo SMPP utiliza o termo SMSC (Short Message Service Center) quando
se refere à entidade servidora da conexão SMPP. No caso da entidade cliente
da conexão SMPP, o nome adotado pelo protocolo é ESME (External Short
Message Entity)
A
versão V3.4 do protocolo SMPP contempla, dentre outras, as seguintes
tecnologias:
-
ANSI-136 (TDMA)
-
IS-95 (CDMA)
-
iDEN
O
protocolo SMPP permite:
- Transmitir mensagens de uma ESME para um único ou múltiplos destinos via SMSC;
- Que uma ESME possa receber mensagens de um terminal móvel via o SMSC;
- Enviar mensagens com confirmação de recebimento;
- Cancelar ou repor mensagens;
- Consultar o status de entrega de uma determinada mensagem;
- Agendar a entrega de mensagens, selecionando a data e a hora de entrega;
- Selecionar o modo de transmissão da mensagem, i.e. datagrama ou store and forward
- Definir prioridade de entrega para as mensagens;
- Definir o tipo de codificação dos dados da mensagem;
- Definir um período de validade para a mensagem;
- Associar um tipo de serviço para cada mensagem.
Figura 1 - Exemplos de aplicações que utilizam SMPP
O protocolo SMPP está sendo utilizado
recentemente para permitir a troca de SMS entre operadoras. Para este intuito
foram desenvolvidas gateways para trabalhar com este protocolo, convertendo-o
de uma tecnologia para outra (e.g. de TDMA para GSM). Este tipo de conversão
se faz bastante necessário no cenário brasileiro dada a diversidade de
tecnologias adotadas pelas operadoras. Têm-se como exemplo destas novas
aplicações os contratos de interconexão de SMS entre as operadoras TIM e
Telemig Celular, TIM e Telebahia Celular, TIM e Global Telecom, TIM e BCP,
Telemig Celular e TCO, Telesp Celular e BCP, Telesp Celular e TESS, dentre
outras.
2 - Overview do protocolo SMPP
2.1 - Definições do protocolo SMPP
O protocolo SMPP pode trafegar sobre a pilha TCP/IP ou X.25. Em linhas gerais, a filosofia do protocolo SMPP consiste em abrir sessões específicas, permanentes, semi-permanentes ou dinâmicas, entre cada entidade. Por estas sessões são enviados os pacotes ou PDU (Protocol Data Unit), contendo as informações daquela operação SMPP específica. Fazendo uma analogia, a seção seria como uma rodovia por onde trafegam os caminhões, neste caso PDU’s com as suas respectivas cargas, ou operações. Da mesma forma que uma rodovia, as sessões SMPP podem ser unidirecionais ou bidirecionais.
O SMPP utiliza um sistema de troca de mensagens e confirmações de recebimento para garantir a confiabilidade das transações. O protocolo SMPP define:
- Um conjunto de operações para a troca de mensagens entre a ESME e o SMSC;
- Os dados que uma entidade pode trocar com a outra, durante uma operação SMPP.
Todas as operações de envio de mensagens SMPP devem ser seguidas de uma mensagem de resposta. A única exceção à esta regra é no caso da mensagem de ALERT_NOTIFICATION, que não requer resposta.
Os três grupos distintos de transações de mensagens SMPP são os seguintes:
i) mensagens enviadas a partir da ESME para o SMSC;
ii) mensagens enviadas a partir do SMSC para a ESME;
iii) Mensagens trocadas entre a ESME e o SMSC simultaneamente;
A figura 2 mostra os três tipos de seção possíveis dentro do protocolo SMPP. Note o sentido de envio das mensagens.
(1) Conexão Transmitter
(2) Conexão Receiver
(3) Conexão Transceiver
2.2
- Descrição
de uma sessão SMPP
Uma
sessão SMPP entre uma ESME e um SMSC é iniciada pelo estabelecimento de um
link TCP/IP ou X.25 entre estas duas entidades. Em seguida a ESME, que segundo
a nossa definição é a entidade cliente da sessão SMPP, faz a solicitação
da conexão, chamada BIND. Se esta entidade deseja enviar mensagens, deve
fazer um “BIND TRANSMITTER”, se deseja receber mensagens, deve fazer um
“BIND RECEIVER” e se deseja tanto enviar quanto receber, deve fazer ou um
“BIND TRANSMITTER” e um “BIND RECEIVER” ou simplesmente um “BIND
TRANSCEIVER”. Os passos para esta conexão estão descritos abaixo:
-
OPEN (Conectado via TCP/IP
ou X.25, aguardando o BIND) A ESME já possui um caminho lógico via TCP/IP ou
X.25, entretanto ainda não solicitou a abertura da conexão SMPP;
-
BOUND_TX A ESME solicitou a
abertura da conexão SMPP transmitter, enviando um PDU (Protocol
Data unit) bind_transmitter.
Ao receber este PDU, o SMSC devolve um bind_transmitter_resp,
informando se aceitou ou não a conexão. Caso a conexão seja estabelecida, a
ESME já estará apta a enviar mensagens para o SMSC;
-
BOUND_RX A ESME solicitou a
abertura da conexão SMPP receiver, enviando um PDU bind_receiver.
Ao receber este PDU, o SMSC devolve um bind_receiver_resp,
informando se aceitou ou não a conexão. Caso a conexão seja estabelecida, a
ESME já estará apta a receber mensagens do SMSC;
- CLOSED A ESME solicitou a desconexão ao SMSC.
Uma outra operação do SMPP é o OUTBIND, que é a mensagem SMPP enviada pelo SMSC para a ESME, solicitando que a ESME envie um BIND_RECEIVER. Observe que a regra da ESME solicitar a conexão não foi quebrada, uma vez que o SMSC não estabeleceu a conexão e sim a ESME. O diagrama abaixo ilustra esta situação:
Figura 3 - A operação de OUTBIND
A tabela abaixo mostra em quais situações são aceitos cada tipo de PDU SMPP.
SMPP
PDU Name |
Required
SMPP Session State |
Issued
by ESME |
Issued
by SMSC |
Bind_transmitter |
OPEN |
Yes |
No |
bind_transmitter_resp |
OPEN |
No |
Yes |
bind_receiver |
OPEN |
Yes |
No |
bind_receiver_resp |
OPEN |
No |
Yes |
Bind_transceiver |
OPEN |
Yes |
No |
bind_transceiver_resp |
OPEN |
No |
Yes |
outbind |
OPEN |
No |
Yes |
Unbind |
BOUND_TX BOUND_RX BOUND_TRX |
Yes Yes Yes |
Yes Yes Yes |
unbind_resp |
BOUND_TX BOUND_RX BOUND_TRX |
Yes Yes Yes |
Yes Yes Yes |
submit_sm |
BOUND_TX BOUND_TRX |
Yes Yes |
No No |
submit_sm_resp |
BOUND_TX BOUND_TRX |
No No |
Yes Yes |
SMPP
PDU Name |
Required
SMPP Session State |
Issued
by ESME |
Issued
by SMSC |
submit_sm_multi |
BOUND_TX BOUND_TRX |
Yes Yes |
No No |
submit_sm_multi_resp |
BOUND_TX BOUND_TRX |
No No |
Yes Yes |
Data_sm |
BOUND_TX BOUND_RX BOUND_TRX |
Yes Yes Yes |
Yes Yes Yes |
Data
_sm_resp |
BOUND_TX BOUND_RX BOUND_TRX |
Yes Yes Yes |
Yes Yes Yes |
deliver_sm |
BOUND_RX BOUND_TRX |
No No |
Yes Yes |
deliver_sm_resp |
BOUND_RX BOUND_TRX |
Yes Yes |
No No |
query_sm |
BOUND_TX BOUND_TRX |
Yes Yes |
No No |
query_sm_resp |
BOUND_TX BOUND_TRX |
No No |
Yes Yes |
cancel_sm |
BOUND_TX BOUND_TRX |
Yes Yes |
No No |
cancel_sm_resp |
BOUND_TX BOUND_TRX |
No No |
Yes Yes |
replace_sm |
BOUND_TX |
Yes |
No |
replace_sm_resp |
BOUND_TX |
No |
Yes |
enquire_link |
BOUND_TX BOUND_RX BOUND_TRX |
Yes Yes Yes |
Yes Yes Yes |
enquire_link_resp |
BOUND_TX BOUND_RX BOUND_TRX |
Yes Yes Yes |
Yes Yes Yes |
alert_notification |
BOUND_RX BOUND_TRX |
No No |
Yes Yes |
generic_nack |
BOUND_TX BOUND_RX BOUND_TRX |
Yes Yes Yes |
Yes Yes Yes |
2.4
- A camada de conexões de rede SMPP
A camada inferior ao nível SMPP é a camada de transporte, que pode ser TCP/IP ou X.25. No caso das interconexões realizadas com o ISR até a presente data, utilizamos o protocolo TCP/IP. Por ser um protocolo do nível de aplicação, o SMPP não se preocupa com o transporte da mensagem, deixando esta tarefa a cargo da camada inferior. Esta camada deverá prover a confiabilidade necessária para a troca de mensagens. Se necessário, é possível solicitar a segmentação do pacote SMPP à entidade de nível inferior(TCP/IP ou X.25) que irá enviá-la. Ao recebê-la, a entidade de nível inferior do outro lado deverá reorganizar o pacote e entregá-lo para o nível superior.
2.5 - Mensagens enviadas da ESME para o SMSC
Uma ESME que envia short messages para um SMSC deve estar conectada a este SMSC como ESME Transmitter ou ESME Transceiver (vide tabela 1). Exemplos de PDU’s que podem ser enviados para a entrega de mensagens ou dados são os PDU’s submit_sm e data_sm. Os PDUS query_sm, cancel_sm e replace_sm são utilizados para controlar as mensagens enviadas para o SMSC, permitindo que a ESME possa questionar qual é o status de uma determinada mensagem, cancelar uma mensagem ou substituir uma mensagem, respectivamente. Deve-se observar que sempre que uma mensagem destas enviada, o SMSC deve responder com a mensagem de resposta correspondente, contendo o status da operação. A única exceção é a operação alert_notification. Estas mensagens serão detalhadas mais adiante.
2.5.1 - Respostas de mensagens SMPP do SMSC para a ESME
Conforme dito anteriormente, para cada envio de operação SMPP, a parte recebedora do PDU deve sinalizar o recebimento do pacote com uma mensagem de resposta, indicando o status da operação. Desta forma, as mensagens de resposta, enviadas pelo SMSC, em resposta aos pacotes enviados pela ESME são as mensagens submit_sm_resp, data_sm_resp, query_sm_resp, cancel_sm_resp e replace_sm_resp. Estas mensagens serão detalhadas mais adiante.
2.5.2 - Exemplo de uma sessão típica SMPP – ESME Transmitter
A figura abaixo mostra como é a seqüência de mensagem/resposta em uma sessão SMPP – ESME Transmitter
fig 4. Exemplo típico de uma seção SMPP – ESME Transmitter
A troca de mensagens e respostas entre a ESME e o SMSC pode ocorrer de forma síncrona (mensagens 1 e 2) ou assíncrona (mensagens 3, 4 e 5). A primeira é chamada Stop and Wait e a segunda é chamada Sliding Window, Janela Deslizante, ou simplesmente Janelamento.
Uma série de mensagens enviadas de forma assíncrona deve ser seguida de uma série de respostas em seqüência, respeitando a ordem de recebimento das mensagens, entretanto o funcionamento desta forma não é mandatório na especificação do protocolo. A entidade recebedora deve ser capaz de gerenciar estas mensagens. A quantidade de mensagens enviadas é chamada de janela ou window. No caso da figura 4, a janela utilizada foi de três mensagens.
O protocolo não estabelece um tamanho máximo para a janela a ser utilizada, entretanto, recomenda-se que não sejam utilizadas janelas maiores do que 10(dez) mensagens.
A ESME deve retornar as respostas na mesma ordem em que recebeu as mensagens. O único PDU de resposta relevante que a ESME passa para o SMSC é o enquire_link_response.