Fact-checked by Grok 2 weeks ago

Data Coding Scheme

A Data Coding Scheme (DCS) is a one-octet field defined in the Short Message Service (SMS) protocol for , , , and other mobile cellular networks, which specifies the encoding format of the message user data field (TP-UD) and may indicate additional attributes such as message class or compression. This field ensures that recipient devices correctly interpret the content of short messages and messages by signaling the character set, such as GSM 7-bit default alphabet (supporting up to 160 characters), 8-bit binary data (up to 140 octets), or UCS2 (up to 70 characters). Standardized in Technical Specification TS 23.038, the DCS plays a critical role in across mobile networks by preventing garbled text or during transmission. The structure of the DCS octet divides into two 4-bit : the most significant nibble (bits 7-4) identifies the coding group, while the least significant nibble (bits 3-0) provides group-specific details like character set indicators or classes. For instance, coding group 00 ( 00xx) is used for general data coding, where bit 5 signals (0 for uncompressed, 1 for compressed per TS 23.042), bits 3-2 select the character set (00 for 7-bit, 01 for 8-bit data, 10 for UCS2, and 11 reserved), and bits 1-0 denote the class if bit 4 is set (e.g., 00 for Class 0 immediate display, 01 for Class 1 (ME storage)). Other groups handle specialized cases, such as 01xx for messages marked for automatic deletion, 11xx for waiting indications (MWI), and reserved values that default to 7-bit encoding to maintain . In practice, the DCS enables efficient delivery in protocols like (Short Message Peer-to-Peer), where it informs gateways and handsets about text encoding to support international characters or binary payloads like ringtones and logos. Common values include DCS 0x00 for plain 7-bit text without class specification and 0x08 for UCS2-encoded messages, ensuring broad support across diverse devices while adhering to the 140-octet limit (adjusted for DCS and other headers). Evolving with mobile standards, the DCS remains essential for legacy and modern applications, including over-the-air updates and multimedia messaging precursors.

Fundamentals

Definition and Purpose

The Data Coding Scheme (DCS) is an 8-bit field within the Transfer Protocol Data Unit (TPDU) of Short Message Service (SMS) protocols, used to specify the encoding of user data, including character sets, languages, and message handling attributes. This field, denoted as TP-Data-Coding-Scheme (TP-DCS), appears in key TPDUs such as SMS-DELIVER, SMS-SUBMIT, and SMS-STATUS-REPORT, providing essential for message interpretation without requiring prior between sending and receiving entities. The primary purpose of DCS is to enable receiving devices, such as mobile stations (), to correctly decode and render message content, supporting features like multilingual text display and specific delivery behaviors, including message classes and compression status. By indicating the alphabet used—such as the GSM 7-bit default or UCS2—it ensures accurate processing of diverse data types, from to content, while facilitating in heterogeneous networks. This mechanism also allows for enhanced functionalities, such as immediate display for messages or storage for normal ones, optimizing across global mobile systems. Introduced in the standard (now 3GPP TS 23.038) for alphabets and data coding during the 1990s by the (ETSI), with the TP-DCS field specified in the contemporaneous standard, DCS addressed the need for standardized handling as mobile networks expanded internationally. Over time, it evolved to accommodate globalization demands, incorporating support for additional encodings and features such as the Enhanced Messaging Service (EMS), initially introduced in 3GPP Release 99 with enhancements in Releases 4 and 5, while preserving with early implementations. Key benefits of DCS include promoting seamless between diverse devices and carriers, thereby reducing errors like garbled text from encoding mismatches, and enabling efficient resource use through options like data . These attributes have been instrumental in the widespread adoption of , supporting billions of daily messages worldwide by ensuring reliable, context-aware delivery.

Bit Structure and Encoding

