Cdma sms pdu Decoding

This was learned in others' blogs when I solved the bug of sending a report via SMS on andorid. The description is very meticulous, after reading it carefully, you can solve the sms pdu format of CDMA by yourself. In addition, the original author also distinguished the byte by color, which is great.

[Stick to no color, cup, original link: http://blog.lytsing.org/archives/180.html]

The PDU format of CDMA differs greatly from that of GSM. The first content is relatively long. Take the second PDU string for analysis.
1. First, compress the PDU string into a PDU package.
Concatenates two adjacent ASCII characters of a PDU string into an 8-bit data.

As follows:
00 00 02 10 02 07 02 C5 4C E2 25 A8 06 01 4C 08 4D 00 03 10 01 F8 01 3E 20 F0 01 90 01 78 01 90 01 62 DF ca 70 04 b1 AC B1 AB B4 23 96 14 C6 70 01 62 96 3B 2B 12 B9 82 7A E3 10 C0 01 72 9f 54 4C 0b 10 8B B4 23 91 8A 75 D0 01 63 31 7A 70 02 9f 52 E0 7C F0 F8 03 06 08 12 29 19 26 16

Message transmission type: 0 × 00 Point to Point message (point-to-point message)

The following content is the fields of short messages. Each field is divided into three parts: Field Type (ID)(8bit), Field Length (Length)(8bit) And field content.

First field:00 02 10 02
0 × 00, indicating the uteleserviceid Field
0 × 02, field length. The length must be 2; otherwise, it is the incorrect PDU information.

Field content: 0x1002, decimal: 4098,

Second Field:02 07 02 C5 4C E2 25 A8 A8
0 × 02, sms_tl_orig_addr (SMS Sending address)
0 × 07, the field length is 7
Field content: 02 C5 4C E2 25 A8 A8
Let's just look at the previous 02 C5 4C E2:
0000 0010 1100 0101 0100 1100 1110 0010
The first bit 0 indicates that ril_cdma _sms_digit_mode_4_bit is 4 bit compressed.
The second bit 0 indicates ril_cdma _sms_number_mode_not_data_network.
The next 8 bits are 00 0010 11 = 11, indicating the number length is 11
Because it is 4-bit compressed, the last 44 bits (4*11) indicate the number, and the resolution is 15338896020.

Third Field:06 01 4C
Sms_tl_bearer_rply_opt

Fourth field:08 4D 00 03 10 01 F8 01 3E 20 F0 01 90 01 78 01 90 01 62 DF ca 70 04 B1 AC B1 AB B4 23 96 14 C6 70 01 62 96 3B 2B 12 B9 82 7A E3 10 C0 01 72 9f 54 4C 0b 10 8B B4 23 91 8A 75 D0 01 63 31 7A 70 02 9f 52 E0 7C F0 F8 03 06 08 12 29 19 26 16

0 × 08, indicating the sms_tl_bearer_data field (SMS content)
0x4d, the field length is 77

This field is also divided into sub-fields:

First child Field:00 03 10 01 F8
0 × 00 mesage ID
0 × 03 Content Length
10 01 F8 = 0001 0000 0000 0001 1111
0001 indicates deliver SMS
0000 0000 0001 1111 indicates the Message ID.
Followed by 1, indicating header_ind

Second Child field:01 3E 20 F0 01 90 01 78 01 90 01 62 DF ca 70 04 B1 AC B1 AB B4 23 96 14 C6 70 01 62 96 3B 2B 12 B9 82 7A E3 10 C0 01 72 9f 54 4C 0b 10 8B B4 23 91 8A 75 D0 01 63 31 7A 70 02 9f 52 E0 7C F0 F8
0 × 01, Field Type
0x3e (62), Field Length
20 F0 01 = 0010 0000 1111 0000 0000
The first five bits of 0x20 are 00100, 0x04, indicating that the SMS encoding method is ril_cdma _sms_encoding_unicode (UNICODE)
The last 3 bits of 0 × 20, the first 5 bits of 0xf0, Which is 1111 0, that is, 0x1e (30), indicates that there are 30 Unicode characters. The last three bits of 0xf0, the eight bits of 0x01, and the first five bits of 0x90,

0000 0000 0011 0010 a 16-digit combination is 0 × 0032 represents character: 2. In vim, it is very easy to understand the hexadecimal code of a character, the result is as follows:

<2> 50, Hex 32, octal 062, 1 All

In turn, the content is the result of running./test_pdu_decode above: 2/2, fighting against a burst of storms. As long as my lover is a bird

Third Child field: 03 06 08 12 29 19 26 16

This is a timestamp field: December 29 (short message sending time)

String analysis ends. Of course, there are still many options not included in this text message. For more complete SMS format, see cdma sms standard on Alibaba PP2 website.

During actual encoding, a while loop traversal, coupled with a simple switch state machine, is required.

What about long text messages?

This module does not support long text messages. The manufacturer replied, "The user data header is removed after preprocessing, because the customer generally does not want to process the user data header by themselves, they only need content, numbers, and other information. Therefore, the PDU sent by the module does not contain the user data header ."

to split and combine long messages, the terminal must support the header_ind parameter for long message processing in the is637c protocol, in addition, the user data subparameter parameter is added to the short message data to process user data headers and text message splitting and combination. Header_ind indicates whether the user data header contains a message header. If the header contains a message, header_ind is set to '1'; otherwise, it is set to '0 '. For details about splitting and combination, refer to is637c or China Telecom CDMA Terminal demand specification-SMS sub-book-V1.0. It should be noted that some CDMA module manufacturers help you deal with user data headers in order to save the trouble for users, and add (1/2) automatically ), (2/2). If you want to manually resolve the issue, you must communicate with the module manufacturer to confirm it.