This chapter describes the Oracle Communications Services Gatekeeper Parlay X 2.1 Short Messaging/Short Message Peer to Peer (SMPP) communication service in detail.
The Parlay X 2.1 Short Messaging/SMPP communication service exposes the Parlay X 2.1 Short Messaging set of application interfaces.
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 Parlay X 2.1 Short Messaging/SMPP communication service supports for the application-facing interfaces and the network protocols, see Services Gatekeeper Statement of Compliance.
Services Gatekeeper provides support for the billing identification identifier, smpp_billing_id, defined in the SMPP Specification, through the use of a tunneled parameter. It also supports the ussd_service_operation, which was added as an optional parameter to the DELIVER_SM operation as a tunneled parameter in the SMPP Specification. See "smpp_billing_id" and "ussd_service_operation" for information about these parameters.
Using a Short Messaging communication service, an application can:
Send short messages to one or many destination addresses. The payload in these short messages can be text, logos, or ringtones. With Split and Submit messaging, short messages addressed to many recipients can be split into multiple individually-addressed messages.
Logos must be in either Smart Messaging or Enhanced Messaging Service (EMS) format. The image is not scaled. Ringtones must be in either Smart Messaging or EMS (iMelody) format.
Request to be notified that delivery receipts for sent short messages have been received from the network.
Receive delivery receipts on sent short messages that have arrived from the network.
Explicitly query Services Gatekeeper for delivery receipts on sent short messages.
Subscribe to be notified if specified short messages for the application have been received from the network.
Receive notifications that specified short messages for the application have arrived from the network. These notifications include the short message payload.
Explicitly poll Services Gatekeeper for short messages sent to the application that have arrived from the network and been stored in Services Gatekeeper.
Requests can flow in two directions: 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). Both of these scenarios are covered in the following sections.
Bulk SMS messages addressed to multiple recipients can be split into a number of individually addressed SMS messages with Split and Submit Messaging regardless of the capabilities of the SMSC.
Split and Submit Messaging:
Works with SMSCs that do not support the SUBMIT_MULTI PDU
Supports sending to more than 254 addresses (the limit of SUBMIT_MULTI)
Frees applications from splitting messages, improving their performance.
Delivery receipts are returned on a per-message basis, one for each individual recipient.
After an application has sent a short message to one or more destination addresses, two different types of responses can be returned:
Send receipts are acknowledgements that the network node has received the short message from the application by means of Services Gatekeeper. Although a single short message may be sent to multiple destination addresses, Services Gatekeeper normally returns only one send receipt to the application. The receipt is returned synchronously in the response message to the sendSms operation.
Delivery receipts contain the delivery status of the short message; that is, whether the short message has actually been delivered by the network to the mobile terminal. There is one delivery receipt per destination address, with one of three possible outcomes:
Successful: In the case of concatenated short messages, this is returned only when all the parts have been successfully delivered.
Unsuccessful: The short message could not be delivered before it expired.
Unsupported: Delivery notification for this address is not supported. This can occur if the originating network supports delivery receipts but is unable to acquire the appropriate information for one or more destination addresses. This status is reported for each address for which this is the case.
Because actual delivery of the short message may take several hours, or even days (if, for example, the mobile terminal is turned off at the time the short message is sent), delivery receipts are returned asynchronously. Applications can choose either to have delivery receipts delivered to them automatically by supplying Services Gatekeeper with a callback interface or they can poll Services Gatekeeper.
If the application supplies a callback interface, there are two possible outcomes:
Services Gatekeeper sends the delivery receipt and the application receives and acknowledges it.
Services Gatekeeper sends the delivery receipt but the application does not acknowledge reception. In this case, Services Gatekeeper stores the delivery receipt. The application can poll Services Gatekeeper for these receipts. Each stored delivery receipt is time stamped and, after a configurable time period, is removed.
If the application chooses not to supply a callback interface, Services Gatekeeper stores the delivery receipt. The application can poll Services Gatekeeper for these receipts. Each stored delivery receipt is time stamped and, after a configurable time period, is removed.
To correlate a sent message with a delivery receipt from the network node, Services Gatekeeper stores the information about the message for a period of time. This information has a life span. If the delivery receipt does not arrive prior to the expiration of the message, a cancel request for the message is sent to the SMSC.
Two types of traffic destined for an application can arrive at Services Gatekeeper from the network. They are:
Delivery receipts for application-initiated sent short messages
Mobile-originated short messages destined for the application
For an application to receive online notification of short messages from the network, it must indicate its interest in these messages by registering for online notification in Services Gatekeeper. A notification is defined by a service activation number, which is the destination address to which the mobile sender directs the short message. This is usually a short code. Use the startSmsNotification method to SmsMBean to register for online notification of network-triggered SMS messages from the Administration console. An application can also use the following operations to register for online notifications:
ParlayX 2.1 StartSmsNotification; see Parlay X 2.1 Web Services Part 4: Short Messaging specification
REST Start Sms Notification; see Services Gatekeeper Application Developer's Guide.
OneAPI Subscribe to SMS Delivery Notification; see Services Gatekeeper Application Developer's Guide.
An application can also be registered to receive short messages offline. Services Gatekeeper stores the messages and delivers them when the application requests them. Use the enableRecieveSms method to SmsMBean to provision offline notification of network-triggered SMS messages.
Additional criteria can be tied to the service activation number, such as the first word of the text in the short message payload. For Services Gatekeeper to accept a message, both the service activation number and the additional criteria must match the details in the notification. Each registered notification must be unique, and notification attempts with overlapping criteria are rejected. The application can either request received short messages from Services Gatekeeper or include a callback interface when setting up the original notification.
Following are the possible scenarios for receipt and handling of short messages.
The application has registered for online notification. Services Gatekeeper sends the short message to the application, and the application receives and acknowledges it.
In this case Services Gatekeeper acknowledges receiving the short message to the network
The application has registered for online notification. Services Gatekeeper sends the short message to the application, but the application does not acknowledge receiving it.
Offline notification has been provisioned and a registration identifier has been established, so Services Gatekeeper stores the short message and acknowledges receiving the short message to the network.
The application has registered for online notification. Services Gatekeeper sends the short message to the application, but the application does not acknowledge receiving it.
Offline notification has not been provisioned. Services Gatekeeper returns an error to the network. It is the responsibility of the network to handle any further processing of the short message
The application has not registered for online notification.
Offline notification has been provisioned. Services Gatekeeper stores the short message and acknowledges receiving the short message to the network.
The application has not registered for online notification.
Offline notification has not been provisioned. Services Gatekeeper acknowledges receiving the short message to the network with an error. It is the responsibility of the network to handle any further processing of the short message.
Each stored short message is time stamped and, after a configurable time period, removed from storage.
A SOAP application retrieves stored messages with the getReceivedSms operation; see the Parlay X 2.1 Web Services Part 4: Short Messaging specification for more information about this operation. A REST application retrieves them with the Get Received Sms operation; see the Services Gatekeeper Application Developer's Guide for information about this operation.
The Parlay X 2.1 Short Messaging/SMPP communication service uses the Services Gatekeeper SMPP Server Service to establish and manage southbound (client) connections between Services Gatekeeper and SMSCs. The SMPP Server Service is deployed as an Oracle WebLogic Server service.
See "System Properties for SMPP Server Service" and "Reference: Attributes and Operations for SMPP Server Service" for information about configuring connections between the Services Gatekeeper SMPP server service and an SMSC.
A client connection is created when this plug-in successfully binds with an SMSC. A successful rebind changes the connection ID.
When a client connection is successfully established, the connection is verified periodically by using ENQUIRE_LINK requests (heartbeats). If the ENQUIRE_LINK requests fail a configurable number of times, Services Gatekeeper attempts to reconnect with the SMSC. If the reconnect attempts fail a configurable number of times, the client connection is closed and removed.
The plug-in instance MBean provides the following configurable timers for southbound connections between Services Gatekeeper and SMSCs:
Connection timer: This timer sets the heartbeat interval that Services Gatekeeper uses to request the connection status on the client connection. If the ENQUIRE_LINK requests fail, Services Gatekeeper closes the connection and attempts to reconnect. See the EnquireLinkTimerValue field to SmsMBean for more information.
Transaction timer: This timer establishes the interval between an SMPP request to the SMSC and the corresponding SMPP response. If the interval is reached, Services Gatekeeper does not resend the request. In this case, Services Gatekeeper removes the transaction information and discards the PDU response. See the RequestTimerValue field to SmsMBean for more information.
A Parlay X 2.1 Short Messaging/SMPP plug-in can bind to an SMSC as an ESME transmitter/receiver or transceiver. If more than one account in the SMSC is used, create one plug-in instance for each account. If more than one SMSC is used, create a plug-in instance for each account in each of the SMSCs.
If plug-in instances have the same bind type, they can share a connection to the SMSC. If they have different bind types, each must have its own client connection.
Each plug-in instance executes on all network tier servers. Shared storage is used, so network-triggered messages and delivery notifications can be accepted by all network tier servers and match them with all application subscriptions, thus creating a configuration with high availability.
To maximize throughput, the Parlay X 2.1 Short Messaging/SMPP communication service supports windowing on the network-facing interfaces. Windowing provides a way to specify the amount of data that can be transmitted without receiving an acknowledgment.
Windowing for requests to the SMSC is configured in the plug-in.
The windowSize attribute sets the number of unacknowledged requests that can be sent simultaneously.
A request moves from the windowing queue to the window. From the window it is submitted for processing. A submitted request remains in the window until its response is received. When the response is received, the request is released and another request can be moved from the windowing queue to the window.
If any one of these windowing parameters is set to a value less than zero, windowing is turned off. If all of these three parameters are greater than zero, windowing is turned on.
For descriptions of these attributes to SmsMbean see the ”All Classes” section of Services Gatekeeper OAM Java API Reference:
windowSize
windowWaitTimeout
If the windowing request queue is full or the timer has expired, the request is not sent and an error code is returned to the plug-in instance.
If an SMS message is larger than the maximum payload size, the message content is concatenated into segments before it is delivered to the application.
The maximum payload size defaults to the standard set by the Parlay X 2.1 Short Messaging specification. You can set the maximum payload size using the wlng.smpp.max_payload_size system property on the command line when starting Services Gatekeeper.
For configuration attributes regarding segments, to SmsMbean see the "All Classes"” section of Services Gatekeeper OAM Java API Reference:
ReceiveSegmentsWaitTime
ReceiveSmsIgnoreMissingSegments
Messaging-capable networks use short codes and message prefixes to help route traffic and to make access to certain features easier for the end user. Instead of having to use the entire address, users can enter a short code that is mapped to the full address in the network. The Parlay X 2.1 Short Messaging/ SMPP communication service supports short codes and message prefixes, which allow the same short code to be mapped to different applications based on the prefix to the enclosed message.
To optimize system utilization, applications should load-balance application-triggered requests among all application tier servers.
When there are multiple connections to the SMSC within a single plug-in instance, the SMPP Server Service selects one of the connections to the SMSC.
A prerequisite for high-availability for the Parlay X 2.1 Short Messaging/SMPP 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. High availability between Services Gatekeeper and the network is achieved 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 behavior is as follows:
The SMPP server runs in every network node. If one network node is unavailable, mobile-terminated requests are automatically routed to a healthy node. Related delivery reports are routed from the healthy network node that handled the request to the application.
If the application tier is unavailable, mobile-originated messages are routed to a healthy application tier node.
In a Services Gatekeeper cluster, if the server becomes unavailable after sending a SUBMIT_SM request to and receiving the SUBMIT_SM_RESP from the SMSC, the SMSC routes the subsequent delivery receipt to another server. This other server retrieves the message information from cluster-level storage and processes it.
In a Services Gatekeeper cluster, if a server becomes unavailable after sending a SUBMIT_SM request to and receiving the SUBMIT_SM_RESP from an application, the application routes the subsequent cancel, query, or replace request to another server. This other server retrieves the message information from cluster-level storage and processes it.
The SMPP protocol expects the sender name value in ASCII characters. The use of non-ASCII characters can cause the request to become garbled or even to be removed at the SMSC.
The maximum size of an SMS message is 140 bytes, regardless of the type of data coding used. If the content exceeds 140 bytes, Service Gatekeeper sends it as multiple SMS messages.
The standard GSM 03.38 alphabet uses 7 bits per character, allowing for 128 different characters with hexadecimal values 0x00 to 0x7F.
If all the characters in an SMS message are from the standard GSM alphabet, it is possible to send 160 of these 7-bit encoded characters in one SMS message of 140 bytes. This is because 140 bytes equals 1120 bits and if each character uses 7-bits, 160 (1120/7) characters fit into the message.
See the DefaultDataCoding field to SmsMBean for the default alphabet settings and payload size that Oracle recommends.
There is also an extended GSM alphabet that defines an additional 10 characters along with the original 128. These characters are sent as two 7-bit encoded characters, starting with the 7-bit encoded escape character (0x1B) from the standard alphabet. For example, if a message contains the character { from the extended alphabet, this character is encoded as 1B 28 where 1B is the escape character and 28 is the { extended character.
Each extended character requires two 7-bit encoded characters (escape character + extended character). Therefore, an SMS message containing a combination of characters from the standard GSM alphabet and characters from the extended GSM alphabet will hold fewer than 160 characters. The exact number depends on the particular mix of standard and extended characters.
For a list of the characters defined in the GSM standard and extended alphabets see the GSM web site:
http://www.csoft.co.uk/sms/character_sets/gsm.htm
To indicate that only SMS messages in which all the characters are from the standard or extended GSM alphabet, the DefaultDataCoding attribute should be set to 0. This is the default. setting. If the DefaultDataCoding attribute is set to 0 and the SMS message contains characters that are not in the standard or extended GSM alphabets, Services Gatekeeper rejects the message and throws an exception. If your SMSC sends 8-bit SMSs, set the DefaultDataCoding attribute to 1, which allows a maximum of 140 characters in an SMS.
It is possible to send characters that are not in the standard or extended GSM alphabets if the DefaultDataCoding attribute is configured appropriately.
In addition to the standard and extended GSM alphabets (called the ”SMSC Default Alphabet” in the SMPP v3.4 specification), two other common character sets are the IA5/ASCII character set and the UCS2 character set.
In the IA5/ASCII alphabet, the characters are 8-bit encoded, in other words one byte per character, so it is possible to send 140 of these 8-bit encoded characters in one SMS message that uses this coding scheme. If you are using the IA5/ASCII alphabet, set the DefaultDataCoding attribute for the plug-in to 1.
Characters in the UCS2 alphabet are 16-bit encoded, requiring two bytes per character, so it is possible to send only 70 of these characters in a single SMS message. If you are using the UCS2 alphabet, set the DefaultDataCoding attribute for the plug-in to 8.
For a complete list of supported character set values, see the ”data_coding” section in the SMPP v3.4 specification.
You can override the DefaultDataCoding attribute in requests using an xparameter or an SLA setting. This makes it possible, for example, to use the standard 7-bit GMS alphabet as the default but to send specific SMS messages using a different character set.
Use the data_coding xparameter for parameter tunneling in the header of the request or the com.bea.wlcp.wlng.plugin.sms.DataCoding parameter for defining the coding scheme in the <requestContext> element of an SLA.
For example, although the DefaultDataCoding parameter may be set to 0 for a plug-in instance, the following SOAP header sets the data coding scheme for its SMS message to 8, stipulating that the UCS2 character set should be used for encoding the SMS message in this particular request:
<soapenv: Header>
. . .
<xparams>
<param key="data_coding" value="8" />
<xparams>
. . .
</soapenv:Header>
In the next example, the <requestContext> element in an SLA sets the data coding scheme to 1, stipulating that the IA5/ASCII character set should be used for encoding SMS messages initiated by the application associated with this particular SLA:
<requestContext>
<contextAttribute>
<attributeName>ccom.bea.wlcp.wlng.plugin.sms.DataCoding</attributeName>
<attributeValue>1</attributeValue>
</contextAttribute>
</requestContext>
For information about the SOAP-based interface for the Parlay X 2.1 Short Messaging/SMPP communication service, see the discussion of Parlay X 2.1 Part 4: Short Messaging interface in Services Gatekeeper Application Developer's Guide.
The RESTful Service Short Messaging interfaces provide RESTful access to the same functionality as the SOAP-based interfaces. The internal representations are identical, and for the purposes of creating service level agreements (SLAs), reading charging data records (CDRs), and so on, they are the same. For information about the RESTful Short Messaging interface, see the discussion about the short messaging interface in Services Gatekeeper Application Developer's Guide.
The Parlay X 2.1 Short Messaging/SMPP communication service generates event data records (EDRs), CDRs, alarms, and statistics to assist system administrators and developers in monitoring the service.
See "Events, Alarms, and Charging" for more information.
Table 7-1 lists the IDs of the EDRs created by the Parlay X 2.1 Short Messaging/SMPP communication service. This list does not include EDRs created when exceptions are thrown.
Table 7-1 EDRs Generated by Parlay X 2.1 Short Messaging/SMPP
| EDR ID | Method Called |
|---|---|
|
6000 |
notifySmsDeliveryReceipt |
|
6001 |
notifiySmsReception |
|
7000 |
sendSms |
|
7001 |
sendSmsLogo |
|
7002 |
sendSmsRingtone |
|
7003 |
startSmsNotification |
|
7004 |
stopSmsNotification |
|
7011 |
getSmsDeliveryStatus |
|
7012 |
getReceivedSms |
See "Events and Statistics""Events and Statistics"for the list of EDRs generated by the SMPP Server Service.
Short Messaging/SMPP-specific generates CDRs under the following conditions:
After Services Gatekeeper has successfully received and processed an application-originated message, and successfully sent all segments of the message to the network.
After Services Gatekeeper receives and processes a delivery report sent from the network.
After Services Gatekeeper successfully receives and processes a mobile-originated message sent from the network.
Table 7-2 maps methods invoked from either the application or the network to the transaction types collected by the Services Gatekeeper statistics counters.
This section lists the parameters that can be tunneled or defined in the <requestContext> element of an SLA.
The dest_bearer_type, service_type, ussd_service_operation, its_session_info parameters are used to support unstructured supplementary service data (USSD).
You can include submit_date as xparam in delivery report notifications sent from Services Gatekeeper to application listeners. You must set the ForwardXParams MBeam attribute to true in order to include submit_date.
You can only include "submit date" when the delivery report from SMSC has the informational content inserted into the short_message parameter of the DeliverSm PDU as shown in the SMPP specification v 3.4, appendix B.
In ParlayX SOAP callbacks, the xparam is set in the SOAP header, for example:
<xparams xmlns="http://schemas.xmlsoap.org/soap/envelope/"
env:mustUnderstand="0">
<param xmlns="" key="submit date" value="1411251321"/>
<param xmlns="" key="originating_address" value="12345">
</xparams>
For SMS OneAPI callbacks it is set in HTTP header, for example:
X-Plugin-Param-Keys: submit_date,originating_address X-Plugin-Param-Values: 1411251324,12345
This parameter returns the date and time a message was delivered to a terminal for OneAPI facade communication. Your implementation must support the SMPP v 3.3 style communication that makes this information available. Also xparams must be configured by setting the Services Gatekeeper SmsMBean attribute ForwardXParams to true.
This example shows an SMS OneAPI callback set in the HTTP header:
X-Plugin-Param-Keys: done_date,originating_address X-Plugin-Param-Values: 1411251324,12345
This example shows a SOAP callback with the xparam set in the header:
<xparams xmlns="http://schemas.xmlsoap.org/soap/envelope/"
env:mustUnderstand="0">
<param xmlns="" key="done_date" value="1411251321"/>
<param xmlns="" key="originating_address" value="12345">
</xparams>
String
This parameter defines the mandatory SMPP protocol_id parameter.
It is valid for application-initiated requests only.
This parameter can be set using SLAs or parameter tunneling. An SLA setting overrides a tunneled parameter.
This parameter key name can be configured in the wlng.sms.protocol.id system property. The default is sms.protocol.id.
Integer
Value range is 0–65535.
This parameter defines the optional SMPP source_port parameter.
It is valid for application-initiated requests.
It is valid for network-triggered requests if the forwarding parameter is enabled. See the ForwardXParams field to SmsMBean for more information.
This parameter can be set using parameter tunneling.
Integer
Value range is 0–65535.
This parameter defines the optional SMPP destination_port parameter.
It is valid for application-initiated requests.
It is valid for network-triggered requests if the forwarding parameter is enabled. See the ForwardXParams field to SmsMBean for more information.
This parameter can be set using parameter tunneling.
Integer
Value range is 0–65535.
This parameter defines the mandatory SMPP data_coding parameter.
Overrides the DefaultDataCoding configuration attribute. See the DefaultDataCoding field in SmsMBean for more information.
It is valid for application-initiated requests.
It is valid for network-triggered requests if the forwarding parameter is enabled. See the ForwardXParams field in SmsMBean for more information.
This parameter can be set using parameter tunneling.
Signed Decimal
Value range is -128 – +127. Some values are restricted. See the SMPP specification for details.
This parameter defines the mandatory SMPP esm_class parameter.
It is valid for application-initiated requests only.
This parameter can be set using parameter tunneling.
Signed Decimal
Value range is -128 – +127. Some values are restricted. See the SMPP specification for details.
This parameter defines the mandatory SMPP service_type parameter.
It is valid for application-initiated requests only.
This parameter can be set using SLAs or parameter tunneling. An SLA setting overrides a tunneled parameter.
This parameter name can be configured in the wlng.sms.service.type system property. The default is sms.service.type.
String enumeration
Valid values are CMT, CPT, VMN, VMA, WAP, USSD, and an empty string (""). See the SMPP specification for details.
This parameter defines the mandatory SMPP replace_if_present_flag parameter.
It is valid for application-initiated requests only.
This parameter can be set using SLAs or parameter tunneling. An SLA setting overrides a tunneled parameter.
This parameter key name can be configured in the wlng.sms.replace.if.present system property. The default is sms.replace.if.present.
Integer
Value values are 0 and 1. See the SMPP specification for details.
This parameter defines a mapping ID.
The ID is used for looking up an SMPP ESME Type Of Number (TON) and an SMPP ESME Numbering Plan Indicator (NPI). The TON and NPI are configured using OAM.
This parameter is valid for application-initiated requests only.
This parameter can be set using SLAs or parameter tunneling. An SLA setting overrides a tunneled parameter.
String
This parameter defines a mapping ID.
The ID is used for looking up an SMPP ESME Type Of Number (TON) and an SMPP ESME Numbering Plan Indicator (NPI). The TON and NPI are configured using Oracle Access Manager (OAM).
The n is the number of the destination address. Valid values are 0 to one less than the number of destination addresses. An example of this parameter name would be:
com.bea.wlcp.wlng.plugin.sms.DestinationAddressType.2
This parameter is valid for application-initiated requests only.
This parameter can be set using SLAs or parameter tunneling. An SLA setting overrides a tunneled parameter.
String
This parameter defines the mandatory SMPP registered_delivery parameter.
It specifies whether delivery reports are requested for application-initiated requests.
It is valid for application-initiated requests only.
This parameter can be set using SLAs or parameter tunneling. An SLA setting overrides a tunneled parameter.
Boolean
0 - Delivery receipt is never requested (was the old false option).
1 - Delivery receipt is always requested (was the old true option).
2 - Delivery receipt is requested if the application requests a delivery report. It either provides a callback URL when sending the message, or by having subscribed for delivery report notifications (new option).
This parameter defines the mandatory SMPP data_coding parameter.
The plug-in uses it for encoding the message string.
It is valid for application-initiated requests only.
This parameter can be set using SLAs.
Integer
Value range is 0–255. Some values are restricted. See the SMPP specification for details.
This parameter defines the mandatory SMPP priority_flag parameter.
It is valid for application-initiated requests only.
This parameter can be set using SLAs.
String
Valid values are:
HIGH; Sets priority_flag to 3.
LOW; Sets priority_flag to 0.
DEFAULT; Sets priority_flag to 0.
UNDEFINED; Sets priority_flag to 0.
This parameter defines the originating address of the SMS in the delivery receipt.
When this parameter is used, the SmsMBean's Boolean forwardXParam attribute must be set to true to make the parameter appear in the SOAP header. By default, forwardXParam is false. See the ForwardXParams field to SmsMBean for more information.
This parameter can be set using parameter tunneling.
String
This parameter defines the billing information according to the format in the SMPP Specification 5.1, section 4.8.4.3 titled "billing_identification".
The parameter works with SMPP 5.1 SMSCs, but with not with SMPP 3.4 SMSCs.
The parameter is intended for use with Parlay X 2.1 SMPP.
Hexadecimal String
Table 7-3 describes the format.
Table 7-3 Format for smpp_bliing_id Value
| Field | Size (octets) | Type | Description |
|---|---|---|---|
|
parameter tag |
2 |
Integer |
0x060B |
|
length |
2 |
Integer |
Length of value part in octets |
|
value |
1 - 1024 |
Octet String |
Bits 7......0 0XXXXXXX (Reserved)1XXXXXXX (Vendor Specific) The first octet represents the Billing Format tag and indicates the format of the billing information contained in the remaining octets. |
If the value is not sent as a hexadecimal string, it is ignored and a warning is logged.
Here is sample code for encoding the string.
private String getHexEncodedString(String normalString) {
byte[] bHexStr = normalString.getBytes();
String retVal = "";
..String sOctet = null;
for (int i = 0; i < bHexStr.length; i++) {
sOctet = Integer.toHexString((int) (bHexStr[i] & 0xFF));
if (sOctet.length() == 1) {
sOctet = "0" + sOctet;
}
retVal = retVal.concat(sOctet);
}
return retVal.toUpperCase(); }
This parameter defines the dest_addr_subunit field in the following SMPP operations:
SUBMIT_SM
SUBMIT_MULTI
DATA_SM
It can be set using parameter tunneling.
Signed Decimal
The decimal value is automatically converted to a hexadecimal string before it is passed to the SMPP dest_addr_subunit field.
Value range is -128 – +127.
<xparams> <param key="dest_addr_subunit" value="1"/> </xparams>
This parameter is used to request the desired bearer for delivery of the message to the destination address.
If the receiving system (the SMSC) does not support the indicated bearer type, it may return a response PDU reporting a failure.
For the formal definition of the parameter and section 4.7.1 for its specification as an optional parameter for the DATA_SM operation, see section 5.3.2.5 of the Short Message Peer to Peer Protocol Specification v3.4 at:
http://docs.nimta.com/SMPP_v3_4_Issue1_2.pdf
This parameter can be set using parameter tunneling.
Unsigned Byte [0–255]
Valid values are:
0x00 = Unknown
0x01 = SMS
0x02 = Circuit Switched Data (CSD)
0x03 = Packet Data
0x04 = USSD
0x05 = CDPD
0x06 = DataTAC
0x07 = FLEX/ReFLEX
0x08 = Cell Broadcast (cellcast)
9 to 255 Reserved
This parameter indicates the SMS application service associated with the message. Allows the ESME to use enhanced messaging services such as replace_if_present and to control the teleservice used on the air interface (for example, ANSI-136/TDMA and IS-95/CDMA).
It is used to support tunneling USSD (3G TS 23.090 version 3.0.0) messages through the SMPP protocol.
For the formal definition of the parameter and the appropriate subsections of section 4 for its specification as a mandatory parameter for SUBMIT_SM, SUBMIT_MULTI, DELIVER_SM, DATA_SM, and CANCEL_SM, see section 5.2.11 of the Short Message Peer to Peer Protocol Specification v3.4 at
http://docs.nimta.com/SMPP_v3_4_Issue1_2.pdf.
This parameter can be set using parameter tunneling.
Octet string
The predefined generic service type value for USSD is USSD.
This parameter defines the USSD service operation that is required when SMPP is used as an interface to a (GSM) USSD system.
It is used to support tunneling USSD (3G TS 23.090 version 3.0.0) messages through the SMPP protocol.
It is used as an optional parameter to the SMPP SUBMIT_SM operation.
This parameter is defined in section 5.3.2.44 of the Short Message Peer to Peer Protocol Specification v3.4.
It was added to the DELIVER_SM operation in the SMPP 5.1 specification. See Short Message Peer to Peer Protocol Specification Version 5.1.
This parameter can be set using parameter tunneling.
Unsigned byte [0–255]
Valid values are:
0 = PSSD indication
1 = PSSR indication
2 = USSR request
3 = USSN request
4 to 15 Reserved
16 = PSSD response
17 = PSSR response
18 = USSR confirm
19 = USSN confirm
20 to 31 Reserved
32 to 255 Reserved for vendor-specific USSD operations
This is a required parameter for the CDMA Interactive Teleservice as defined by the Korean PCS carriers [KORITS]. Contains control information for the interactive session between an MS and an ESME.
See section 5.3.2.43 of the Short Message Peer to Peer Protocol Specification v3.4 for the formal definition of the parameter and the appropriate subsections of section 4 for its specification as an optional parameter for SUBMIT_SM, DELIVER_SM, and DATA_SM.
This parameter is also supported for native SMPP.
This parameter can be set using parameter tunneling.
Unsigned Short (2 bytes) [0–65535] as an octet string
Following is a description of the octet string.
Bits 7...............0
SSSS SSSS (octet 1)
NNNN NNNE (octet 2)
Octet 1 contains the session number (0–255) encoded in binary. The session number remains constant for each session.
Octet 2 encodes the sequence number of the dialog unit (as assigned by the ESME) within the session in bits [7. . . 1].
Bit 0 of octet 2 is the End of Session Indicator, indicating that the message is the end of the conversation session. Valid values for the End of Session Indicator are:
0 = End of Session Indicator inactive
1 = End of Session Indicator active
An application or interceptor uses this parameter to pass integer data to a plug-in in TagLengthValue (TLV) data units. A TLV data unit consists of a tag/value pair. This parameter passes a list of comma-separated items that are the tag parts of the data units.
See "smpp_optional_octet_tlv_param_tags" for sending data that is not of type integer.
The smpp_optional_int_tlv_param_tags list must have the same number of entries as its corresponding smpp_optional_int_tlv_param_values list. See "smpp_optional_int_tlv_param_values".
Within a TLV data unit, the sizes of the tag and length fields are each 2 bytes. The value of length field is always "0x00, 0x04", because integer data is always encoded in 4 bytes.
An example of code to tunnel TLV integer data is:
injectXParam(TLV_OPTIONAL_INT_PARAM_TAGS, "5121,5124"); injectXParam(TLV_OPTIONAL_INT_PARAM_VALUES, "999,1234");
This parameter can be set using parameter tunneling.
The tag identifiers must be in decimal format. For example, set a tag with the hexadecimal value 0x1401 as 5121.
An application or interceptor uses this parameter to pass integer data to a plug-in in TagLengthValue (TLV) data units. A TLV data unit consists of a tag/value pair. This parameter passes a list of comma-separated items that are the value parts of the data units.
See "smpp_optional_octet_tlv_param_values" for sending data that is not of type integer.
The smpp_optional_int_tlv_param_values list must have the same number of entries as its corresponding smpp_optional_int_tlv_param_tags list. See "smpp_optional_int_tlv_param_tags".
Within a TLV data unit, the sizes of the tag and length fields are each 2 bytes. The value of length field is always "0x00, 0x04", because integer data is always encoded in 4 bytes.
An example of code that tunnels TLV integer data is:
injectXParam(TLV_OPTIONAL_INT_PARAM_TAGS, "5121,5124"); injectXParam(TLV_OPTIONAL_INT_PARAM_VALUES, "999,1234");
This parameter can be set using parameter tunneling.
An application or interceptor uses this general-purpose parameter to pass any type of data to a plug-in in TagLengthValue (TLV) data units. A TLV data unit consists of a tag/value pair. This parameter passes a list of comma-separated items that are the tag parts of the data units.
See "smpp_optional_int_tlv_param_tags" for sending integer data.
The smpp_optional_octet_tlv_param_tags list must have the same number of entries as its corresponding smpp_optional_octet_tlv_param_values list. See "smpp_optional_octet_tlv_param_values".
Within a TLV data unit, the sizes of the tag and length fields are each 2 bytes. The value of length field is the size of the actual data in the value field in the corresponding smpp_optional_octet_tlv_param_values parameter.
An example of code that tunnels TLV octet data is:
injectXParam(TLV_OPTIONAL_OCTET_PARAM_TAGS, "5121,5124", rctx);
injectXParam(TLV_OPTIONAL_OCTET_PARAM_VALUES, "03e7,04d2", rctx);
private void injectXParam(String name, String value, RequestContext rctx){
rctx.putXParam(name, value);
This parameter can be set using parameter tunneling.
The tag identifiers must be in decimal format. For example, set a tag with the hexadecimal value 0x1401 as 5121.
An application or interceptor uses this general-purpose parameter to pass any type of data to a plug-in in TagLengthValue (TLV) data units. A TLV data unit consists of a tag/value pair. This parameter passes a list of comma-separated items that are the value parts of the data units.
See "smpp_optional_int_tlv_param_values" for sending integer data.
The smpp_optional_octet_tlv_param_values list must have the same number of entries as its corresponding smpp_optional_octet_tlv_param_tags list. See "smpp_optional_octet_tlv_param_tags".
Within a TLV data unit, the sizes of the tag and length fields are each 2 bytes. The value of length field is the size of the actual data in the value field.
An example of code that tunnels TLV octet data is:
injectXParam(TLV_OPTIONAL_OCTET_PARAM_TAGS, "5121,5124", rctx);
injectXParam(TLV_OPTIONAL_OCTET_PARAM_VALUES, "03e7,04d2", rctx);
private void injectXParam(String name, String value, RequestContext rctx){
rctx.putXParam(name, value);
This parameter can be set using parameter tunneling.
The tag identifiers must be in decimal format. For example, set a tag with the hexadecimal value 0x1401 as 5121.
This parameter specifies the scheduled time at which the message delivery should be first attempted. It defines either the absolute date and time or relative time from the current SMSC time at which delivery of this message will be attempted by the SMSC.
The PDU parameter is schedule_delivery_time.
ASCII string specified as YYMMDDhhmmsstnnp where:
YY: last two digits of the year, from 00 to 99.
MM: month from 1 to 12.
DD: day from 01 to 31.
hh: hour from 00 to 23.
ss: second from 00 to 59.
t: tenths of a second from 0 to 9.
nn: time differential in 15 minute increments between the local time (as expressed in the first 13 octets) and Universal Time Coordinated (UTC) from 00 to 48.
p +: local time is in 15 minute increments advanced in relation to UTC.
p -: local time is in 15 minute increments retarded in relation to UTC.
p R: local time is relative to the current SMSC time.
The validity_period parameter indicates the SMSC expiration time, after which the message should be discarded if not delivered to the destination. It can be defined in absolute time format or relative time format.
The PDU parameter is validity_period.
ASCII string specified as YYMMDDhhmmsstnnp where:
YY: last two digits of the year, from 00 to 99.
MM: month from 1 to 12.
DD: day from 01 to 31.
hh: hour from 00 to 23.
ss: second from 00 to 59.
t: tenths of a second from 0 to 9.
nn: time differential in 15 minute increments between the local time (as expressed in the first 13 octets) and Universal Time Coordinated (UTC) from 00 to 48.
p +: local time is in 15 minute increments advanced in relation to UTC.
p -: local time is in 15 minute increments retarded in relation to UTC.
p R: local time is relative to the current SMSC time.
This section describes the properties and workflow for setting up Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP network protocol plug-in instances. These plug-in instances share the same configuration options.
The Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP communication services rely on an SMPP Server Service for connecting to the Small Message Service Center (SMSC).
The SMPP Server Service is also used by the Native SMPP Communication Service. See "Native SMPP" for information on managing client connections using SMPP Server Service.Configuration facilities for the SMPP Server Service are described in detail in the following sections of "Native SMPP":
Table 7-4 lists the technical specifications for the communication service.
Table 7-4 Properties for Parlay X 2.1 Short Messaging/SMPP and EWS Binary SMS/SMPP
| Property | Description |
|---|---|
|
Managed object in Administration Console |
To manage the object, select domain_name, then OCSG, then server_name. then Communication Services, then plugin_instance_id in that order. |
|
MBean |
Domain=com.bea.wlcp.wlng Name=wlng_nt InstanceName=same as the network protocol instance_id assigned when the plug-in instance is created Type=oracle.ocsg.sms.smpp.management.SmsMBean Documentation: See the ”All Classes” section of Services Gatekeeper OAM Java API Reference |
|
Network protocol plug-in service ID |
Plugin_px21_short_messaging_smpp |
|
Network protocol plug-in instance ID |
The ID is assigned when the plug-in instance is created. See "Managing and Configuring the Plug-in Manager" in Services Gatekeeper System Administrator's Guide. |
|
Supported Address Scheme |
tel |
|
Service type |
Sms |
|
Exposes to the service communication layer a Java representation of: |
Parlay X 2.1 Short Messaging/SMPP:
Extended Web Services Binary SMS/SMPP:
|
|
Interfaces with the network nodes using: |
SMPP 3.4 |
|
Deployment artifacts |
wlng_nt_sms_px21.ear and wlng_at_sms_px21.ear |
Following is an outline for configuring the plug-in using the Administration Console or an MBean browser.
Create one or more instances of the plug-in service. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in service ID as listed in the "Properties for Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP" section.
Using the Administration Console or an MBean browser, select the MBean for the plug-in instance. The MBean display name is the same as the plug-in instance ID given when the plug-in instance was created.
Configure the behavior of the plug-in instance. Seethe description about SmsMBean in the "All Classes" section of the Services Gatekeeper Java API Reference for the list of fields and methods.
If desired, configure the supportBulkRequest attribute to manage Split and Submit Messaging. See the discussion on attribute: supportBulkRequest in Services Gatekeeper System Administrator's Guide.
If the plug-in uses short code mappings, configure the Short Code Mapper. See the discussion on managing and configuring shortcode mappings in Services Gatekeeper System Administrator's Guide.
Set up the routing rules to the plug-in instance. See the discussion about configuring and managing the plug-in manager in Services Gatekeeper System Administrator's Guide. Use the plug-in instance ID and address schemes listed in the "Properties for Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP" section.
If required, create and load a node SLA. For details see "Defining Global Node and Service Provider Group Node SLAs and Managing SLAs in Services Gatekeeper Portal Developer's Guide.
Provision the service provider accounts and application accounts. For information, see Services Gatekeeper Portal Developer's Guide.
The Parlay X 2.1 Short Messaging/SMPP and Extended Web Services Binary SMS/SMPP communication services use the SMPP Server Service to establish and manage client connections with the SMSC.
The SMPP Server Service establishes a client connection to the SMSC when the plug-in instance is activated or when the administrator resets the client connection by using the resetClientConnection SMPP Server Service operation.
The following Server Service methods to the SMPPServiceMBean, described in "Native SMPP" manage client connections:
closeClientConnection
listClientConnections
listPluginInstances
resetClientConnection
For a description of the attributes and operations of the SmsMBean and SMPPServiceMBean, see the "All Classes" section of Services Gatekeeper OAM Java API Reference.