The Data Coding Scheme (DCS) is an 8-bit field used in Short Message Service () protocols to specify the encoding and handling attributes of the message user data. The octet is structured with bits numbered 7 (most significant) to 0 (least significant), where bits 7 to 4 define the primary coding group, and bits 3 to 0 provide group-specific details such as character set, message class, or indications. This division allows for up to 16 possible values in the default coding group (hexadecimal 00 to 0F), with higher ranges reserved for specialized or extended encodings. In the default coding group (bits 7 to 6 set to 00), bit 5 indicates whether is applied (0 for uncompressed, 1 for compressed), bit 4 signals the presence of a (0 for absent, 1 for present), bits 3 to 2 specify the character set encoding (00 for 7-bit default , 01 for 8-bit , 10 for UCS2 16-bit, 11 reserved), and bits 1 to 0 denote the when bit 4 is 1 (00 for 0, 01 for 1 ME-specific, 10 for 2 SIM-specific, 11 for 3 TE-specific). Bit 7 serves as a high-level group indicator (0 for general or default groups, 1 for extended groups like message waiting indications), while bits 6 to 4 further delineate subgroups within those categories, such as 000 for basic 7-bit, 001 for 8-bit binary, or 010 for UCS2. For groups like message waiting indication (bits 7 to 4 as 1100 or 1101), bits 3 to 0 shift to indication status and type (e.g., bit 3 for active/inactive, bits 1 to 0 for , , , or other). The encoding rules combine these bits to form standardized values, ensuring compatibility across implementations; for instance, values 00 to 0F ( 0000xxxx) exclusively use the general coding structure, defaulting to the 7-bit alphabet if unspecified. Reserved ranges (e.g., bits 7 to 4 as 1000 to 1011 or 1111 with specific sub-bits) allow for future extensions or alternative codings like UCS2-based indications, but receiving devices treat undefined values by falling back to the default 7-bit encoding. A common example is DCS value 0x00 ( 00000000), which denotes uncompressed using the 7-bit default alphabet with no message class or additional indications.
Coding Group (Bits 7-4)Bit 5 MeaningBit 4 MeaningBits 3-2 MeaningBits 1-0 MeaningExample Hex Value
00xx (General )Compression (0/1)Class present (0/1)Character set (00= 7-bit, 01=8-bit, 10=UCS2)Class (if bit 4=1: 00=Class 0, etc.)0x00 ( 7-bit, no class)
01xx (Auto Deletion)Same as 00xxSame as 00xxSame as 00xxSame as 00xx0x45 (8-bit, Class 1)
1100 (MWI Discard)N/AN/AIndication active (0/1, bit 3)Type (00=, etc.)0xC0 (Inactive voicemail)
1101 (MWI Store, 7-bit)N/AN/ASame as 1100Same as 11000xD9 (Active )
1110 (MWI Store, UCS2)N/AN/ASame as 1100Same as 11000xEA (Active )
1111 (/Class)N/AN/AReserved (0, bit 3)Class (00=Class 0, 01=Class 1, 10=Class 2, 11=Class 3)0xF0 ( 7-bit, Class 0)
This table illustrates the bit allocations for key groups, highlighting how the structure supports varied encoding without overlapping functionalities.

Character Sets and Message Classes

Supported Character Sets

The Data Coding Scheme (DCS) specifies multiple options to accommodate diverse text representations in short services, primarily through bit combinations in an 8-bit field that indicate the or used for the user data. These encodings balance efficiency, capacity, and multilingual support, with selections made via bits 3 and 2 in the general coding group (bits 7-4 set to 0000). The 7-bit default alphabet serves as the primary encoding for text , supporting a 128-character set optimized for Western European languages, including basic Latin letters, digits, and common symbols such as and signs. Characters are packed into 7-bit units within 8-bit octets, allowing a maximum of 160 characters per short message while maintaining compatibility across networks; an extension table enables access to additional symbols like curly braces, but each use reduces the effective displayable characters by one due to the escape mechanism. This encoding is mandatory for all mobile stations () and service centers (). For non-textual content, the 8-bit binary or data coding treats the message as an unstructured octet stream, suitable for applications like downloads, operator logos, or other payloads, with a capacity of up to 140 octets per message. This scheme provides flexibility for user-defined data without imposing a specific interpretation, though it requires explicit handling by receiving devices. UCS2, a 16-bit encoding based on the standard, enables support for a broader range of international scripts, including non-Latin languages such as , Hebrew, , and , by representing each character with two octets. This results in a reduced capacity of 70 characters per message but facilitates global interoperability for multilingual content. UCS2 is selected when bits 3-2 are set to 10 in the general coding group. Reserved coding combinations, particularly when bits 3-2 are set to 11 in the general group, default to the 7-bit alphabet for , ensuring that unsupported schemes do not disrupt basic text transmission. For national language variants, such as Turkish or , the DCS incorporates shift mechanisms within the 7-bit encoding: single-shift tables add specific characters to the default alphabet, while locking-shift replaces it entirely with a language-specific set using escape characters (e.g., 0x1B for single shift, 0x1D for locking shift). In practice, national language variants such as Turkish or are supported by invoking language-specific single-shift or locking-shift tables via escape characters within the 7-bit default alphabet, allowing addition or replacement of characters without changing the DCS coding group. These features address regional character needs without requiring full overhead. The specification has evolved through multiple 3GPP releases, with the latest version 19.0.0 (October 2025, Release 19) maintaining core character set definitions while incorporating updates to language-specific information as needed.
Coding Group (Bits 7-4)Bits 3-2 Character SetDescription
0000 (General)00GSM 7-bit default alphabet
0000 (General)018-bit binary/data
0000 (General)10UCS2 (16-bit Unicode)
0000 (General)11Reserved (defaults to GSM 7-bit)
National language variants (e.g., Turkish, ) use locking/single-shift tables invoked via escape characters in 7-bit messages, without dedicated coding groups.

