首先感謝下面各位博主的文章，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