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]
2.6 - Mensagens enviadas pelo SMSC para a ESME
Uma ESME que recebe short messages para um SMSC deve estar conectada a este SMSC como ESME Receiver 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 deliver_sm e data_sm. 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. Estas mensagens serão detalhadas mais adiante.
2.6.1 - Respostas de mensagens SMPP da ESME para o SMSC
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 pela ESME, em resposta aos pacotes enviados pelo SMSC são as mensagens deliver_sm_resp e data_sm_resp. Estas mensagens serão detalhadas mais adiante.
2.6.2 - Exemplo de uma sessão típica SMPP – ESME Receiver
A figura a seguir mostra como é a seqüência de mensagem/resposta em uma sessão SMPP – ESME Receiver
Figura 5 - Exemplo típico de uma seção SMPP – ESME Receiver
Da mesma forma como mostrado anteriormente, no caso da ESME Transmitter, a ESME receiver também pode trabalhar com o controle de fluxo utilizando o Stop and Wait ou Windowing.
2.7 - Envio de mensagens bidirecional entre uma ESME e um SMSC
Um SMSC e uma ESME podem operar com uma sessão duplex para o envio de mensagens. Neste caso a ESME deve estar conectada ao SMSC como uma ESME Transceiver. Exemplos de PDU’s SMPP que podem ser enviados e recebidos em uma sessão SMPP Transceiver são submit_sm, deliver_sm, data_sm, query_sm, cancel_sm e replace_sm.
Um exemplo de utilização deste tipo de sessão é a conexão entre um WAP Proxy e um SMSC. O usuário solicita uma informação ao gateway e este retorna esta informação para o usuário via SMSC
O único PDU SMPP que pode ser enviado e não necessita de uma mensagem de resposta da outra entidade é o allert_notification.
2.7.1 Exemplo de uma sessão típica SMPP – ESME Transceiver
A figura a seguir mostra como é a seqüência de mensagem/resposta em uma sessão SMPP – ESME Transceiver
Figura
6 - Exemplo típico de uma seção SMPP – ESME Receiver
Da mesma forma como foi visto anteriormente, é possível trabalhar com controle de fluxo por Stop and Wait e janelamento, também em sessões ESME Transceiver.
2.7.2 - Gerenciamento de erros no SMPP
Todas as operações SMPP são seguidas do
respectivo PDU de resposta, exceto a operação alert_notification.
A função do PDU de resposta é informar à entidade remetente que o PDU foi
recebido, assim como qual foi o resultado da operação solicitada. Caso a
operação solicitada seja concluída com sucesso, o campo command_status
do PDU de resposta virá preenchido com um OK.
Caso seja encontrada alguma não conformidade no campo de dados do pacote,
i.e. a configuração errônea de um parâmetro, este campo virá preenchido
com o código de erro correspondente. Caso seja encontrado algum erro no cabeçalho
do PDU, a entidade de destino irá responder com um “GENERIC_NACK” PDU,
significando que não foi possível a identificação do tipo de PDU recebido.
Para garantir a eficiência nas transações SMPP, é recomendável que cada sessão SMPP seja gerenciada utilizando temporizadores configuráveis, tanto na ESME, quanto no SMSC, de acordo com as seguintes considerações:
- Um temporizador inicial para garantir que quando uma ESME inicia uma sessão SMPP, isto ocorra dentro de um determinado período, após a abertura da conexão de rede entre as plataformas;
- Um temporizador para permitir que tanto a ESME quanto o SMSC verifiquem o status da conexão via o comando enquire_link;
- Uma inatividade da conexão SMPP deve especificar um período máximo para a espera por novas mensagens, após o qual a conexão poderá ser finalizada;
- Um temporizador SMPP que irá especificar qual é o maior tempo permitido entre a chegada de uma mensagem e o envio de uma resposta.
Trataremos dos temporizadores SMPP
mais adiante.
Complementando os tipos “normais” de short messages, mensagens especiais podem ser transferidas entre ESME e SMSC em uma operação submit_sm, deliver_sm ou data_sm. O tipo destas mensagens é definido no parâmetro esm_class destas operações SMPP. Os tipos suportados são os seguintes:
Esta mensagem é usada para transportar um recibo de entrega da mensagem por uma SMSC. A SMSC, detectando que o destino final da mensagem foi alcançado, deve gerar um recibo de entrega para a entidade originadora da mensagem. O recibo de entrega é codificado como um pacote de dados do usuário, na operação deliver_sm ou data_sm. Os campos abaixo são relevantes nas operações deliver_sm ou data_sm, quanto utilizadas para transportar recibos de entrega de mesangens:
-
source
address (i.e.
source_addr_ton, source_addr_npi, source_addr)
O endereço fonte é obtido a partir do endereço de destino na mensagem original;
-
destination address
(i.e. dest_addr_ton, dest_addr_npi, destination_addr)
O endereço fonte é obtido a partir do endereço fonte na mensagem original;
-
esm_class
-
message_state
-
network_error_code
-
receipted_message_id
2.9.2 - Notificação Intermediária
Uma notificação intermediária é uma forma especial de mensagem que o SMSC utiliza para enviar para a ESME mensagens que deverão ser entregues em um destinatário específico. Isto proporciona um status intermediário da entrega da mensagem. As aplicações típicas são:
- Proporcionar uma notificação de “capacidade de memória excedida” para uma plataforma Voice Mail;
- Informar a primeira tentativa de entrega de uma mensagem que, por não ter sido entregue, foi armazenada para tentativas futuras.
2.9.3 - SME Deliver Acknowledgement
Apesar do nome, a mensagem com o tipo SME Deliver Acknowledgement não é uma confirmação de que a mensagem foi entregue e sim uma confirmação de que a mensagem foi lida pelo destinatário. Esta facilidade é encontrada principalmente nos aparelhos Nokia, onde pode-se definir no menu de configuração de mensagem se é necessária uma confirmação de leitura para a mesma. Este tipo de mensagem não é suportado em todos os tipos de rede.
3 - Tipos de PDU’s SMPP e definições de formato
3.1 - Definições dos tipos de dados do PDU SMPP
Os seguintes tipos de dados são utilizados para definir parâmetros SMPP:
Integer Um valor indeterminado que define o número de octetos. Os octetos serão sempre transmitidos com o bit mais significativo primeiro (Big Endian).
C-Octet String Uma série de caracteres ASCII, terminados com o caractere NULO
C-Octet String Uma série de caracteres ASCII, onde cada caractere representa
(decimal) um dígito decimal (de 0 a 9) e termina com o caractere NULO
C-Octet String Uma série de caracteres ASCII, onde cada caractere representa
(HEXA) um dígito hexadecimal (de 0 a F) e termina com o caractere NULO
Octet String Uma série de octetos, não necessariamente terminada com o caractere NULO
3.1.1
Notação do tamanho dos campos dos parâmetros SMPP
A seguinte notação será utilizada nesta documentação para os parâmetros descritos:
| Size
octets |
Type |
Description
of String type specified |
| 4 |
Integer |
Fixed
size integer field. In this example the integer is of size 32 bits
(4 octets) |
| Var Max
16 |
C-Octet String |
This
string is of variable length from 1-15 ASCII characters, followed
by an octet containing the NULL terminator. An
empty string is encoded as a single octet containing the NULL
character (0x00). |
| Fixed 1
or 17 |
C-Octet String |
This
string has two possible lengths:- 1
octet containing the NULL character or a
fixed number of characters terminated with the NULL character
(in this example 16 characters plus the NULL character). |
|
Var 0
- 254 |
Octet
String |
Variable
size octet string field. In this example the size of the octet
string field can vary from 0 to 254 octets. |
Tabela 2 - Notação do tamanho dos parâmetros
3.2 - Overview do formato do PDU SMPP
O formato geral do PDU SMPP consiste de um cabeçalho PDU, seguido de um pacote de dados, tal como a maioria dos PDU’s dos sistemas de comunicação digital. Este formato está descrito abaixo:
|
|
||||
|
Cabeçalho
do PDU SMPP (Mandatório) |
Corpo
do PDU (Opcional) |
|||
|
Command length |
Command Id |
Command status |
Sequence number |
Campo
de dados |
| 4
Octetos
|
Comprimento=(tamanho informado no command length - 4 Octetos |
|||
Tabela 3 - Formato do PDU SMPP
O cabeçalho SMPP é mandatório em qualquer PDU e deve sempre estar presente. O campo de dados do PDU é opcional e pode não estar presente na mensagem. O formato de cada PDU SMPP será mais detalhado adiante.
|
|
SMPP
PDU Field |
Size Octets |
Type |
Description |
|
header |
command_length |
4 |
Integer |
The
command_length field
defines the total octet length of the SMPP PDU packet including the
length field. |
| command_id |
4 |
Integer |
The
command_id field
identifies the particular SMPP PDU, e.g., submit_sm,
query_sm,
etc. A
unique command identifier is allocated to each SMPP request PDU in
the range: 0x00000000 to 0x000001FF A unique command identifier is
also allocated to each SMPP response PDU in the range: 0x80000000 to
0x800001FF (Note
that an SMPP response command_id
is identical to the corresponding request SMPP command_id,
but with bit 31 set). Refer to chapter 5. for details of the
complete SMPP Command ID set. |
|
| command_status |
4 |
Integer |
The
command_status field
indicates the success or failure of an SMPP request. It is relevant
only in the SMPP response PDU and it must contain a NULL value in an
SMPP request PDU. The
complete list of SMPP Error codes is defined in Chapter 5. |
|
| sequence_number |
4 |
Integer |
This
field contains a sequence number which allows SMPP requests and
responses to be associated for correlation purposes. The use of
sequence numbers for message correlation allows SMPP PDUs to be
exchanged asynchronously. Assignment
of the sequence_number is
the responsibility of the SMPP PDU originator. The sequence_number
should be increased monotonically for each submitted SMPP
request PDU and must be preserved in the associated SMPP response
PDU. The
sequence_number may range
from: 0x00000001 to 0x7FFFFFFF. |
|
|
body |
Mandatory Parameters |
var.
|
mixed |
A
list of mandatory parameters corresponding to that SMPP PDU defined
in the command_id field. The
complete list of mandatory parameters is detailed in section 4.
"SMPP PDU Definition" with the description of each SMPP
PDU. |
|
Optional Parameters |
|
|
A
list of Optional Parameters corresponding to that SMPP PDU defined
in the command_id field
and included as required. The
complete list of optional parameters is detailed in section 4.
"SMPP PDU Definition" with the description of each SMPP
PDU. |
Tabela 4 - Descrição do formato do PDU SMPP
O campo command_length no começo do cabeçalho do PDU SMPP indica o tamanho total do PDU SMPP em número de octetos. O campo command_length contem um inteiro de 4 octetos, transmitido no formato Big Endian.
Para decodificar um PDU SMPP, a ESME ou o SMSC
deve primeiro ler o command_length para
determinar o tamanho deste PDU. O valor indicado neste campo é subtraído de
quatro octetos, sendo que o valor resultante corresponde ao tamanho restante
da mensagem.
Exemplo:
Suponhamos que uma mensagem tenha a seguinte seqüência de dados no cabeçalho:
00
00 00 2F 00 00
00 02 00 00 00 00 00 00 00 01 53 4D 50 50 33 54 45 53 54 00
73
65 63 72 65 74 30 38 00 53 55 42 4D 49 54 31 00 00 01 01 00
Os valores estão representados em formato hexadecimal. Desta forma, decodificando a seqüência acima obtemos:
00
00 00 2F Command Length 0x0000002F
00
00 00 02 Command ID 0x00000002 (bind_transmitter)
00
00 00 00 Command Status 0x00000000
00
00 00 01 Sequence Number 0x00000001
Os dados restantes representam o campo de dados do PDU SMPP, cujo exemplo corresponde à um PDU da operação BIND_TRANSMITTER.
Parâmetros Opcionais são campos que podem estar presentes nas mensagens SMPP. Estes parâmetros fornecem mecanismos para a introdução futura de novos parâmetros, à medida que forem definidos em futuras versões do protocolo SMPP.
Os parâmetros opcionais devem sempre aparecer no final do PDU SMPP. Entretanto eles podem ser incluídos em qualquer ordem conveniente, dentro da seção de parâmetros opcionais do PDU SMPP.
Para um PDU SMPP em particular, a ESME ou o SMSC devem incluir todos ou nenhum dos parâmetros opcionais definidos como o necessário no contexto da aplicação em particular. Por exemplo, sistemas de paging podem precisar somente de incluir o campo relacionado ao “callback number” em uma operação de submit_sm.
3.2.4 - Formato dos parâmetros opcionais
Todos os parâmetros opcionais devem seguir o seguinte formato TLV (Tag Length Value) ou ICV (Identificador Comprimento Valor).
|
Parameter
Name |
Size |
Type |
Description |
|
Tag |
2 |
Integer |
The
Tag field is used to
uniquely identify the particular optional parameter in question. The
optional parameter Tag field
is always 2 octets in length. |
|
Length |
2 |
Integer |
The
Length field indicates
the length of the Val u e field
in octets. Note that this length does not include the length
of the Tag and Length
fields. The
optional parameter Length field
is always 2 octets in length. |
|
Value |
variable |
variable |
The
Val u e field contains
the actual data for the optional parameter in question. |
Tabela 5 - Formato dos parâmetros
opcionais
3.2.5 - Premissas para a compatibilidade do SMPP com versões mais avançadas
Um procedimento para compatibilidade com versões mais avançadas permite que uma entidade funcional (i.e. SMSC ou ESME) utilize uma versão do protocolo SMPP para comunicar-se com uma outra entidade utilizando uma versão mais aprimorada do protocolo. Desta forma, novos desenvolvimentos para PDU’s SMPP existentes são implementados utilizando parâmetros opcionais.
As seguintes premissas devem ser seguidas para garantir esta compatibilidade:
- Se uma entidade SMPP recebe um PDU ou comando desconhecido, esta entidade deve retornar um PDU generic_nack, indicando um command_id no campo command_status do cabeçalho.
- A entidade SMPP que recebe uma mensagem que possui Parâmetros Opcionais deve primeiramente inspecionar o campo de identificador do Parâmetro Opcional, da seguinte forma:
. Se o identificador do Parâmetro Opcional for reconhecido e suportado pela entidade SMPP, para aquela aplicação em particular, este parâmetro deverá ser processado;
. Se o identificador do Parâmetro Opcional for reconhecido mas não for esperado pela entidade SMPP, para aquela operação em particular, este parâmetro deverá ser ignorado;
.
Se o identificador do Parâmetro Opcional não for reconhecido ou não
suportado pela entidade SMPP, para aquela operação em particular, este parâmetro
deverá ser ignorado e o próximo parâmetro opcional da seqüência deverá
ser processado;
- Uma entidade SMPP que recebe um parâmetro com o valor “reservado”, deve utilizar o valor padrão, se uma configuração padrão é definida, caso contrário o parâmetro deverá ignorado;
- Se um valor de um parâmetro é desconhecido ou inválido, a entidade SMPP deve retornar um erro, indicando que o valor daquele parâmetro é inválido;
- Uma entidade SMPP que detecta que um parâmetro opcional, necessário naquela operação específica, não estava presente no PDU SMPP, deve retornar uma mensagem com um erro dizendo “Expected Optional Parameter missing”.
- Um campo com tamanho variável pode ter seu comprimento máximo estendido em versões futuras do protocolo SMPP. Uma entidade SMPP que recebe um parâmetro cujo comprimento é maior do que o suportado por aquela entidade deve rejeitar aquele parâmetro com o código de erro indicando “invalid parameter length”.
3.2.6 - Premissas para a compatibilidade do SMPP com versões mais atrasadas
Um procedimento para compatibilidade com versões mais atrasadas permite que uma entidade funcional (i.e. SMSC ou ESME) utilize uma versão do protocolo SMPP para comunicar-se com uma outra entidade utilizando uma versão mais antiga do protocolo.
As seguintes premissas devem ser seguidas para garantir esta compatibilidade:
- PDU’s existentes não devem ser removidos do protocolo;
- O efeito de uma mensagem existente, recebida em um novo formato modificado, deve ter o mesmo efeito que seria esperado quando utilizado um protocolo anterior;
- Parâmetros Opcionais não deverão tornar-se mandatórios e vice-versa.
- Novos parâmetros mandatórios não deverão ser adicionados;
- O significado de parâmetros existentes não deverá ser mudado em novas versões do protocolo;
Como o conceito de Parâmetros Opcionais foi introduzido nesta versão do protocolo, as seguintes premissas foram definidas:
- Um SMSC que trabalha com SMPP v3.4 ou superior não deve enviar parâmetros opcionais para uma ESME que utilize versões inferiores. Uma SMSC, que suporta uma versão anterior à v3.4, deverá preencher o parãmetro interface_version comum valor menor que 0x34;
- Um SMSC, que suporta uma versão igual ou superior à v3.4, deverá preencher o parãmetro sc_interface_version com o valor suportado;
Um SMSC que trabalha com uma versão do SMPP igual ou superior à v3.4 não deve gerar message ID’s maiores que 8 (oito) octetos, quando esta comunicando-se com uma ESME que utilize uma versão mais antiga do SMPP.