This chapter describes the Oracle Communications Services Gatekeeper Extended Web Services (EWS) Binary SMS/Short Message Peer to Peer (SMPP) Communication Service in detail.
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 EWS Binary SMS/SMPP communication service supports for the application-facing interfaces and the network protocols, see Services Gatekeeper Statement of Compliance.
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. The UDH and message data elements are each optional, but both cannot be null at the same time; otherwise no data would be sent at all. The overall binaryMessage element 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 the segmentsLimit attribute to SmsMBean for details.
This communication service supports automatic chunking of oversized binary SMS messages to handle messages that exceed the maximum size limits that switches enforce for a single SMS request. Oversized unsegmented messages are automatically divided into size-conforming individual messages. This feature is supported for SMSs using user data header (UDH) and Sar headers, and you must select the header your implementation uses. The default is UDH. See Configuring Automatic Chunking of Binary SMSs for in Services Gatekeeper Application Developer's Guide for details.
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.1, 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.1. See the descriptions of the smpp_billing_id and ussd_service_operation tunneled parameters in "Parlay X 2.1 Short Messaging/SMPP" for more information.
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 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 "Parlay X 2.1 Short Messaging/SMPP" for information on delivery receipts.
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 "Parlay X 2.1 Short Messaging/SMPP".
For information on the application interface for the EWS Binary SMS/SMPP communication service, see the discussion about extended web services binary SMS in Services Gatekeeper Application Developer's Guide.
For information about the RESTful Call Notification interface, see the discussion on binary short messaging in Services Gatekeeper 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.
For general information, see "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.
Table 17-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 17-1 EDRs Generated by EWS Binary SMS /SMPP
| EDRID | Method Called |
|---|---|
|
7101 |
sendBinarySms |
|
7201 |
startBinarySmsNotification |
|
7202 |
stopBinarySmsNotification |
|
7204 |
notifyBinarySmsDeliveryReceipt |
|
7205 |
notifyBinarySmsReception |
See "Events and Statistics" for the list of EDRs generated by the SMPP Server Service.
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.
Table 17-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.
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:
Managing Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP
Properties for Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP
Set the fields and methods for the SmsMBean from the Administration Console or a Java application. For information on the methods and fields, see the ”All Classes” section of Services Gatekeeper OAM Java API Reference