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    (3)

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.

2.8 -  Temporizadores SMPP

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.

2.9Tipos de mensagens

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:

2.9.1 - SMSC Delivery Receipt

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:

  PDU SMPP

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.


3.2.1 - Layout do PDU SMPP  

 

 

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


3.2.2 - Tamanho 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.

 

3.2.3 - Parâmetros Opcionais

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.

Anterior                               Home WirelessBR                              Próxima