Message Class Types

The Data Coding Scheme (DCS) in SMS messaging categorizes messages into four distinct classes to determine their handling, storage, and presentation by the receiving device. These classes are indicated within the TP-DCS octet, allowing the (SMSC) or originating entity to specify how the message should be processed upon delivery. Message classes are encoded using bits 1 and 0 of the DCS octet when bit 4 is set to 1 (indicating a class is present), with bits 3-2 reserved (set to 00 by sender), within coding group 0000 (bits 7-4 = 0000) for uncompressed text. The encoding overrides any default behavior, with the following bit patterns for bits 1-0: 00 for Class 0, 01 for Class 1, 10 for Class 2, and 11 for Class 3. This mechanism ensures compatibility across different message alphabets while prioritizing the specified storage and display rules.
ClassBit Pattern (Bits 1-0)DescriptionStorage and Handling
000Immediate display (flash message)Displayed directly on the device screen without user interaction; not stored in any memory.
101Mobile Equipment (ME)-specificStored in the device's ME memory; accessible via the and potentially the if configured.
210-specificStored exclusively on the or USIM card; not accessible through the standard user interface.
311Terminal Equipment (TE)-specificForwarded to an external , such as a connected computer or peripheral, for storage and processing.
Class 0 messages are typically used for urgent, transient notifications like network alerts or emergency broadcasts, where immediate visibility is critical but persistence is unnecessary. 1 serves as the default for standard user-to-user exchanges, enabling typical storage and retrieval in the device's message inbox. 2 is reserved for toolkit applications, such as downloading configuration data or applets that interact directly with the SIM for services like or operator provisioning. 3 facilitates integration with external systems, often in or scenarios where messages need to be routed beyond the . These classes integrate with the selected character set in the DCS to ensure proper decoding before applying the handling rules. The message class framework was originally defined in and has been carried forward without alteration in subsequent releases, including those supporting Non-Stand Alone (NSA) and Stand Alone (SA) architectures via over IP.

Indication and Control Features

Message Waiting Indication

Message Waiting Indication (MWI) is a feature within the Data Coding Scheme (DCS) that enables short message service centers to notify mobile devices of pending messages, such as voicemails or faxes, through dedicated messages. This mechanism uses specific DCS values to signal the presence or absence of waiting messages, allowing the receiving mobile equipment (ME) to display appropriate indicators like icons or play alert sounds without delivering full message content. Introduced as part of the specification in its version 5.1.0 released in March 1996, MWI has been a standard component of protocols for legacy circuit-switched networks. The DCS octet for MWI belongs to the indication group, where bits 7 to 4 are set to 1100 for discard mode (message processed but not stored) or 1101 for store mode (message stored in 7-bit alphabet, with an additional 1110 option for UCS2 storage). Bit 3 indicates the sense (1 for active/waiting, 0 for inactive/no waiting), bit 2 is (set to 0), and bits 1 to 0 specify the type: 00 for message waiting, 01 for , 10 for electronic , or 11 for other. For the "other" category, up to 14 additional subtypes can be distinguished via associated /USIM storage records (EF_MWIS), enabling support for diverse services like short message waiting or alerts. Upon receipt, the ME interprets the DCS to update the device's visual or audible indicators and stores the status in the /USIM's Message Waiting Indication Status (MWIS) elementary file, regardless of available memory; the originating address may also be retained if supported. For specifically, the basic DCS MWI sets the active/inactive flag, while new and deleted message counters are updated via separate messages employing the Special SMS Message Indication in the user data field, which conveys numerical counts and timestamps. This layered approach allows precise status reporting without overloading the core indication . The receiving device acknowledges MWI irrespective of storage capacity, ensuring reliable delivery of alerts. Although widely implemented in and networks, MWI support is not universal, as it remains an optional feature dependent on network operator and device capabilities. In modern IP-based messaging systems like (RCS), which leverage the , traditional SMS-based MWI has been largely supplanted by SIP-based protocols defined in TS 24.606 since Release 7 (2006), with ongoing enhancements through 2023 standards favoring push notifications and integrated indicators over DCS signaling.

