SMPP submit_sm message payload character Limit 254 vs 140 Octet

When utilizing the submit_sm operation in SMPP protocol, the message text data should be placed in one of two designated fields:

The short_message field (a mandatory field).
The message_payload field (an optional TLV field).
It is not permissible to use both fields simultaneously.

When opting for the short_message field, the sm_length field must specify the length in octets of the short_message field data and should be set accordingly. If the message_payload field is utilized, the sm_length field must still be employed, but it will be set to 0, indicating the use of the message_payload field instead.

When employing the data_sm operation, the message text data can only be inserted in the message_payload field, and the sm_length field is omitted.

For both operations, it is stipulated that up to 254 octets can be accommodated in the short_message field, whereas the message_payload field can contain up to 64K octets. However, the GSM standard limits a single short message to 140 octets, thereby constraining transmission to this maximum. (https://en.wikipedia.org/wiki/GSM_03.38)

As a result, a receiving SMSC typically rejects a submit operation that would yield a short message exceeding 140 octets unless it employs an automatic concatenation mechanism, dividing long messages into multiple parts of 140 octets each. In most SMSC, on the fly concatenation is not supported and it is expected that ESME will restrict the message payload to 140 octets and hand the concatenation at their end using UDH.

It’s worth noting an important distinction between the short_message field and the message_payload field: The short_message field, being a mandatory parameter and defined as an octet string type, requires a NULL character after the short message text. However, this requirement does not apply to the message_payload field, which is optional and based on Tag-Length-Value (TLV) structures.

Beyond the Message

Ideas and innovations driving the next era of customer communication

How A2P Aggregators Can Monetize WhatsApp in Their CPaaS Stack

The global messaging landscape is evolving—and fast. While A2P SMS remains a reliable and widely-used […]

A2P Messaging Unplugged: Understanding Tomorrow’s Trends Today 

A2P messaging is evolving fast, and service providers are leading the charge. Businesses now need to offer seamless, multi-channel communication across SMS, WhatsApp, email, and more. With Rich Communication Services (RCS) bringing a new dimension to SMS and personalized messaging driving engagement, it’s all about delivering timely, tailored experiences. Security, scalability, and API integration are key to staying competitive, while analytics help fine-tune strategies. Power SMPP is built to support service providers with innovative tools for high-volume, secure, and personalized messaging, ensuring they stay ahead in this rapidly changing landscape.

WhatsApp API : A Game- changer for CPaaS Omni – channel platforms

Imagine switching from a WhatsApp chat to an SMS without missing a beat. Today’s consumers expect this seamless experience, and CPaaS providers and SMS aggregators must adapt. The global A2P messaging market is growing steadily, and integrating channels like WhatsApp alongside SMS is essential for staying competitive. Power SMPP empowers CPaaS platforms to offer a unified, omnichannel approach—boosting reach, engagement, and scalability. With advanced routing, real-time analytics, and robust security, Power SMPP provides solutions for success in the evolving messaging landscape. Learn more in our latest blog.

× How can I help you?
🏆 MEFFYS Awards 2025 finalists! in Best Enterprise Communication Platform
This is default text for notification bar