Pá

gin

a1

PROTOCOLO

SMPP

ESME MC/ SMSC

X.25

Pá

gin

a2

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

Closed .......................................................................................................................................... 9

Outbound ................................................................................................................................... 10

Ejemplo de Sesiones SMPP ................................................................................................................ 11

Sincrono y Asincrono ......................................................................................................................... 16

Pá

gin

a3

¿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

PDU REPLACE_SM ...................................................................................................................... 24

Pá

gin

a4

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. El siguiente diagrama muestra el contexto de SMPP en una red Mobile.

Pá

gin

a5

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. Usos comunes de SMPP:

� 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.

Pá

gin

a6

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) Tipos de PDU:

1. PDU´s de solicitud o requerimiento y 2. PDU´s de respuesta

Los PDU´s contienen 3 Partes:

Área de encabezado o Header Área de Parámetros Mandatorios Área de Parámetros Opcionales.

Pá

gin

a7

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

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

Pá

gin

a8

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

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.

Pá

gin

a9

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

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.

Pá

gin

a1

0

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. El diagrama siguiente ilustra el concepto de Outbind cuando es utilizado para solicitar un enlace de un ESME Receiver

Pá

gin

a1

1

Ejemplo de Sesiones SMPP

Pá

gin

a1

2

Pá

gin

a1

3

Pá

gin

a1

4

Pá

gin

a1

5

Este ejemplo muestra una sesión de outbind que resulta en la unión de un ESME receptor

Pá

gin

a1

6

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 : 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.

Pá

gin

a1

7

¿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. 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. 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.

Pá

gin

a1

8

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:

Monitorear estados de enlace punto a punto (ESME-MC – MC-ESME y otros nodos relacionados).

Modificación remota de configuración de dispositivos

Pá

gin

a1

9

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.

Las ESME´s o MC restringen el uso de características de ciertos PDU´s.

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.

Pá

gin

a2

0

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. Gestión de Sesión Session Management 2. Presentación de mensaje Message Submission 3. Entrega de mensaje Message Delivery 4. Difusión de mensaje Message Broadcast 5. Presentación auxiliar Ancilliary Submission 6. Difusión auxiliar 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: BIND_TRANSMITTER BIND_TRANSMITTER_RESP El bind_transmitter_resp SMPP PDU se utiliza para responder a una solicitud bind_transmitter BIND_RECEIVER BIND_RECEIVER_RESP BIND_TRANSCEIVER BIND_TRANSCEIVER_RESP

Pá

gin

a2

1

Parámetros mandatorios importantes de los PDUs BIND: system_id: identifica al ESME haciendo BIND password: utilizado para autenticar el ESME system_type: 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

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.

Pá

gin

a2

2

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: identifican el originador del SM destination_addr, dest_addr_ton, dest_addr_npi: identifican el destinatario del SM short_message: texto del SM registered_delivery: 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

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

Pá

gin

a2

3

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: message_id: 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

Pá

gin

a2

4

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. El mecanismo de match está basado en campo message_id y la dirección origen del mensaje original. Parámetros mandatorios importantes del PDU REPLACE_SM: 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á

gin

a2

5

Refiérase a http://smsforum.net para ampliar información sobre SMPP