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
PROTOCOLOS E APLICAÇÕES    (2)

Autor: João Bosco Silvino Júnior  

[Esta página contém muitas figuras. Aguarde a carga se a conexão estiver lenta] 


1 - Introdução

1.1 - Overview SMPP

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  

 

   
Figura 2 - Tipos de conexão SMPP


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.


2.2.1 - O OUTBIND

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


 

2.3       O PDU SMPP

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.


Anterior                               Home WirelessBR                              Próxima