16 Extended Web Services Binary SMS/SMPP

This chapter describes the Extended Web Services (EWS) Binary SMS/Short Message Peer to Peer (SMPP) Communication Service in detail.

Overview of the EWS Binary SMS/SMPP

The EWS Binary SMS/SMPP communication service allows applications to send and receive generic binary object attachment, such as vCards. It exposes the Oracle Extended Web Services Binary SMS interface.

The communication service acts as an External Short Message Entity (ESME) that connects to a Short Messaging Service Center (SMSC) over TCP/IP.

For the exact version of the standards that the communication service supports for the application-facing interfaces and the network protocols, see the appendix on standards and specifications in Concepts Guide.

Using the EWS Binary SMS/SMPP communication service an application can:

Send short messages with binary attachments to one or more destination addresses.
Subscribe and unsubscribe for network-triggered binary short messages with binary attachments.
Receive network-triggered short messages with binary attachments.

The actual message element is made up of an array of UDH and message parts, encoded in Base64. See "3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the short message service (SMS); (Release 6) 3GPP 23.040 Version 6.5.0" at:

http://www.3gpp.org/ftp/Specs/html-info/23040.htm

The send message operation gives an application the flexibility to manipulate the SMPP UDH and message data. Both the UDH and message data elements are optional, but the overall element, binaryMessage, is required. The contents of the UDH and the message can be of any binary data, although any byte array should be less than 140 bytes due to SMPP limitations, and the number of BinaryMessage arrays should be less than the SegmentsLimit specified in OAM. The default value is 1024. see Attribute: SegmentsLimit.

The notification operation gives the application access to an array of SMPP UDHs, the SMPP DCS, the protocol identifier according to 3GPP 23.040 Version 6.5.0, and other data such as sender address, destination address and timestamp of the message.

SMPP expects the sender name value to be in ASCII characters. The use of non-ASCII characters may cause the request to become garbled or even be removed at the SMSCS

Services Gatekeeper provides support for the billing identification identifier, smpp_billing_id, defined in SMPP Specification 5.0, through the use of a tunneled parameter. It also supports the ussd_service_operation, which was added as an optional parameter to the deliverSM operation as a tunneled parameter in SMPP v 5.0. See the descriptions of the smpp_billing_id and ussd_service_operation tunneled parameters in Chapter 6, "Parlay X 2.1 Short Messaging/SMPP" for more information.

Send Receipts

Send receipts are acknowledgements that the network node has received the short message from the application by Services Gatekeeper. Although a single short message may be sent to multiple destination addresses, normally only one send receipt is returned to the application by Services Gatekeeper. The receipt is returned synchronously in the response message to the sendBinarySms operation.

Delivery Receipts

Delivery receipt notifications can be set up using the sendBinarySms operation, but the actual asynchronous delivery of receipts is accomplished using the Parlay X 2.1 Short Messaging interface. See "Delivery Receipts" in Chapter 6, "Parlay X 2.1 Short Messaging/SMPP" for information on delivery receipts.

Connection Handling and Provisioning

The EWS Binary SMS/SMPP communication service uses the Services Gatekeeper SMPP Server Service to establish and manage southbound connections between Services Gatekeeper and Short Message Service Centers (SMSCs). The SMPP Server Service is deployed as an Oracle WebLogic Server Service.

The SMPP Server Service provides these services for the Parlay X 2.1 Short Messaging and Native SMPP plug-ins as well as for EWS Binary SMS/SMPP.

For information about configuration options pertaining to these client connections, see the System Properties for SMPP Server Service and Reference: Attributes and Operations for SMPP Server Service sections.

The client connection ID is created on the plug-in's successful bind with the SMSC. The connection ID changes on a successful rebind.

For information about connection handling and provisioning, multiple connections and multiple plug-in instances, windowing, and load balancing/high availability, see the applicable sections in Chapter 6, "Parlay X 2.1 Short Messaging/SMPP."

Application Interfaces

For information about the application interface for the EWS Binary SMS/SMPP communication service, see the discussion of Extended Web Services Binary SMS in Application Developer's Guide.

For information about the RESTful Call Notification interface, see the discussion of Binary Short Messaging in RESTful Application Developer's Guide.

The RESTful Service Call Notification interfaces provide RESTful access to the same functionality as the application interfaces. The internal representations are identical, and for the purposes of creating SLAs and reading CDRs, and so on, they are the same.

Events and Statistics

For general information, see Appendix A, "Events, Alarms, and Charging."

The Extended Web Services Binary SMS/SMPP communication service generates Event Data Records (EDRs), Charging Data Records (CDRs), alarms, and statistics to assist system administrators and developers in monitoring the service.

Event Data

Table 16-1 lists the IDs of the EDRs created by the EWS Binary SMS/SMPP communication service. This list does not include EDRs created when exceptions are thrown.

Table 16-1 Event Types Generated by EWS Binary SMS /SMPP

EDRID	Method Called
7101	sendBinarySms
7201	startBinarySmsNotification
7202	stopBinarySmsNotification
7204	notifyBinarySmsDeliveryReceipt
7205	notifyBinarySmsReception

For the list of EDRs generated by the SMPP Server Service, see Table 20-2, "Event Types Generated by the SMPP Server Service".

Charging Data Records

EWS Binary SMS/SMPP-specific CDRs are generated under the following conditions:

After a mobile-terminated sendBinarySms request is sent from Services Gatekeeper to the network.
After a a network-triggered binary SMS message has been successfully delivered to the application.

Statistics

Table 16-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.

Table 16-2 Methods and Transaction Types for EWS Binary SMS/SMPP

Method	Transaction type
sendBinarySMS	TRANSACTION_TYPE_MESSAGING_SEND
receivedMobileOriginatedBinarySMS	TRANSACTION_TYPE_MESSAGING_RECEIVE

Alarms

For the list of alarms, see Alarm Handling Guide.

Managing EWS Binary SMS/SMPP

The properties, workflow, tunneled parameters and management operations for the EWS Binary SMS/SMPP communication service are identical to those provided for the Parlay X 2.1 Short Messaging/SMPP communication service.

For details, see: