Concatenated Segments in A2P SMS: How to Validate the Actual Count Before Sending Traffic

What Counts as an SMS Segment, and Why Character Counts Are Not Enough

A segment is an SMS transmission unit. If the text does not fit in the available payload, it may be split into multiple concatenated parts that the recipient’s device reassembles. That is why counting visible characters is not enough: the result depends on how they are encoded and how much space the technical information accompanying the text takes up.

The TP-UD payload may contain only user data or may include a header. When a header is present, its length also uses some of the available space. In concatenated messages, the header identifies the message and the position of each part.

• Do not confuse visible Unicode characters with transmitted units.
• The technical segment count does not, by itself, determine a commercial rate.
• Effective capacity depends on the encoding and concatenation method.

GSM 7-bit, Escape Characters, and Unicode

In GSM 7-bit, characters are represented using septets. However, not every symbol commonly described as a character uses just one septet: symbols in the extension table are represented by an escape sequence and use two. The calculation must count encoded units, not just text positions.

If a character is not in the applicable GSM tables, the sender may need to use another encoding, such as UCS2. UCS2 represents each character in 16-bit units. Emojis and other characters outside the GSM repertoire require checking which encoding the system actually selects; do not assume the message will remain in GSM 7-bit.

National language tables can also affect the choice of encoding and the calculation. The effective encoding depends on the content, configuration, and implementation of the sender or route.

• Count each GSM 7-bit symbol that uses an escape sequence as two septets.
• Check how the encoder handles accents, symbols, emojis, and less common characters.
• Do not assume a default value for data_coding in SMPP: the SMPP v3.4 specification states that there is no default.

How Concatenation Affects Capacity

Concatenation reserves space for a user data header (UDH), which contains information needed to reconstruct the message. The header may include a shared reference, the total number of parts, and the sequence number. In GSM 7-bit, bit padding may also be needed to align the text after the header.

As a standards-based reference, 3GPP TS 23.040 specifies capacities of 153 GSM 7-bit characters or 67 UCS2 characters per segment with the standard concatenation header using an 8-bit reference. For the 16-bit reference variant, it specifies 152 and 66, respectively. These are technical reference capacities, not a guarantee that every platform or route uses the same method.

The specification also requires certain sequences not to be split between segments: GSM escape characters and UCS2 characters must remain intact. As a result, a simple split into blocks of characters can produce an incorrect calculation.

• Confirm whether the implementation uses an 8-bit or 16-bit concatenation reference.
• Do not use reference limits as a substitute for checking the actual header.
• Distinguish technical segmentation from the billing rules agreed with each provider.

A Reproducible Method for Calculating Segments

To make the calculation repeatable and auditable, base it on the exact text that will be sent. A preview may differ from the transmitted content because of substitutions, spaces, line breaks, or characters added by a template.

Follow this procedure before production and retain the calculation output with the sending request.

• 1. Capture the exact final text after personalization and substitutions.
• 2. Identify the encoding and effective tables used by the encoder; do not infer them from the text’s appearance alone.
• 3. If using GSM 7-bit, count septets and count extension-table characters as two units. If using UCS2, count the 16-bit units according to the encoder in use.
• 4. Determine the concatenation method and the space taken up by the header. Account for septet alignment where applicable.
• 5. Calculate how many parts are required, ensuring that escape sequences and UCS2 characters are not split.
• 6. Save the result alongside a version or hash of the text, the encoder configuration, and the prepared payload.

Test Cases Before Changing Templates or Encoders

Test both boundaries and encoding changes. A short message can expand to multiple parts when a single added character forces a different scheme; an extension-table symbol can use two septets even though it occupies one visible character position.

Use controlled test cases and retain the exact text for each one. Do not change the content, encoding, and concatenation method all at once, or it will be difficult to identify the cause of a difference.

• Text containing only characters from the default GSM table.
• Text that includes characters from the extension table.
• Text with accents, symbols, or emojis to see whether the encoding changes.
• Messages near the limits for one and multiple parts, using the reference method actually configured.
• Changes to line breaks, spaces, and template variables that alter the final text.

Verify the Accepted Request and the Logs

Cross-check the local calculation against what was sent. In SMPP, review the value of data_coding, the content of short_message or message_payload as applicable to the implementation, and the UDH or SAR parameters used. The SMPP v3.4 specification defines sar_msg_ref_num, sar_total_segments, and sar_segment_seqnum to communicate the reference, total, and sequence; it states that all three related parameters must be present to process the SAR reference.

A successful submit_sm_resp confirms the outcome of the request and may return a message_id, but the standard format does not include a field confirming the number of accepted segments. Acceptance therefore does not replace comparison with platform or provider logs.

If sending through an HTTP API, consult its documentation to find out what its response represents and whether it exposes segmentation details. Do not assume that an acceptance response reports the technical count.

• Compare the text or its hash, encoding, UDH or SAR parameters, and sending response.
• Link the message_id to subsequent records when available.
• Consult the API, provider, and route documentation to interpret reported fields.
• Do not confuse acceptance, DLR, and independent confirmation of receipt on the device.

Investigate and Reconcile Discrepancies Without Inferring Rates

A difference between a local calculation and an external record may result from comparing different texts, selecting another encoding, using a different concatenation method, or a platform applying a transformation. Systems may also report different types of data. First isolate what was sent and which unit each party is recording.

Keep the technical segment count separate from commercial reconciliation. Technical standards describe encoding, payload, and concatenation; they do not establish the applicable rate. For any charges, use the relevant contractual terms and billing records.

• Retain the exact text or its hash and the template version.
• Record the encoding, data_coding, calculated units, and concatenation method.
• Save the UDH or SAR parameters, sending result, and message_id.
• Note the segments reported by each system, their source, and the time period.
• Investigate one variable at a time and document the conclusion before changing production.

Checklist and Technical References

Before enabling a template or changing the sending setup, confirm that the calculation uses the final text, that the effective encoding has been identified, and that the concatenation method matches the actual configuration. Repeat the test whenever the content, encoder, API, SMPP session, or route changes.

For standards details, consult 3GPP TS 23.038 for alphabets and encoding; 3GPP TS 23.040 for SMS technical implementation and headers; and SMPP v3.4 for data_coding, responses, and SAR parameters.

• Does the test text match the sent text byte for byte or by hash?
• Have GSM 7-bit, escape characters, and possible changes to UCS2 been checked?
• Has the concatenation method and its header been confirmed?
• Are the request, response, identifier, and relevant records retained?
• Is technical reconciliation kept separate from rate interpretation?