Everything worth knowing, nothing that isn't.
What it actually does
An SMS submit_sm includes a data_coding field that tells the SMSC how to interpret the message body. DCS = 0x00 (or 0x01) means GSM 7-bit, the default 160-character encoding. DCS = 0x08 means UCS-2, two bytes per character. The SMSC propagates the data_coding to the recipient operator's SMSC, which propagates it to the handset; the handset displays the body using the indicated encoding. Mixing — sending a GSM-7-encoded body with a UCS-2 character in it — is a protocol violation and produces garbled display.
Why it matters commercially
For MENA messaging, UCS-2 is the default — virtually all consumer-facing Arabic A2P traffic is UCS-2, and so each message costs 2-3 segments instead of 1. This is not optional; transliterating Arabic into Latin destroys consumer recognition and engagement. The mature operator practice is to pre-classify Arabic UCS-2 traffic at the SMSC and price it appropriately. For Latin-script markets, the optimisation is to scrub composition for accidental UCS-2 triggers (em-dashes, curly quotes, emoji from a marketer's Word document) before submit.
Operational angle
Most aggregators auto-detect encoding from the submitted body and set data_coding accordingly. Some let you force the encoding (useful for testing). When debugging billing surprises ("why is my Arabic campaign costing 3x what I expected?"), the first thing to check is the data_coding distribution of the campaign — if you expected GSM-7 but the bodies are coming through as UCS-2, somebody added a curly quote.
Privacy and compliance considerations
Encoding is metadata; it is not personal data on its own and is not in PDPL/GDPR scope. But UCS-2 is the encoding used for Arabic, which means UCS-2 traffic is statistically more likely to carry MENA-resident personal data. Operators in regulated MENA markets typically apply the strictest data-residency rules to UCS-2 traffic specifically, on the safe-default assumption that it carries local-language personal data.