Automatic Deletion Mechanisms

In the SMS Data Coding Scheme, the automatic deletion mechanism allows the short message (SM) originator to mark messages for automatic removal from the mobile equipment (ME) or universal subscriber identity module ((U)SIM) after the recipient has read them. This ensures temporary storage without permanent retention, enhancing or storage management in mobile networks. It was introduced in Release 4 via change request TP-000074 to support automatic removal of read SMS messages. The mechanism is encoded in the TP-Data-Coding-Scheme (TP-DCS) field of the (TPDU), where bits 7-4 are set to 01xx (coding group for messages marked for automatic deletion), with bits 5-0 following the same coding as the general data coding group (00xx), defining elements like character set, data compression, and message class. This coding applies irrespective of the message class, ensuring consistent behavior across SMS types stored in the ME or (U). Upon delivery and reading, the receiving ME must delete the message without intervention from the end user or any targeted application, with the deletion process being manufacturer-specific. Mobile equipment manufacturers may optionally implement a user-accessible setting to prevent this automatic deletion, allowing recipients to retain flagged messages if needed. Unlike SMS, the Cell Broadcast Service (CBS) Data Coding Scheme does not include an equivalent automatic deletion group, as CBS messages are transient broadcasts without individual storage semantics. The bit structure for the TP-DCS field in the automatic deletion group is as follows:
BitsFunctionValues
7-4Coding Group01xx (Message marked for automatic deletion)
5Data Compression0 = Uncompressed; 1 = Compressed (per TS 23.042)
4Message Class Indication0 = No message class; 1 = Message class present (bits 1-0 used)
3-2Character Set / Indication00 = GSM 7-bit default alphabet; 01 = 8-bit data; 10 = UCS2 (16-bit); 11 = Reserved
1-0Message Class (if bit 4=1)00 = Class 0 (immediate display); 01 = Class 1 (ME-specific); 10 = Class 2 ((U)SIM-specific); 11 = Class 3 (TE-specific)
This structure maintains compatibility with standard SMS encoding while adding the deletion flag.

Advanced Features

Data Compression Options

The Data Coding Scheme (DCS) incorporates compression to optimize message efficiency, primarily for text-based content in and related services. In the General Data Coding group (bits 7-4=00xx), bit 5 set to 1 indicates that the consists of compressed 7-bit, 8-bit, or UCS2 data, signaling the receiving device to apply using the specified algorithm. This flag ensures compatibility with character sets like UCS2, which are eligible for compression to mitigate their higher bit requirements compared to 7-bit encoding. For example, compressed UCS2 without message class uses DCS=0x28. The standardized compression method relies on a scheme, which assigns shorter variable-length bit sequences to more frequent characters, achieving efficient reduction in payload size. Additional optional mechanisms include character group transitions (SEGS) for handling language-specific sets and dynamic tree updates via techniques like weight swapping () to adapt to message content without initial training. For UCS2 data, the algorithm optimizes by signaling row changes only when necessary, effectively reducing the average encoding from 16 bits per character to approximately 10 bits per character in typical scenarios. This directly impacts message capacity within the 140-octet of the TP-User Data (TP-UD) field for a single SMS segment, allocating up to 133 octets for the compressed payload after 7 octets of overhead for the compression header and footer. Consequently, compressed UCS2 messages can accommodate approximately 100-110 characters in typical scenarios, an increase over the uncompressed of 70 characters depending on text compressibility. Despite these benefits, adoption of DCS compression remains limited, as it is an optional requiring consistent across networks and devices, which has proven complex due to variable decompression needs. Usage has further declined post-2010 with the proliferation of and alternatives that natively support extended message lengths without such optimizations.

User-Defined Extensions

