首先感谢下面各位博主的文章，CDMA短信的解析我就是从下面开始的，下面这些文章对CDMA短信的解析已经有了比较详细的介绍。我这里只是介绍一些自己的经验和所得，有自己认为比较重要的地方做了一些补充，希望对大家有所帮助。
https://blog.csdn.net/zx249388847/article/details/52607862
https://blog.csdn.net/Arthur_zeng/article/details/7059783
https://blog.csdn.net/zx249388847/article/details/52623477
单条短信内容最大的长度是140字节，如果内容能够采用7bit ASCII编码，那么可以传输的内容长度是140X8/7=160。如果发送的内容长度超过160，需要将短信拆分成多条短信，那么拆分后的短信需要一个header来描述总共有几条，这是第几条短信等内容，140X8=160X7=134X8+6X8=153X7+7X7，也就是如果7bit编码，那么这条短信能够存储153个字符。如果发送的字符超过160，假如是161，那么将会拆分成两条短信，153+8，一条发送153个字符，另一条只发送8个字符。
假如我们需要发送一条短信给某一个人，基本流程是发送方编辑一条短信点击发送，这条短信会submit到短信中心，短信中心会将该条短信delivery到接收端，接收端收到短信中心的短信后，会acknowledge短信中心，已经收到这条短信了。这个过程其实发送端并不清楚接收方到底有没有收到短信。如果发送端希望知道短信到底有没有抵达接收端，那么发送的时候可以带一个信息给短信中心delivery report，告知短信中心我希望接收端如果收到短信了，请将这个信息通知我，如果没有收到，也请告诉我原因。那么短信中心将短信delivery给接收端后，接收端acknowledge短信中心，短信中心这个时候就知道短信已经抵达接收端，再通知发送端短信已经送到了接收端。这基本上就是短信发送接收的一个最简单的抽象了。另外还有一种小区广播短信（cell broadcast）这种短信在国内应该不支持，如果发生地震，火灾等灾害的时候，终端会收到这种短信，只是内容上和普通通信有些区别，但是解析过程和普通短信是一样。
在正式解析PDU之前，还请了解编码的基本知识，了解8bit，7bit，Unicode，utf-8，DTMF编码和解码。
我先列举出几个CDMA SMS的PDU（下面短信中没有涉及到长短信和Unicode的短信，在解释这几个后，会专门对长短信进行讲解）
//发送的短信
0000021002040702c620468c8e90060100081000032000200106102c8cbb366f0a0140
//接收到的短信
0000021002020702c620468c8e90060170081c0003400020010a20229e8c800b108294f80306190723112417140102
// acknowledge的短信（收到短信后，需要ACK短信中心，告知短信中心我收到了）
02040702c620468c8e90070198
// cell broadcast
0101020004081300031008d00106102c2870e1420801c00c01c0
当我首次看到上面四个短信PDU后，一脸茫然，不知所措，感觉好难。后面随着学习的深入，按照3GPP2 SMS的spec就能一步一步的揭开PDU的面纱，看看里面到底隐藏着什么内容。仔细观察一下这四个PDU，开头是不一样的，有00，01，02，这就是message type，标明这是一条什么类型的短信。不同的短信，内容上就有些差别。但是解析过程是一样的。下面就是message type的定义，短信PDU都是以message type开始的。
无论是哪种type的message，format都是一样的，
Message type之后就是多个固定结构，id，length，data，id描述了数据类型，length描述的是data的长度。我们对发送的短信和cell broadcast进行format拆分，拆分之后对每个id，length，data分析就简单了。另外两条大家可以做一下同步练习。其中data的结构可能也是按照id，length，data的结构进行组合的。也就是说data可能是一种复合结构。
三种message type包含的内容不同，Point to Point最为复杂，而broadcast和acknowledge message都非常简单。
各种Parameter Identifiers的定义如下，根据parameter id，在spec中找到对应的部分，根据spec就可以解析出data的内容。有些data内容包含多个信息，并且信息长度不能被4整除，需要将data转换为二进制处理就简单了.
先以发送的短信作为例子进行解析
0000021002040702c620468c8e90060100081000032000200106102c8cbb366f0a0140
我们把这个按照parameter id进行拆分成，对每一段分别进行解析。
00// message type (point-to-point)
00021002 //把00021002 id，length和data标成不同颜色00021002，一般情况id和length都是8bit，id = 00(16进制) = 00000000（二进制），在parameter identifiers table表里找到00000000对应的id，也就是Teleservice Identifier，在spec中可以继续搜索00000000或者Teleservice Identifier，找到后有详细的解释Teleservice Identifier的结构如何。这个结构比较简单，就不详细说了。
040702c620468c8e90//按照上面方法标成不同的颜色040702c620468c8e90，id = 04 = 00000100，在parameter identifiers table里找到00000100是Destination Address，在spec里面搜索00000100或者Destination Address，找到的是Address Parameters，Destination Address和Originating Address有同样的结构，如下表，这是一个变长的结构，需要读一下spec，每个item代表的含义。040702c620468c8e90 // 04 就是id，07是长度
040702c620468c8e90 //接下来就是Digit mode和number mode，都是一个bit，0 = 0000，所以Digit mode和number mode都是0，Digit mode = 0说明采用DTMF格式编码，如果等于1表示的是采用8 bit编码，number mode具体表示还需要查其他的spec（email类型的地址会应用到），感兴趣的可以自行查阅。根据spec ，Digit mode和number mode都是0，那么number type和number plan都不存在。下一个是NUM_FIELDS，长度是8 bit，由于Digit mode和number mode已经占用了两个bits，这个时候我们将 02c620468c8e90 全部转化为二进制就容易解析了。
00001011就是NUM_FIELDS，等于11。后面就是CHARi，CHARi可能是4bit或者8bit，由于Digit mode = 0，采用DTMF编码，采用4 bit编码，一共是11个数字，每个DTMF对应的数字可以参考下表，最终number是18811032304，最后留下两个 bit 是reserved。到此Destination Address就解析完了，是不是很简单。
060100// 按照同样的方法将不同不同表示成不同颜色060100，id = 06 = 00000110，parameter identifiers table里找到00000110，对应的是Bearer Reply Option，定义如下，06是id，01是长度，00 = 000000 00，REPLY_SEQ是000000，两个bit是reserved的。
081000032000200106102c8cbb366f0a0140 // 这部分是重点了，仍然用同样方法表示成不同颜色081000032000200106102c8cbb366f0a0140，id=08=00001000，在Parameter Identifier table中找到00001000是Bearer Data，搜索spec，发现了什么，Bearer Data是一个复合结构，Bearer data的sub data也是id，length，data的结构，这个bear data的length = 10 = 16，data就是00032000200106102c8cbb366f0a0140。我们先给这个标上颜色，可以看到有三个sub data。Bearer data 的sub data的id有单独的定义，也就是bearer data sub id的值定义上和parameter identifier table是没有任何关系的，一定不要混淆，他们不在同一layer上。
00032000200106102c8cbb366f0a0140
每种短信的bearer data的sub parameter是有很大的区别的，含有的内容有很大的差异，在此就不一一列举每种短信的bearer data的内容了，只列出bearer data的sub parameter table，根据这个table和对应的spec就可以解析任意短信的bearer data了。
我们继续拿00032000200106102c8cbb366f0a0140作为例子说明
0003200020 //解析方法还是一样的，id = 00 = 00000000，在上表中查到是Message Identifier，找到对应的spec，如下ID=00，length=03，message type是4个bit就是2=0010，Message ID占用了16个bit，就是0002，还剩下最后一个0=0000，Header_IND=0（占一个bit），剩下的3个bit是reserved。继续对每个item进行解释。Message type = 0010标明的是message type，每个值的意思见表，0010是submit，MO的，符合我们的期望，因为这就是一条发送的短信。MESSAGE_ID=0002这个非常有用（后面会见识到），message identifier。HEADER_IND等于1标明的是user data sub-parameter (00000001) 是有header的，等于0是user data sub-parameter没有header。这里等于0，就是没有header。对于长短信（>160）都需要user data sub-parameter含有header，来说明这是长短息的第几条。对于长短信我们会再单独介绍。
Message Identifier
0106102c8cbb366f// id=01 = 00000001，这个就是user data sub-parameter，找到对应的spec，length=06，MSG_ENCODING占用了5个bit，在此我们将后面的数据全部转为2进制。
MSG_ENCODING = 00010(这个代表是7 bit ASCII编码) ，message type没有占用bit，NUM_FIELDS=00000101=5，也就是有5个CHARi，每个7 bit，1001000（0x48,’H’）， 1100101(0x65,’e’), 1101100(0x6C,’l’), 1101100(0x6C,’l’), 1101111(0x6F,’’o) ，内容就是”Hello”，这个就是发送给18811032304的内容。RESERVERED的bit正好没有。
0a0140//还是标成不同颜色0a0140，id=0a=00001010，也就是Reply Option，spec如下，长度是01，后面的数据是按bit的，所以40=01000000，那么USER_ACK_REQ =0, DAK_REQ=1, READ_ACK_REQ=0, REPORT_REQ=0, RESERVERD=0000, DAK_REQ=1说明的是发送的短信需要知道发送的短信有没有送到对应的号码，短信中心需要把这个信息回给发送方，发送方最终看到的UI界面就是status report。
发送短信的PDU整个就解析完毕，总结一下，基本上就是拿到PDU后，先把PDU按内容拆分，之后对每一部分按照spec严格进行解析即可。希望这个方法对于学习和解析CDMA SMS有帮助。
下面我再按照同样的方法解析一下接收到的短信，另两条短信，大家可以作为练习，下面这条的内容是中文的。
//接收到的短信
0000021002020702c620468c8e90060170081c0003400020010a20229e8c800b108294f80306190723112417140102
先将短信按照format进行拆分，拆分的过程一定要数对length后的数据的个数，不然就会乱了。
00 //message type (point-to-point)
00021002// id = 00, length = 02, data =1002, 这是Teleservice Identifier，Identifier是1002
020702c620468c8e90//id = 02, length=07, data=02c620468c8e90 这是Originating Address,DIGIT_MODE和NUMBER_MODE都是0，编码仍然是DTMF，NUMBER_TYPE和NUMBER_PLAN没有占用bit，NUM_FIELDS=11, CHARi=18811032304, 有两个bits reserved。
060170 //id=06,length=01,data=70 这是Bearer Reply Option，REPLY_SEQ=28，ACK短信中心的时候需要这个值。
081c0003400020010a20229e8c800b108294f80306190723112417140102 // id=08，这是Bearer data，长度是1C=28, 我们接着把后面的数据再拆分，换一种颜色，和上面的layer区分开。
0003400020 //id = 00, length=03, 这是Message Identifier。MESSAGE_TYPE=4=0100，描述的是Delivery Acknowledgment (mobile-terminated only), 可以参考刚才上面的spec。这是一条短信中心回复的短信，告知发送方短信发送成功了 (这条短信其实就是上面发送短信成功后，短信中心回复的) 。MESSAGE_ID=0002，这个ID和发送短信的MESSAGE_ID是一样的。HEADER_IND=0，User data还是没有Header，3 bits是reserved.
010a20229e8c800b108294f8 //id=01，length=0a=10，这是User data，可以把20229e8c800b108294f8全部转换成2进制继续解析MSG_ENCODING=00100=4（Unicode编码），MESSAGE_TYPE 没有占用bit，NUMBER_FIELDS = 00000100=4，没有header，我们把NUMBER_FIELDS后面的数据重新4位进行组合。最终解析出来的就是“发送成功”。
03061907231124170306190723112417 //id=03=00000011,length=06，这是Message Center Time Stamp，可以在SPEC中找到对应的部分，解析后就是YEAR=19（2019） MONTH=07 DAY =23 HOURS=11 MINUTES=24 SECONDS=17，时间就是2019年7月23日11点24分17秒。
140102 // id=14 = 00010100, length=01, 这是Message Status, data = 02=00000010, ERROR_CLASS = 00 (2个bit) =0, ERROR_CLASS = 0代表没有error；MSG_STATUS_CODE=000010(6个bit) =2，MSG_STATUS_CODE=2代表没有error的情况下，Message delivered，也就是message已经送达接收端。如果有UI显示的话，发送短信设置了显示status report，那么短信中心回复这种status report后，需要进行解析，来决定显示。需要显示是否发送到短信中心，这仅代表短信已经发送到短信中心，还需要显示短信中心回复的status report，表明接收方接收到了，或者是有error发生。
对于小于160个字符的短信解析就基本结束了，大家可以用另外两个短信或者手头上有的CDMA SMS PDU来练习一下，这里只是扼要的解释了如何解析PDU，SPEC里面涉及到的内容还有很多，还需要后续工作遇到相关问题后，仔细研读SPEC。
（note：这只是我个人工作和学习的总结，可能会有纰漏或不正确的地方，在阅读的时候一定要带着怀疑的心态去阅读，结合SPEC，不然会给工作带来不必要的麻烦。）
下面是在手机端编辑了一条长短信（>160），发送过程中将长短信拆分成了两条进行发送，如下。
//第一条
0000021002040702c5cc684e698806010008950003200018018e150028001f98100a0e2c7932e6cfa34ead7b36eedfc38f2e7d3af6efe3cfa838b1e4cb9b3e8d3ab5ecdbbb7f0e3cb9f4ebdbbf8f3ea0e2c7932e6cfa34ead7b36eedfc38f2e7d3af6efe3cfa838b1e4cb9b3e8d3ab5ecdbbb7f0e3cb9f4ebdbbf8f3ea0e2c7932e6cfa34ead7b36eedfc38f2e7d3af6efe3cfa838b1e4cb9b3e8d3ab5ecdbbb7f0e3cb9f4ebdbb8
//第二条
0000021002040702c5cc684e698806010008400003200028013911f028001f981013c79f507163c997367d1a756bd9b776fe1c7973e9d7b77f1e7d41c58f265cd9f469d5af66dddbf871e5cfa75eddfc79f400
我们用第二条作为例子进行拆分解析，和第一条相比只是内容短了一些，另外和长短信无关的部分，就直接列出结果了，不再详细说明。我们先按着format进行着色
00 //message type (point-to-point)
00021002// id = 00, length = 02, data =1002, 这是Teleservice Identifier，Identifier是1002
040702c5cc684e6988//id=04=00000100, length=07, 这是Destination Address，Digit Mode = 0，Number_mode=0, 说明是DTMF编码，Number of fields=11, number=17310139062, 两个bits reserved。
0601008//id=06=00000110, length=01, 这是reply sequence number 是6个bits 0, Reserved bits是两个0.
08400003200028013911f028001f981013c79f507163c997367d1a756bd9b776fe1c7973e9d7b77f1e7d41c58f265cd9f469d5af66dddbf871e5cfa75eddfc79f400 //id=08=00001000 length=40=64, 这是Bearer data.我们将Bearer data 的sub data进行解析。
0003200028//id=00, length=03这是Message Identifier，Message Type = 2 = 0010这是submit（mobile-originated only）, message id=0002, 最后剩下一个8=1000，Header Ind=1，说明user data sub-parameter含有header，剩下3个bit是reserved。
013911f028001f981013c79f507163c997367d1a756bd9b776fe1c7973e9d7b77f1e7d41c58f265cd9f469d5af66dddbf871e5cfa75eddfc79f400 //id=01,length=57,这是User data，因为后面MSG_ENCODING占用了5个bit，我们把紧接着的部分先编码成二进制，这样子容易分析，MSG_ENCODING=00010 =2，说明是7bit ASCII编码，number fields 占用8个bit，number fields=001 1111 0=62,后面数据就是header，关于header的说明（user data header）可以看一下（User_Data_Header(https://en.wikipedia.org/wiki/User_Data_Header, Concatenated_SMS(https://en.wikipedia.org/wiki/Concatenated_SMS)）这两个的说明，后面就是6个8 bits, UDHL=00000101=5，说明后面紧跟着5个长度的数据；IEI=00,说明是长短信；IEI length=3，这个说明后面有三个8bit的数据；reference number=243,长短信各个部分该值都相等； total number=2,也就是长短信拆分成了2条；part number =2，这是长短信的第几部分，现在等于2，长短信又拆分成了两条，所以这就是最后一条。前面MSG_ENCODING=2，是7bit ASCII,数据需要补齐为7bit（用7bit的数据表示整个UDH）,这里 UDH 有 6 byte : 6 * 8 = 48 bit不能被 7 整除即不能刚好补满 7-bit编码的数据。所以这里需要 留 1 bit 补齐 7-bits 数据格式。后面都是7bit ASCII码，对应的值”xyzAbc“，这符合结果，因为测试的时候短信内容就是一直在重复”Abcdefghijklmnopqrstuvwxyz”，可以继续解析后面的内容。第一条短信大家可以作为练习。
长短信UDH的解释
• Field 1 (1 octet): Length of User Data Header, in this case 05.
• Field 2 (1 octet): Information Element Identifier, equal to 00 (Concatenated short messages, 8-bit reference number)
• Field 3 (1 octet): Length of the header, excluding the first two fields; equal to 03
• Field 4 (1 octet): 00-FF, CSMS reference number, must be same for all the SMS parts in the CSMS
• Field 5 (1 octet): 00-FF, total number of parts. The value shall remain constant for every short message which makes up the concatenated short message. If the value is zero then the receiving entity shall ignore the whole information element
• Field 6 (1 octet): 00-FF, this part’s number in the sequence. The value shall start at 1 and increment for every short message which makes up the concatenated short message. If the value is zero or greater than the value in Field 5 then the receiving entity shall ignore the whole information element. [ETSI Specification: GSM 03.40 Version 5.3.0: July 199