SMPP v5 is the latest release of the SMPP protocol specification.
This version is an enhancement of SMPP v3.4. The version number change from SMPP v3.4 to SMPP v5.0 is intended to avoid confusion with the proprietary Logica SMPP v4.0 specification.The specification incorporates many changes defined by the SMS Forum during the lifetime of v3.4. The layout has also been revised to cater for a more detailed and clearer description of the protocol functionality.
The new features are summarized as follows:
- Addition of Cell Broadcast operations for use with CBCs (Cell Broadcast Centres).
- New registered mode for “successful delivery only” delivery receipts.
- Enhanced the
network_error_codeTLV to classify several additional error types. - New
congestion_stateTLV added to support flow control and congestion avoidance. See below. - Added
ussd_service_opTLV support to deliver_sm for bi-directional USSD. - Added additional error codes for service_type restrictions (
ESME_RSERTYPDENIED,ESME_RSERTYPUNAUTH,ESME_RSERTYPUNAVAIL) - Added error code,
ESME_RPROHIBITEDto indicate a prohibited operation. - Added
billing_identificationTLV to support pass-through billing information between ESME and MC. - Enhanced
alert_on_message_deliveryTLV to support new alert modes for CDMA. - Added
dest_addr_np_country,dest_addr_np_information,dest_addr_np_resolutionTLVs to enable the encoding of number portability information for inter-carrier routing. - Added end point Identification TLVs (
source_network_id,source_node_id,dest_network_id,dest_node_id) to enable intelligent routing with intra- and inter-carrier architectures.
See SMPP Protocol Overview for a general overview of SMPP.
Key Aspects of SMPP v5.0
Flow Control and Congestion Avoidance
It is a common misconception that windowing provides full flow control. However, as discussed in section 2.6.4 of the Short Message Peer-to-Peer Protocol Specification v5, all that is gained is a finite limit to an asynchronous window. A maxed out window prevents the originator from issuing more requests until responses arrive, but this is not flow control.
Flow control relates to the concept of a receiver informing the sender that it can’t accept any more data.
In TCP, this concept is supported by a ‘receiver buffer advertisem*nt’, which can be passed with every packet acknowledgement. The sender uses this data as a means of judging how much more data can be sent in subsequent transmissions. This mechanism works fine for TCP, given that congestion is based mostly on volumes of data being sent across busy networks or to a congested receiver.
In terms of SMPP, if an ESME or MC submits/delivers messages at a rate that exceeds the capabilities of its peer, congestion may occur. Relying on windowing to solve the problem is not enough. The ESME will continue to top up its window of unacknowledged requests, keeping the MC under load to process these requests.
To better assist a peer (ESME or MC) in avoiding congestion, the peer needs a mechanism to provide the receiving peer with an indication of its state of congestion.
This is accomplished with the addition of an optional congestion_state TLV. This parameter may be optionally included in any response PDU sent between an ESME and MC. This TLV contains a simple integer from 0-100 to indicate the congestion state ranging from idle to congested. Refer to 4.8.4.18 of the Short Message Peer-to-Peer Protocol Specification v5 for details on the values acceptable for this TLV.
The ESME or MC can use this value as a means of detecting increased load scenarios on its peer and take the appropriate action to reduce its input rates. In order to get the maximum throughput from the transfer of messages, the MC or ESME should try to maintain the congestion state between 80-90 (Optimum Load).
When commencing a SMPP session, the ESME or MC would begin transmission of requests, with a maximum window of N. If the ESME or MC supports the congestion_state TLV, then as the responses arrive, the ESME/MC can increase/decrease its transmission rate according to the indicated congestion state of its peer. If the congestion_state TLV is supported, then the Window of N can actually be discarded as the congestion_state itself acts as a better indicator and preventative measure of congestion avoidance.
If the TLV is not present in response PDUs, then simple linear windowing is the only means of applying flow control within the session.
The advantage of using congestion_state over a fixed window is that the ESME can avail of the optimum performance available at a particular time instead of predetermining some window limit and using this consistently. This recognises that a MC or ESME may be under varying levels of stress and that predetermined performance is not always guaranteed.
The above diagram shows a session where an ESME is transmitting PDUs at a rate of 50/second. On recognising the congestion_state TLV and its below Optimum value, the ESME increased its rate until the congestion_state enters an optimum range. At this point, the ESME maintains the 120 PDUs/second until the congestion_state enters ‘Nearing Congestion’, at which time the ESME relaxes the messaging rate to return the congestion_state to an optimum level.
SMPP Specifications
- Short Message Peer-to-Peer Protocol Specification v5
