PROTOCOLO SMPP

PROTOCOLO
SMPP
X.25
1
MC/ SMSC
Página
ESME
INDICE
INDICE ..................................................................................................................................................... 2
Short Message Peer to Peer (SMPP) ......................................................................................................... 4
Message Centre (MC)........................................................................................................................... 4
External Short Message Entity (ESME) .................................................................................................. 4
Routing Entity (RE) ............................................................................................................................... 4
Descripción breve ................................................................................................................................ 5
Short Message Peer to Peer Protocol (Protocolo de Mensaje Corto entre iguales)............................... 5
Tecnologías Celulares Soportadas .................................................................................................... 5
Aplicaciones típicas de SMPP ............................................................................................................... 5
Sesiones SMPP ..................................................................................................................................... 6
Hay 3 formas de inicio de Sesión ESME. ............................................................................................ 6
1-TX Transmitter .......................................................................................................................... 6
2-RX Receiver ............................................................................................................................... 6
3-TRX Transceiver ......................................................................................................................... 6
Operaciones de Protocolo y PDU´s (Protocol Data Unit) ....................................................................... 6
Administración de Sesión. ................................................................................................................ 7
Mensaje de Presentación (Submission). ........................................................................................... 7
Entrega de Mensajes. ....................................................................................................................... 7
Mensaje de Difusión (Broadcasting) ................................................................................................. 7
Operaciones Auxiliares ..................................................................................................................... 7
Estableciendo una Sesión SMPP .......................................................................................................... 7
Estados de una Sesión SMPP ............................................................................................................ 7
Open ............................................................................................................................................ 7
Bound_TX..................................................................................................................................... 8
Bound_RX .................................................................................................................................... 8
Bound_TRX................................................................................................................................... 9
Unbound ...................................................................................................................................... 9
Ejemplo de Sesiones SMPP ................................................................................................................ 11
Sincrono y Asincrono ......................................................................................................................... 16
Página
Outbound ................................................................................................................................... 10
2
Closed .......................................................................................................................................... 9
¿Por qué Asíncrona? ...................................................................................................................... 17
Manejo de Errores ............................................................................................................................. 18
Manejo de Fallas de Conexión ........................................................................................................ 18
Fallas de Operación ............................................................................................................................ 19
El PDU no es reconocido................................................................................................................. 19
El PDU es incorrecto. ...................................................................................................................... 19
Longitud de campo invalido............................................................................................................ 19
El dato PDU es inesperado y se considera invalido (PDU data unexpected and deemed invalid). ... 19
PDU no permitida en el estado de sesión actual. ............................................................................ 19
Las ESME´s o MC restringen el uso de características de ciertos PDU´s. .......................................... 19
Parámetros SMPP y formato de PDU .................................................................................................. 20
Definiciones SMPP PDU...................................................................................................................... 20
1-Operación de Gestión de Sesión
Session Management ........................................................ 20
PDU BIND ................................................................................................................................... 20
PDU UNBIND .............................................................................................................................. 21
PDU ENQUIRE LINK..................................................................................................................... 21
2-Presentacion de Mensajes
Message Submission.................................................................. 22
PDU SUBMIT_SM........................................................................................................................ 22
3-Operaciones de entrega de Mensajes
Message Delivery Operations ................................... 22
PDU DELIVER_SM ....................................................................................................................... 22
4-Difusión de mensaje
Message Broadcast ................................................................................. 23
5-Presentación auxiliar
Ancilliary Submission............................................................................. 23
PDU CANCEL_SM........................................................................................................................ 23
PDU QUERY_SM ......................................................................................................................... 24
Página
3
PDU REPLACE_SM ...................................................................................................................... 24
Short Message Peer to Peer (SMPP)
SMPP, es un protocolo abierto, diseñado para proporcionar un interfaz de comunicacion para la
transferencia de mensajes cortos (SM) entre External Short Message Entities (ESMES), Routing
Entities (RE), y Message Centres (MC).
Message Centre (MC)
Un Message Centre (MC) o Centro de Mensajes es un término genérico utilizado para describir sistemas
tales como un Short Message Service Centre (SMSC), GSM Unstructured Supplementary Services Data
(USSD) o Cell Broadcast Centre (CBC).
External Short Message Entity (ESME)
Un ESME típicamente representa un cliente SMS de una red fija/una entidad de red, tal como un Server
Proxy WAP, un Email Gateway, un Servidor de Mensajería de voz (Voice Mail Server). También puede
representar un Cell Broadcast Entity (CBE).
Routing Entity (RE)
Un Routing Entity (RE) o Entidad de ruteo es un término genérico para un elemento de red que es
utilizado por un MC to MC y un ESME to MC para ruteo de mensajes. Un SMPP RE tiene la capacidad
de emular la funcionalidad de asociación tanto de un MC como de un ESME o de ambos a la vez. Para
un ESME, un RE aparece como un MC y para un MC, un RE aparece como un ESME.
Un Carrier puede utilizar RE´s para ocultar una red de MC´s, presentando únicamente las RE´s como el
punto de interfaz externo para las ESME´s.
Página
4
El siguiente diagrama muestra el contexto de SMPP en una red Mobile.
Descripción breve
Short Message Peer to Peer Protocol (Protocolo de Mensaje Corto entre
iguales)
Tecnologías Celulares Soportadas
SMPP está diseñado para soportar funcionalidades short messaging para cualquier tecnología celular
como:
GSM
UMTS
IS-95 CDMA
CDMA2000
ANSI-136 TDMA
IDEN
Aplicaciones típicas de SMPP
La variedad de aplicaciones de mensajería, particularmente SMS para lo cual SMPP puede ser empleado
es casi ilimitada. Operadores inalámbricos, Vendedores de centro de mensajes, proveedores de
infraestructura, y diseñadores de aplicaciones están constantemente desarrollando nuevas aplicaciones
para SMS. SMPP es ideal como un protocolo de acceso para estas aplicaciones. SMPP es intencionado
para diseñadores e implementadores de SMPP como interfaz entre MC, RE y ESMES.
Página
Alertas de voicemail originadas desde un VPS (Voice Processing System) indicando mensajes
de voz al mailbox del cliente, son una de las primeras aplicaciones SMS basadas en ESME que
todavía son utilizadas en la industria.
Servicios de información. Por ejemplo, permitir a los suscriptores móviles consultar tasas de
cambio o información de precios de acciones de una base de datos o en la WWW, y que estos
reciban esa información desplegada en su móvil como un SM (short message).
Se utiliza para llamadas directamente marcadas o desviadas hacia un operador, quien a su vez
direcciona o remite los mensajes hacia una MC para entregarlas al terminal o celular del
suscriptor
Servicios de Directorios.
Servicios basados en Posicionamiento o localización. Incluyen rastreo de vehículos, envío de
taxis, controle logístico.
Aplicaciones de seguridad tales como sistemas de alarmas que pueden utilizar los servicios SMS
para accesos remotos y propósitos de alertas. Por ejemplo, un padre recibe un SMS de su
compañía de seguridad para informarles que su hija ha llegado a casa y que ingreso el código de
seguridad para acceso.
Banco en línea , E-Commerce.
SMS – Chat, juegos. Los usuarios de móviles pueden interactuar unos con otros utilizando un
Server ESME y utilizar esta interacción para jugar inalámbricamente.
Instant Messaging.
MMS Notification.
Cell Broadcasting Services (Servicios de Difusión) . Apoyo de mensajería geográfica como
alarmas de tráfico y servicios de emergencia.
5
Usos comunes de SMPP:
Sesiones SMPP
Para hacer uso del protocolo SMPP, una sesión SMPP debe establecerse entre el ESME y el MC o
SMPP RE cuando sea apropiado. La sesión establecida está basada en una capa de aplicación TCP/IP
o una conexión X.25 entre el ESME y MC/RE y por lo general, es iniciada por el ESME.
Hay 3 formas de inicio de Sesión ESME.
1-TX Transmitter
Cuando la autenticación es como un transmisor, un ESME puede enviar o entregar SM hacia el MC
(Message Center) para entregar más adelante éstos hacia los MS (Mobile Station). Una sesión de
transmisor también permitirá que un ESME, cancele, consulte o sustituya mensajes enviados con
anterioridad. Los mensajes enviados de esta manera son a menudo llamados Mobile Terminated
Message. (Mensajes terminados en el terminal) MT
2-RX Receiver
Una sesión de receptor permite a un ESME recibir SM de un MC, estos mensajes normalmente se
originan o provienen de los MS y se conocen como Mobile Originated Messages (Mensajes originados
en el terminal). MO
3-TRX Transceiver
Una sesión TRX es una combinación de TX y RX, de forma que una sesión SMPP pueda utilizar ambas
modalidades de MO y MT
Adicionalmente un MC puede establecer una sesión SMPP mediante la conexión a un ESME. Esto se
llama una Sesión Outbind.
Un ESME puede enviar y recibir SM´s
Operaciones de Protocolo y PDU´s (Protocol Data Unit)
El protocolo SMPP es un conjunto de operaciones, cada una de las cuales toma la forma de
Solicitud y Respuesta PDU. Por ejemplo, si un ESME desea enviar un SM, puede enviar un submit_sm
PDU al MC. El MC responderá con un submit_sm_resp PDU, indicando el éxito o falla de la petición.
Del mismo modo, si un MC desea entregar un SM a un ESME, este puede enviar un deliver_sm PDU al
ESME que a su vez, responderá con un deliver_sm_resp PDU como medio de reconocimiento de la
entrega.
Algunas operaciones son específicas a un ESME, como otras son específicas para un MC. Otras pueden
ser específicas a un tipo de sesión dado.
Refiriéndome a los ejemplos de arriba de un submit_sm y el deliver_sm, un ESME puede enviar un
submit_sm a un MC únicamente si ha establecido una sesión TX o una conexión/sesión TRX con ese
MC, igualmente, un MC puede enviar un deliver_sm PDU a un ESME solo si ya estableció una conexión
o sesión RX o TRX.
Resumiendo, SMPP está basado en el intercambio de PDU´s (Protocol Data Units)
Página
Los PDU´s contienen 3 Partes:
Área de encabezado o Header
Área de Parámetros Mandatorios
Área de Parámetros Opcionales.
6
Tipos de PDU:
1. PDU´s de solicitud o requerimiento y
2. PDU´s de respuesta
Las operaciones del protocolo y PDU´s se clasifican en términos generales en los siguientes grupos:
Administración de Sesión.
Estas operaciones son diseñadas para habilitar el establecimiento de sesiones SMPP entre un
ESME y un MC y proporcionar métodos de manejo de errores inesperados.
Mensaje de Presentación (Submission).
Estas operaciones son diseñadas específicamente para la presentación de mensajes desde las
ESMES hacia los MC.
Entrega de Mensajes.
Estas operaciones permiten a un MC entregar mensajes a un ESME.
Mensaje de Difusión (Broadcasting)
Estas operaciones son diseñadas para proveer servicios de difusión celular dentro de MC.
Operaciones Auxiliares
Estas operaciones están diseñadas para proporcionar características mejoradas, tales como la
cancelación, consulta o reemplazo de los mensajes
Estableciendo una Sesión SMPP
Para establecer una sesión, primero se requiere que una ESME se conecte a un MC. Esto se consigue
utilizando una red TCP/IP o X.25. El MC normalmente se mantiene escuchando las conexiones por uno
o más puertos de TCP/IP / X.25, sin embargo los puertos pueden variar dependiendo del vendedor y el
operador del MC. Típicamente el puerto estandarizado para SMPP, es el 2775.
Estados de una Sesión SMPP
Open
Bound_TX
Bound_RX
Bound_TRX
Unbound
Closed
Outbound
Open
Página
7
Un ESME a establecido una conexión de red con la MC, pero aun no ha emitido una petición o
Bind_request. El MC únicamente es consciente de la conexión TCP/IP o X.25. Ningún detalle de
identificación ha sido cambiado todavía
Bound_TX
Un ESME conectado ha solicitado unirse como un Transmitter/transmisor (utilizando un bind_transmitter
PDU) y ha recibido un bind_transmitter_resp PDU desde la MC autorizando su petición o solicitud. Un
ESME ligado como un transmitter puede enviar SM hacia un MC, para ser entregado a un MS o hacia
otro ESME. El ESME puede también reemplazar, solicitar o cancelar SM previamente entregados.
Bound_RX
Página
8
Un ESME conectado ha solicitado unirse como un Receiver/Receptor (utilizando un bind_receiver PDU) y
ha recibido un bind_receiver_resp PDU desde el MC autorizando su bind_request. Un ESME enlazado
como un receptor puede recibir SM desde un MC, el cual puede ser originado desde un MS (móvil
station) o por otro ESME o por el mismo MC.
Bound_TRX
Un ESME conectado ha solicitado enlazarse como un Transceiver (utilizando un bind_transceiver PDU) y
ha recibido un bind_transceiver_resp PDU desde la MC autorizando su bind_request. Un ESME enlazado
o unido como un transceiver esta autorizado a utilizar todas las operaciones soportadas por un ESME
Transmitter y un ESME Receiver. Una sesion transceiver es efectivamente la combinacion de una sesion
Transmitter y Receiver. Un ESME unido como un transceiver puede enviar SM a un MC para ser
entregados a un MS o hacia otro ESME y puede tambien recibir SM desde un MC, el cual puede
originado por un MS, o por otro ESME o por un MC.
Unbound
Un Unbound se da, cuando un ESME enlazado como un TX, RX o TRX solicita una peticion de desunion
a la MC (Message Center) para la terminacion de la sesion SMPP.
Closed
Página
9
Un estado Closed entre ESME-MC, se da cuando un ESME o MC han cerrado la conexión de Red. Esto
tipicamente es producido por un estado Unbound donde un punto de enlace ha solicitado terminar la
sesion. Un estado Closed puede tambien resultar debido a un error de comunicación entre pares o por
una falla de conexión inesperada en la red.
Outbound
El objetivo de la operación Outbind, es permitir que la MC inicie una sesion SMPP. Un ejemplo tipico
seria que la MC tuviera un SM pendiente de entregar a un ESME.
Página
10
El diagrama siguiente ilustra el concepto de Outbind cuando es utilizado para solicitar un enlace de un
ESME Receiver
Página
11
Ejemplo de Sesiones SMPP
12
Página
13
Página
14
Página
Página
15
Este ejemplo muestra una sesión de outbind que resulta en la unión de un ESME receptor
Sincrono y Asincrono
SMPP es un protocolo Asincrono. Esto significa que un ESME o un MC puede enviar varias solicitudes o
peticiones a la vez para la otra parte.
Veamos un ejemplo de una sesion asincrono :
Página
16
La conducta asíncrono de ambas ESME y MC es evidente en la sesión arriba presentada. Los números
de secuencia PDU hacen posible la adecuada respuesta para cada request / response.
¿Por qué Asíncrona?
El comportamiento asíncrono puede parecer un camino fácil cuando se desarrolla una aplicación a nivel
del protocolo SMPP. El envío de una petición PDU, y luego esperar por el PDU response es una
alternativa fácil sobre la gestión de varios PDU’s manejándolos en un entorno completo, en la forma
asíncrono, el orden de PDU y su secuencia numérica puede ser reconocido en un orden no continuo y
definitivo para la secuencia request/response.
Sin embargo para una aplicación eficiente en el uso de sesiones SMPP y la utilización de ancho de
banda, la transmisión asíncrono puede hacer mejoras significativas. El siguiente diagrama ayuda a
explicar la razón para utilizar el protocolo de forma asíncrona.
El ejemplo anterior muestra 5 PDU´s de forma asíncrona transmitidos a través de sesiones SMPP desde
el ESME hacia el MC. Si el MC puede procesar solo un PDU a la vez, entonces el beneficio de la
transmisión asíncrono no está realmente perdido. En esta situación, la transmisión de PDU´s se convierte
en una cola de solicitudes o peticiones para el MC. Tan pronto como el MC reconozca cada solicitud o
petición, inmediatamente encontrara otra solicitud o petición en estado de espera. Los mismos beneficios
aplican para las sesiones Receiver y Transceiver, donde el MC emite deliver_sm o data_sm PDU´s hacia
el ESME.
Página
Si consideramos el tiempo de transporte desde el ESME hacia el MC, tomara α microsegundos, entonces
el tiempo de inactividad por operación será 2α. Este es el tiempo de inactividad transcurrido mientras que
la respuesta está en tránsito hacia el ESME y cuando la petición o solicitud siguiente esta en tránsito
hacia el MC. Una ventana Asíncrona de peticiones o solicitudes efectivamente evita esta ineficiencia.
17
Si el ESME es síncrono y solo puede enviar un único PDU a la vez, entonces, tan pronto como el MC
reconozca el PDU, la sesión SMPP permanecerá inactiva hasta que el response_PDU del MC ha sido
procesado por el ESME y éste pueda enviar la próxima solicitud o petición al MC.
Manejo de Errores
Esta sección trata los escenarios típicos de errores que pueden ocurrir y como un ESME o un MC
debería de manejar tales situaciones o escenarios.
Manejo de Fallas de Conexión
Un ESME o un MC puede experimentar un intento de falla de conexión o una pérdida de conexión con
su otro par. Esto puede ser debido a cualquiera de las siguientes razones.
La dirección IP y el puerto o los detalles de X.25 son incorrectos (fallas de conexión).
El MC remoto o el ESME está caído/abajo y no puede aceptar la conexión.
La red entre los dos Hosts esta caída o abajo.
El enfoque recomendado es que continuamente se intente conectar o reconectar de nuevo a intervalos
definidos en el ESME.
Muchos sistemas ESME proporcionan servicios cruciales a una red SMS. Si una red o un MC se hacen
no disponibles, causando a los ESME´s perdida de conexión SMPP, entonces mientras el ESME entra en
modo por el cual intenta reconectarse a intervalos definidos, entonces cuando el MC restaura su servicio,
el ESME se reconectara y resumirá el servicio interrumpido con anterioridad.
La mayor parte de sesiones SMPP serán ESME-initiated, pero como hemos visto de Outbind, el MC
puede el mismo estar en posición de conectarse a un ESME configurado para Outbind.
La razón probable para intentar un Outbind es que los mensajes para el ESME han llegado en el MC.
Si el intento de conexión falla, se recomienda que el MC utilice mecanismos similares de intentos
periódicos de Outbind hacia el ESME. Esto puede conducir a una secuencia de reintentos que controlen
la frecuencia de intentos de entrega hechos para un mensaje dado.
Cada vez que el mensaje ESME es programado para reintentos, el MC intentará Outbind hacia el ESME
Para los tipos de fallas o controles de error, es necesario establecer un sistema de alarmas basado en
SNMP (Simple Network Management Protocol).
SNMP se basa en agentes, el agente envía alertas a otros agentes para avisar de eventos, dentro de las
características de un protocolo SNMP podemos citar:
Página
18
Monitorear estados de enlace punto a punto (ESME-MC – MC-ESME y otros nodos
relacionados).
Modificación remota de configuración de dispositivos
Fallas de Operación
Hay una serie de razones por las que un MC o un ESME podrán rechazar una solicitud de una
operación PDU.
El PDU no es reconocido.
Esto es uno de los motivos más comunes para rechazar un PDU. Esto puede ser el resultado de un
ESME o un MC enviando un PDU que el receptor par no reconoce. La respuesta típica en este escenario
es un generic_nack PDU devolviendo al remitente el número de secuencia infractor PDU. El estado de
comando generalmente es ESME_RINVCMDID, el cual indica que el MC o el ESME no pueden
reconocer el PDU. En esta situación, el error esa en el par receptor y se comporta como un escenario de
incumplimiento que por lo general se especifica en la documentación de PICS SMPP.
El PDU es incorrecto.
Cuando esto sucede, esto indica que la entidad que envía tiene fallas para el envío de PDU´s. Las
respuestas dependerán en como el PDU incorrecto es detectado. Si el command_id es la razón del
rechazo, el par que recibe debería de responder con un generic_nack y el command status colocarse con
ESME_RINVCMDID. Si el command_length del PDU parece ser demasiado grande, esto sugiere que el
PDU era inválido. El ESME o MC deberían de responder con un generic_nack y un command status
fijado con ESME_RINVCMDLEN.
Longitud de campo invalido.
Sin algún campo PDU es demasiado largo o demasiado corto, entonces el PDU es esencialmente
incorrecto, pero un ESME o un MC podrán reconocer el PDU y como tal responderán con un
submit_sm_resp o en su defecto, responder al PDU con un comando apropiado al error. Por ejemplo, si
un ESME envía un mensaje programado de entrega de 20 caracteres, el comando de rechazo debería de
ser command_status set to ESME_RINVSCHED.
El dato PDU es inesperado y se considera invalido (PDU data unexpected and deemed
invalid).
Este tipo de rechazo es una aplicación en lugar de una cuestión de cumplimiento de protocolo.
Un ejemplo de este tipo de escenario podría ser un Email Gateway que provee servicio de convertir
mensajes MO SMS en E-mail. El direccionamiento de email podría estar basado en el contenido del
texto del mensaje. Si el ESME encuentra que el mensaje transmitido por el MC no contiene el formato
correcto, éste rechazaría el mensaje. El código de error típico seria ESME_RX_R_APPN, el cual significa
el rechazo a un mensaje y que asegura que no existirá reintento de transmisión o envió.
PDU no permitida en el estado de sesión actual.
Esto es una violación de las reglas de sesión SMPP.
Un ejemplo seria que: un ESME en estado Bound_RX, intente enviar un mensaje, enviando un
submit_sm PDU
O el ESME intente enviar un mensaje a través una sesión Open sin primero hacer un Binding.
El comando de estado esperado en el submit_sm_resp PDU seria ESME_RINVBNDSTS.
Página
SMPP tiene un amplio alcance de funcionalidades y algunos MC o ESME´s pueden deliberadamente
proporcionar mecanismos para deshabilitar ciertas características. Por ejemplo, si un operador configura
un MC para rechazar intentos por las ESME´s para solicitar entrega de mensajes, forzarían al MC a
rechazar el mensaje con un estado de comando set to ESME_RINVREGDLVFLG. Aunque el campo
puede estar correctamente codificado, su uso esta desactivado y el MC esta autorizado para rechazar el
mensaje utilizando el código de error.
19
Las ESME´s o MC restringen el uso de características de ciertos PDU´s.
Parámetros SMPP y formato de PDU
Definiciones SMPP PDU
Esta sección define diferentes operaciones PDU´s que componen el protocolo SMPP.
Las operaciones se agrupan en 6 categorías:
1.
2.
3.
4.
5.
6.
Gestión de Sesión
Presentación de mensaje
Entrega de mensaje
Difusión de mensaje
Presentación auxiliar
Difusión auxiliar
Session Management
Message Submission
Message Delivery
Message Broadcast
Ancilliary Submission
Ancilliary Broadcast operation
1-Operación de Gestión de Sesión
Session Management
Estas operaciones son utilizadas para establecer y mantener sesiones SMPP.
PDU BIND
El propósito de la operación de enlace (bind) de SMPP, es el registro de una instancia ESME con
un sistema MC y establecer una sesión SMPP a través de una conexión de red para la entrega de
mensajes. Así, la operación Enlace BIN puede ser vista como una forma de petición login MC para
autenticar a la entidad ESME que desea establecer la conexión.
Como se describió anteriormente, un ESME puede enlazarse-unirse a un MC como un Transmitter
(llamado ESME Transmitter Transmisor), puede unirse a un MC como un Receiver (llamado ESME
Receiver Receptor) o puede unirse a un MC como un Transceiver (llamado ESME Transceiver
Transmisor-Receptor).
Hay 3 SMPP BIND PDU´s para soportar los distintos modos de operación, los cuales son:
a. Bind_transmitter
b. Bind_receiver
c. Bind_transceiver
El arreglo del campo command_id específica cual PDU se está utilizando.
Un ESME puede enlazarse como un SMPP transmitter y/o Receiver utilizando operaciones separadas de
bind_transmitter y bind_receiver (habiendo primero establecido 2 conexiones de red separadas).
Alternativamente un ESME puede también enlazarse o unirse como un Transceiver habiendo primero
establecido una única conexión de red.
Con los PDUs de BIND el ESME establece una sesión SMPP con el MC
Para cada operación BIND existe una operación BIND_RESP:
20
BIND_RECEIVER
BIND_TRANSCEIVER
BIND_TRANSMITTER_RESP
El bind_transmitter_resp SMPP PDU se utiliza para responder a
una solicitud bind_transmitter
BIND_RECEIVER_RESP
BIND_TRANSCEIVER_RESP
Página
BIND_TRANSMITTER
Parámetros mandatorios importantes de los PDUs BIND:
system_id:
password:
system_type:
identifica al ESME haciendo BIND
utilizado para autenticar el ESME
identifica el tipo de ESME que está haciendo el BIND
Una respuesta exitosa del MC indica que el ESME puede iniciar el intercambio de SM´s con el MC.
.
PDU UNBIND
UNBIND finaliza la sesión SMPP.
El objetivo de la operación Unbind SMPP (desenlazar) es para dar de baja a una instancia ESME desde
una MC e informar a la MC que el ESME ya no desea utilizar la conexión de red para el envío o entrega
de mensajes. Esta operación puede ser vista como una forma de la MC de solicitar el cierre de sesión
actual de SMPP, pero en la actualidad, Unbind puede ser enviado tanto por el ESME como por el MC y
cerrar la conexión TCP.
La operación Unbind, recibe siempre su respectivo unbind_resp. El unbind_resp SMPP es utilizado para
responder a una solicitud unbind y comprende el encabezado del mensaje SMPP.
PDU ENQUIRE LINK
Página
21
Este PDU enquire_link puede ser originado tanto por el ESME como por el MC y es utilizado para
proporcionar chequeo de confidencialidad de comunicación entre las entidades ESME y MC. Tras
la recepción de esta petición, la entidad receptora debe responder con un enquire_link_resp, por lo que
se verifica o valida que la conexión a nivel de aplicación entre el ESME y el MC está funcionando. El
ESME puede también responder con el envío de cualquier SMPP valido.
2-Presentacion de Mensajes
Message Submission
Las operaciones de presentación de mensajes o message submission proveen a un ESME la capacidad
de enviar SM a estaciones móviles.
PDU SUBMIT_SM
Con submit_sm, un ESME encola SM en el SMSC o MC, el PDU submit_sm_resp exitoso, indica que el
SM fue aceptado por el MC para ser entregado a su destino.
Parámetros mandatorios importantes del PDU SUBMIT_SM:
source_addr, source_addr_ton, source_addr_npi:
destination_addr, dest_addr_ton, dest_addr_npi:
short_message:
registered_delivery:
identifican el originador del SM
identifican el destinatario del SM
texto del SM
indica si se solicita notificación de entrega del SM
Parámetros mandatorios importantes del PDU SUBMIT_SM_RESP:
message_id: identifica el SM dentro del SMSC, puede ser utilizado posteriormente para consultar el
status del SM, cancelarlo o reemplazarlo
3-Operaciones de entrega de Mensajes
Message Delivery Operations
Las operaciones de entrega de mensajes proveen los medios de entrega de SM´s desde un MC hacia un
ESME. Estos mensajes suelen originarse desde los terminales o estaciones móviles.
PDU DELIVER_SM
Página
22
La operación deliver_sm, ésta operación es emitida por el MC para entregar un mensaje a un
ESME. Utilizando este comando, el MC puede rutear / dirigir un SM al ESME para la entrega.
Con el PDU deliver_sm_resp exitoso, se indica que el SM fue entregado correctamente al destinatario
Parámetros mandatorios importantes del PDU DELIVER_SM:
source_addr, source_addr_ton, source_addr_npi:
identifican el originadordel SM
destination_addr, dest_addr_ton, dest_addr_npi:
identifican el destinatario del SM
short_message:
texto del SM
esm_class:
Indica si el SM corresponde a una
notificación de entrega de un SM enviado anteriormente con SUBMIT_SM, en cuyo caso el parámetro
opcional receipted_message_idcontiene el message_iddel mensaje notificado
4-Difusión de mensaje
Message Broadcast
Las operaciones de mensaje de difusión proporcionan servicios de difusión a ESME´s.
Las operaciones de mensajes de difusión son aplicables únicamente a CBS (Cell Broadcast Centres) o
a SMSC´s con funcionalidades de integración con CBS´s.
La operación broadcast_sm, es emitida por el ESME para enviar SM al MC para la difusión del SM en
una área geográfica determinada o un a un conjunto de zonas geográficas, para esta operación existe su
broadcast_sm_resp.
5-Presentación auxiliar
Ancilliary Submission
Las operaciones ancilliary submission proporcionan gestión de mensajes presentados por las ESME´s.
Esto incluye, cancelación, consultas y reemplazo de mensajes.
PDU CANCEL_SM
Con la operación cancel_sm, el ESME cancela uno o más SM´s enviados con anterioridad con la
operación PDU submit_sm.
Parámetros mandatorios importantes del PDU CANCEL_SM:
Página
Identificador de un SM previamente enviado, puede ser nulo para
cancelar un grupo de mensajes
source_addr, source_addr_ton, source_addr_npi:
Debe hacer match con el origen de los mensajes a cancelar
destination_addr, dest_addr_ton, dest_addr_npi:
Debe hacer match con el destino de los mensajes a cancelar. Puede ser
nulo si la operación message_id es distinta de nulo
23
message_id:
PDU QUERY_SM
Operación query_sm
Este comando es emitido por el ESME para consultar el estado de un SM presentado o enviado
con anterioridad con el comando submit_sm
El mecanismo de match se basa sobre el MC y los campos asignados message_id y source_address.
Donde los parámetros submit_sm, data_sm o submit_multi (source address) fueron colocados o seteados
originalmente con el valor NULL, entonces la dirección de origen o source address en la consulta
query_sm también se debe setear o establecer con el valor NULL
Parámetros mandatorios importantes del PDU QUERY_SM:
message_id:
identificador de mensaje entregado por un SUBMIT_SM_RESP previo
source_addr, source_addr_ton, source_addr_npi:
Deben hacer match con los datos de origen del SUBMIT_SM previo
Parámetros mandatorios importantes del PDU QUERY_SM_RESP:
message_id:
identificador del SM
final_date:
fecha y hora en que el SM alcanzó un estado final
message_state:
status del SM consultado
error_code:
utilizado en caso de falla de entrega del SM
PDU REPLACE_SM
Este comando es emitido por el ESME para sustituir un SM enviado anteriormente y que se encuentra
pendiente de ser entregado a su destino final.
message_id:
identificador del SM a ser reemplazado
source_addr, source_addr_ton, source_addr_npi:
Debe hacer match con el originador del SM a reemplazar
short_message:
nuevo texto del SM.
Página
Parámetros mandatorios importantes del PDU REPLACE_SM:
24
El mecanismo de match está basado en campo message_id y la dirección origen del mensaje original.
Página
25
Refiérase a http://smsforum.net para ampliar información sobre SMPP