The Data Coding Scheme (DCS) octet in and messages allocates certain values as reserved, enabling vendors and network operators to implement proprietary or user-defined extensions for custom features. According to TS 23.038, reserved coding groups (e.g., bits 7-4=10xx) are treated by receiving entities as the General Data Coding group (00xx) for fallback , while 8-bit data coding inherently allows user-defined payloads. Specific bit combinations marked as reserved support implementations like over-the-air () configuration messages or hints for enhanced content handling, provided they adhere to fallback behaviors such as defaulting to 7-bit encoding. Mobile stations (MS) must store messages with reserved or unsupported DCS values without attempting to interpret them, treating them as opaque data, while service centers () are permitted to reject such messages to maintain network integrity. This design supports innovation in vendor-specific applications, such as proprietary signaling for device configurations, but the standard explicitly discourages overuse of reserved values to prevent fragmentation. Interoperability risks arise when devices lack support for custom schemes, potentially leading to message loss or incorrect rendering; thus, guidelines recommend defaulting to the GSM 7-bit alphabet (DCS 0x00) for broad compatibility. For instance, in binary SMS formats common for OTA settings, 8-bit coding (e.g., DCS=0x04 or 0xF6 for class 2) may signal vendor-specific protocols, ensuring delivery to class-specific storage (e.g., for class 2) if the recipient recognizes them.

Specific Implementations

SMS Data Coding Scheme

The SMS Data Coding Scheme (DCS) plays a central role in the Short Message Service () by specifying the encoding, alphabet, and handling instructions for the user data within short messages. In the SMS protocol, the TP-DCS (TP-Data-Coding-Scheme) field, an optional 8-bit parameter in the Transfer Protocol Data Unit (TPDU), carries this scheme and informs the receiving entity how to interpret the TP-UD (TP-User Data) field. This field determines the length of the user data and the packing method applied, ensuring compatibility between sender and receiver in terms of character representation and message processing. The TP-DCS directly influences the maximum allowable user data length in SMS messages. For the GSM 7-bit default alphabet, messages support up to 160 characters, packed into 140 octets to optimize bandwidth on / networks. In contrast, 8-bit data coding allows up to 140 octets of , suitable for non-text applications, while UCS2 (16-bit) coding limits messages to 70 characters, occupying 140 octets due to the doubled byte size per character. These limits apply to single-part messages and guide the segmentation in multi-part transmissions. During message submission, the originating (MS) or application sets the TP-DCS value in the TPDU before forwarding it to the (SMSC) via the mobile-originated (MO) procedure. The SMSC stores the message and, upon delivery to the destination MS, includes the unchanged TP-DCS in the SMS-DELIVER TPDU, enabling the receiving MS to decode the user data accordingly. For concatenated long messages exceeding single-part limits, each segment carries the same TP-DCS value, with concatenation information provided in the (UDH) to reassemble the full message at the receiver. This uniform DCS application across parts ensures consistent decoding. The core specifications for SMS DCS are outlined in 3GPP TS 23.040, with version 18.0.0 (released May 2024) incorporating enhancements for modern networks. Notably, this includes support for SMS delivery over the Non-Access Stratum () protocol, extending DCS applicability to IP-based and New Radio (NR) environments while maintaining with earlier releases. These updates address evolving requirements for SMS in diverse access technologies without altering the fundamental TP-DCS mechanics.

CBS Data Coding Scheme

The Cell Broadcast Service (CBS) utilizes the Data Coding Scheme (DCS) as a one-octet field in the message header to specify the character set, coding method, and for broadcast messages delivered simultaneously to all stations within a geographic or group of cells. This enables efficient, unacknowledged dissemination of short text content, such as public announcements or alerts, without the point-to-point delivery model of . In CBS, the DCS is positioned at octet 5 in the format or octet 6 in , , and formats, directly influencing how receiving devices decode and display the message. Like , DCS supports 7-bit default alphabet, 8-bit data, and UCS2 (16-bit ) encodings, though it excludes certain SMS-specific features such as message classes and user indications in most groups to optimize for broadcast efficiency. This focuses on text-based and content with a fixed structure: each page consists of 82 octets, accommodating up to 93 characters in 7-bit mode, up to 82 octets in 8-bit mode, or 41 characters in UCS2, with messages spanning up to 15 pages for a total of 1,230 octets. The DCS bits 7-4 denote the group (e.g., 0000 for general ), while bits 3-0 indicate or handling, such as 0000 for or 1111 for unspecified, ensuring appropriate rendering without interactive features like acknowledgments or deletions. For example, DCS value 0x00 (binary 00000000) specifies 7-bit default alphabet in , commonly used for warning messages in regions requiring that . The DCS plays a critical role in emergency alert systems integrated with , such as the Earthquake and Tsunami Warning System (ETWS), where it defines coding for primary and secondary notifications to ensure rapid, language-appropriate delivery without device-specific filtering for mandatory alerts. This is standardized in 3GPP TS 23.041 (version 18.7.0, October 2025) for architecture and TS 23.038 (version 18.0.0, May 2024) for DCS details, with implementations in the U.S. Commercial Mobile Alert System (CMAS) and Europe's relying on these schemes for geo-targeted warnings using predefined message identifiers (e.g., 4370-4371 for ETWS). In networks, Release 18 (as of 2025) builds on Release 17's evolved Public Warning System (ePWS) to enhance DCS support for language-independent content, such as Unicode pictograms, while multimedia broadcasting is addressed separately through Multicast-Broadcast services rather than extending traditional text limits.

