# Communication Service Reference

# Native SMPP Communication Service

This chapter describes the native SMPP communication service in detail:

## An Overview of the 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.

Using the native SMPP communication service, an application can:

- Send a short message to one or many destination addresses.
- Cancel a previously sent message that has not yet been delivered.
- Replace a previously sent message that has not yet been delivered.
- Query the delivery status of a previously sent message.
- Receive short messages arrived from the network.
- Receive the delivery status of a previously sent message.

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:

- The port number to bind to
- The maximum number of concurrent sessions allowed
- Whether subsequent operations should be allowed to target a previously sent short message
- Whether network-triggered short messages and delivery reports should be forwarded to the application or not.
- The address range that when matched with the destination address of a network-triggered short message forwards the message to the application.

### 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

The native SMPP communication service supports the following network protocol:

- SMPP v3.4

#### 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

The Native SMPP communication service does not offer short code translations.

### Limitations and Recommendations

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

- Windowing, as implemented by the Parlay 2.1 Short Messaging/SMPP plug-in, is not supported.
- The following operations are not supported:

- data_sm
- alert_notification
- outbind

- Hitless upgrade is not supported. The old version of the communication service must be undeployed before a new version can be deployed.
- Different applications should not share the same bind towards the SMPP server. See Load Balancing, High Availability and Fail-Over.

### 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
- Event Data Records
- Statistics
- Supported Address Schemes

### Charging Data Records

#### Generation of CDRs

The Native SMPP communication service writes CDRs in the following conditions:

- After a short message has been successfully sent from the application to the network
- After a short message has been successfully sent from the network to the application
- After a delivery report has been successfully delivered to the application

### Event Data Records

The Native SMPP communication service uses the standard EDR mechanism, documented in Table 16-1. For more information, see Events, Alarms, and Charging.

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:

Note: | Method names for network-initiated requests are specified by the internal Gatekeeper name, which is not necessarily the same as the message from the network.

Table 16-2 Transaction types for Native SMPP communication service
Method | Transaction type
--- | ---
submitSm | TRANSACTION_TYPE_MESSAGING_SEND
submitSmMulti | TRANSACTION_TYPE_MESSAGING_SEND
receiveMoReq | TRANSACTION_TYPE_MESSAGING_RECEIV

### Supported Address Schemes

The native SMPP communication service supports the`tel:` address scheme.