Native SMPP Communication Service

The native SMPP communication service implements the SMPP v. 3.4 standard. For more information, see “Appendix A: Standards and Specifications” in the Concepts and Architectural Overview, another document in this set.

Requests can flow in two directions using the native SMPP communication service: from the application to the network (called application-initiated or mobile terminated) and from the network to the application (called network-triggered or mobile originated).

Applications act as SMPP ESME clients and Oracle Communications Services Gatekeeper acts as an SMPP server.

Session Handling and Provisioning

Applications can bind to Oracle Communications Services Gatekeeper as a transmitter, a receiver, or a transceiver. Oracle Communications Services Gatekeeper does not initialize binds (SMPP operation outbind).

An application can establish several parallel sessions by issuing multiple bind operations.

Applications use an application instance ID as the ESME system_id and the related password as provisioned in Oracle Communications Services Gatekeeper when binding to Oracle Communications Services Gatekeeper.

As a result of a bind operation from an application, the Native SMMP network protocol plug-in binds to the underlying SMPP server. When the application unbinds, the plug-in unbinds from the SMPP server. The plug-in can bind as a transceiver, transmitter, or receiver.

A plug-in instance can connect to exactly one SMPP server, so at least one plug-in instance must be created per SMPP server to use. The plug-in instance binds to the SMPP server using a configurable ESME system ID.

The Native SMPP Service Facade must be provisioned with additional data about the application instance. This data includes:

Application-triggered Short Messages

The communication service forwards the SMPP PDU sent from the application transparently to the SMPP server, if not modified by the Service Interceptors, with the exception of the BIND PDU. The BIND PDU is configured in the plug-in.

There is no enforcement on maximum number of unacknowledged SMPP operations, a maximum window size cannot be specified.

Network-triggered Short Messages

The communication service forwards the SMPP PDU sent from the SMPP server to Oracle Communications Services Gatekeeper transparently to the application, if not modified by the Service Interceptors, with the exception of the BIND PDU.

If the application does not acknowledge the reception of a network-triggered message, an error response is sent back to the SMPP SMSC. Both the error message and the time to wait for a response are configurable in the Native SMPP Facade.

Supported Network Protocols

SMPP v3.4

Oracle Communications Services Gatekeeper connects to an SMSC using SMPP v3.4. See “Appendix A: Standards and Specifications” in Concepts and Architectural Overview for the exact version of the standard Oracle Communications Services Gatekeeper supports.

Short Code Translation

Limitations and Recommendations

Below is a set of limitations to and recommendations for the Native SMPP Communication Service:

Load Balancing, High Availability and Fail-Over

To optimize system utilization, applications should load balance application-triggered requests between all Network Tier servers.

The SMPP server should load-balance network-triggered requests between all Network Tier servers.

Load balancing is only supported between plug-in instances which are located in same Network Tier server and share the same large account. When a request has reached a plug-in instance in a Network Tier server, it uses the Service Facade in the same server to pass the request on to the applications. When a request has reached the Service Facade in a Network Tier server, it uses a plug-in instance in the same Network Tier server to process the request.

High availability and fail-over is supported out-of-the-box between Oracle Communications Services Gatekeeper and the SMPP server. High availability between the application and Oracle Communications Services Gatekeeper must be handled by each application.

A prerequisite for high-availability for the Native SMMP communication service is redundant Network Tier servers, redundant network interface cards in each Network Tier server, and a redundant set of SMPP servers to connect to. By using at least two different plug-in instances per Network Tier server, and having the plug-in instances connect to different SMPP servers high-availability is achieved from Network Gatekeeper to the network.

Between SMPP applications and Network Gatekeeper, the applications need to handle high availability and fail-over for application-initiated requests by binding to two or more Network Tier servers. For network-triggered requests, the same requirement that the applications bind to two or more network tier servers applies.

