|
|
The following chapter describes the Parlay X 2.1 Short Messaging communication service in detail:
The Short Messaging communication service implements the Parlay X 2.1 Short Messaging set of interfaces. For the exact version of the standard this communication service supports, see “Appendix A: Standards and Specifications” in Concepts and Architectural Overview, another document in this set.
Using a Short Messaging communication service, an application can:
| Note: | Logos must be in either SmartMessaging or EMS format. The image is not scaled. Ringtones must be in either SmartMessaging or EMS (iMelody) format |
Requests can flow in two directions using the Parlay X 2.1 Short Message 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”). Both of these scenarios are covered below.
Once an application has sent a Short Message to one or more destination addresses, two different types of responses can be returned:
Send Receipts are merely acknowledgements that the network node has received the Short Message from the application by means of Network Gatekeeper. Although a single Short Message may be sent to multiple destination addresses, normally only one Send Receipt is returned to the application by Network Gatekeeper. 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 states:
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 either choose to have Delivery Receipts delivered to them automatically by supplying Network Gatekeeper with a call-back interface or they can chose to poll Network Gatekeeper.
If the application supplies a call-back interface, there are two possible outcomes:
If the application chooses not to supply a call-back interface, Network Gatekeeper stores the Delivery Receipt in temporary in-memory storage. The application can poll Network Gatekeeper for these Receipts. Each stored Delivery Receipt is time-stamped and, after a configurable time-period, is removed.
In order to correlate a sent message with a delivery receipt form the network node, information about the message is stored in Gatekeeper 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.
| Note: | The Short Messaging communication service does put any limitation on the size of the payload in a Short Message. If the network protocol used restricts the size of the payload, Network Gatekeeper splits the Short Message into appropriately sized parts. |
Two sorts of traffic destined for an application can arrive at Network Gatekeeper from the network, including:
In order for an application to receive Short Messages from the network, it must register its interest in these Short Messages by setting up a subscription in Network Gatekeeper. A subscription, or notification, is defined by a Service Activation Number, the destination address to which the mobile sender directs the Short Message. This is usually a Short Code.
Additional criteria can be tied to the Service Activation Number, such as the first word of the text in the Short Message payload. For Network Gatekeeper to accept a message, both the Service Activation Number and the additional criteria must match the details set up in the subscription. Each registered subscription must be unique, and subscription attempts with overlapping criteria are rejected. The application may choose either to poll Network Gatekeeper for received Short Messages or it may include a call-back interface in setting up the original subscription.
If a Short Message that matches a subscription arrives at Network Gatekeeper from the network and the original subscription includes a call-back interface, there are two possible results:
registrationIdentifier has been established. In such a case Network Gatekeeper acknowledges the reception of the Short Message to the network. If no provisioning has been done, Network Gatekeeper returns an error to the network. Each stored Short Message is time-stamped and, after a configurable time-period, is flushed to disk and removed from in-memory storage. The application can poll Network Gatekeeper for any stored Short Messages.If a Short Message that matches a subscription arrives at Network Gatekeeper, and the original subscription does not include a call-back interface, the Short Message is stored in temporary in-memory storage and Network Gatekeeper acknowledges the reception of the Short Message to the network. The application can poll Network Gatekeeper for any such Short Messages. Each stored Short Message is time-stamped and, after a configurable time-period, is removed.
If a Short Message arrives at Network Gatekeeper and no matching subscription is found, Network Gatekeeper does not acknowledge reception to the network. It is the responsibility of the network node to handle any further processing of the Short Message.
| Note: | Short Message communication services do not put any limitations on the size of the payload in a message. If the network protocol used restricts the size of the payload, Network Gatekeeper can concatenate Short Message segments into one single Short Message before delivering it to an application. If configured to concatenate segments, it is also configurable whether to deliver parts of the message to the application regardless if all segments have arrived to Network Gatekeeper or not, and after which time period the segments are considered as lost and the message is propagated to the application. |
Off-the shelf, the Short Messaging communication service can be configured to support the following network protocol:
When Network Gatekeeper is configured to use this protocol, it 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 Network Gatekeeper supports. See the System Administrator’s Guide for a description of how the plug-in connects to an SMPP v.3.4 compliant SMSC.
| Note: | SMPP expects the sendName 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 SMSC. |
A common feature of Messaging capable networks is the use of 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 shorter sequences when they dial, which are then mapped to the full address in the network. The Parlay X 2.1 Short Messaging to SMPP communication service supports short codes and message prefixes, which allow the same short code to be mapped to multiple addresses, based on what is prepended to the enclosed message.
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 Parlay X 2.1 Short Messaging communication service, including:
There are three Short Messaging/SMPP specific CDRs. They occur when the following criteria are met:
sendSms is sent from Network Gatekeeper to the network, using either plug-in.reportNotification is sent from the network to Network Gatekeeper, indicating that a Delivery Receipt has been returned for the application, using either plug-in.
The following is a list of EdrIds created by the Short Messaging/SMPP communication service. This list does not include EDRs created when exceptions are thrown. For more information, see Events, Alarms, and Charging..
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 Network Gatekeeper for the Parlay X 2. Short Messaging/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. |
The Parlay X 2.1 Short Messaging/SMPP communication service supports the tel: address scheme.
|