References

  1. [1]
    SMS and CBS Data Coding Scheme - inside TS 23.038 - Tech-invite
    The TP-Data-Coding-Scheme field, defined in TS 23.040, indicates the data coding scheme of the TP-UD field, and may indicate a message class.
  2. [2]
    Data Coding Scheme - OpenMarket
    In SMPP, the data coding scheme (DCS) indicates information that includes (but isn't restricted to) the character set that the message text is in.Missing: definition | Show results with:definition
  3. [3]
    Overview of data coding schemes - Alaris Labs
    The data coding scheme (DCS) indicates information that includes the character set that the message text is encoded in.Missing: definition | Show results with:definition
  4. [4]
    [PDF] GSM 03.40 - ETSI
    GSM 03.40 is a technical specification for the Short Message Service (SMS) within the Global System for Mobile communications (GSM).
  5. [5]
    [PDF] ETSI TS 123 038 V10.0.0 (2011-03)
    SMS Data Coding Scheme. The TP-Data-Coding-Scheme field, defined in 3GPP TS 23.040 [4], indicates the data coding scheme of the TP-UD field, and may indicate ...
  6. [6]
    None
    Summary of each segment:
  7. [7]
    [PDF] ETSI TS 123 040 V16.0.0 (2020-07)
    ETSI TS 123 040 is a technical specification for the Short Message Service (SMS) in digital cellular systems like GSM, UMTS, LTE, and 5G.
  8. [8]
    [PDF] GSM 03.40 - ETSI
    GSM 03.40 Version 5.1.0: March 1996​​ If you have comments concerning its accuracy, please write to "ETSI Editing and Committee Support Dept." at the address ...
  9. [9]
    [PDF] CHANGE REQUEST 6.3.0 - 3GPP
    This CR allows voice mail systems to convey via SMS to the user enhanced information regarding voice mail messages and voice mail box status such as a list of ...
  10. [10]
    [PDF] ETSI TS 123 040 V12.2.0 (2014-10)
    This information shall be stored by the ME in the Message Waiting Indication Status on the SIM (see 3GPP TS 51.011 ... SMS User Data: This is a message with two ...
  11. [11]
    [PDF] ETSI TS 124 606 V18.0.0 (2024-05)
    The present document can be downloaded from: https://www.etsi.org/standards-search. The present document may be made available in electronic versions and/or ...
  12. [12]
    Specification # 24.606 - 3GPP
    Nov 9, 2020 · Reference: 24.606. Title: Message Waiting Indication (MWI) using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification.
  13. [13]
    [PDF] ETSI TS 123 042 V17.0.0 (2022-04)
    Compression is achieved by assigning a 1:1 mapping between the characters in the base group and those in the other groups and when appropriate signalling a ...
  14. [14]
    None
    Below is a merged summary of the SMS compression capacity impact based on ETSI TS 123 040 V18.0.0, consolidating all provided segments into a single, dense response. To maximize clarity and detail, I’ve organized the information into tables where appropriate, followed by a narrative summary. All relevant details, including maximum lengths, comparisons to uncompressed SMS, and useful URLs, are retained.
  15. [15]
    [PDF] Secure Text Communication for the Tiger XS - DiVA portal
    Dec 14, 2006 · Though no evidence of it is presented here, there appears to be little or no adoption of the standard for SMS compression on behalf of the.
  16. [16]
    [PDF] ETSI TS 123 041 V17.4.0 (2022-06)
    3GPP TS 23.041 version 17.4.0 Release 17. UE. LTE-Uu. eNodeB. S1 ... The warning messages use the coding scheme for CBS data specified in 3GPP TS 23.038 [3].
  17. [17]
    [PDF] ETSI TS 123 038 V18.0.0 (2024-05) - iTeh Standards
    ETSI TS 123 038 V18.0.0 (2024-05). 9. 3GPP TS 23.038 version 18.0.0 Release 18. Coding Group Bits. 7..4. Use of bits 3..0. 00xx. General Data Coding indication.