The Native SMPP communication service can be provisioned so applications share the same large account in the SMPP server, so that they share the same bind. However, when there is only one bind between Oracle Communications Services Gatekeeper and the SMPP server, and more than one application listens to network-triggered messages, the Native SMPP communication service must listen to incoming messages on behalf of all the applications. The bind between the plug-in and the network node is done on all Network Tier servers, so network-triggered messages can be sent to any of these servers. If the network-triggered request ends up in a Network Tier server that the application has not bound to, the message is put into a JMS queue for the server that has the active bind. The latency in this case can have a negative impact on performance. For better performance all applications should bind to all Network Tier servers.

Configuration Specifics for the Native SMPP Communication Service

Communication services share many common features, covered in the “Introducing Communication Services” chapter of Concepts and Architectural Overview, but each one has a few characteristics that are specific only to that service. This section describes those specific features for the native SMPP communication service, including:

Charging Data Records

Generation of CDRs

Event Data Records

Table 16-1 Event types emitted in Native SMPP Communication Service
EdrId	Meaning
400000	An application-initiated bind operation has entered the plug-in.
400001	An application-initiated unbind operation has entered the plug-in.
400002	An application-initiated submit operation has entered the plug-in.
400003	A network-triggered submitResponse operation has been forwarded to the Service Facade.
400004	An application-initiated submitSmMulti operation has entered the plug-in.
400005	A network-triggered submitMultiResponse operation has been forwarded to the Service Facade.
400006	An application-initiated querySm operation has entered the plug-in.
400007	A network-triggered submitMultiResponse operation has been forwarded to the Service Facade.
400008	An application-initiated cancelSm operation has entered the plug-in.
400009	A network-triggered cancelResponse operation has been forwarded to the Service Facade.
400010	An application-initiated replaceSm operation has entered the plug-in.
400011	A network-triggered replaceResponse operation has been forwarded to the Service Facade.
400020	The plug-in initiates an attempt to bind to the SMPP server.
400021	The plug-in unbinds from the SMPP server
400022	An application-initiated submit operation has been forwarded to the SMPP server.
400023	A network-triggered receiveSubmitSmResponse operation has been received from the SMPP server.
400024	An application-initiated sendSubmitSmMulti operation has been forwarded to the SMPP server.
400025	A network-triggered receiveSubmitSmMultiResponse operation has been received from the SMPP server.
400026	An application-initiated sendQuerySm operation has been forwarded to the SMPP server.
400027	A network-triggered receiveQuerySmResponse operation has been received from the SMPP server.
400028	An application-initiated sendCancelSm operation has been forwarded to the SMPP server.
400029	A network-triggered receiveCancelSmResponse operation has been received from the SMPP server.
400030	An application-initiated sendReplaceSm operation has been forwarded to the SMPP server.
400031	A network-triggered receiveReplaceSmResponse operation has been received from the SMPP server.
400100	A network-triggered deliverSm operation has been forwarded to the SMPP server.
400101	An application-initiated deliverSmResponse operation has reached the plug-in.
400102	A network-triggered message that had been stored in the JMS queue has expired and been removed.
400103	A deliverSmResponse operation from the connector has reached the plug-in. The message has been transferred via JMS to a server with an active bind session to the application.
400110	A network-triggered short message has reached the plug-in.
400111	A network-triggered delivery receipt has reached the plug-in.
400112	A response (deliver_sm_resp) to a network-triggered short message or delivery receipt is sent to the SMPP server.

Statistics

The table below outlines the correlation between the methods being invoked from either the application (in application-initiated requests) or the telecom network (in network-initiated requests) and the transaction type collected by the statistics counters in Gatekeeper for the native SMPP communication service:

Method	Transaction type
submitSm	TRANSACTION_TYPE_MESSAGING_SEND
submitSmMulti	TRANSACTION_TYPE_MESSAGING_SEND
receiveMoReq	TRANSACTION_TYPE_MESSAGING_RECEIV

Communication Service Reference