超長簡訊：簡訊內容超過70個漢字，提交給閘道器時候需要分成多條，但是使用者手機接收時候是一條（sp角度，手機發送長簡訊概念一樣）。

在cmpp協議裡，CMPP-_SUBMIT訊息定義中有相應的引數配置：
TP_udhi ：0代表內容體裡不含有協議頭資訊 1代表內容含有協議頭資訊（長簡訊，push簡訊等都是在內容體上含有頭內容的,也就是說把基本引數(TP-MTI/VFP)值設定成0X51）當設定內容體包含協議頭，需要根據協議寫入相應的資訊，長簡訊協議頭有兩種：
6位協議頭格式：05 00 03 XX MM NN
byte 1 : 05, 表示剩餘協議頭的長度
byte 2 : 00, 這個值在GSM 03.40規範9.2.3.24.1中規定，表示隨後的這批超長簡訊的標識位長度為1（格式中的XX值）。
byte 3 : 03, 這個值表示剩下簡訊標識的長度
byte 4 : XX，這批簡訊的唯一標誌(被拆分的多條簡訊,此值必需一致)，事實上，SME(手機或者SP)把訊息合併完之後，就重新記錄，所以這個標誌是否唯
一併不是很 重要。
byte 5 : MM, 這批簡訊的數量。如果一個超長簡訊總共5條，這裡的值就是5。
byte 6 : NN, 這批簡訊的數量。如果當前簡訊是這批簡訊中的第一條的值是1，第二條的值是2。
例如：05 00 03 39 02 01

包頭一共6個位元組，如下：
1、位元組一：包頭長度，固定填寫0x05；
2、位元組二：包頭型別標識，固定填寫0x00，表示長簡訊；
3、位元組三：子包長度，固定填寫0x03，表示後面三個位元組的長度；
4、位元組四到位元組六：包內容：
1）位元組四：長訊息參考號，每個SP給每個使用者傳送的每條參考號都應該不同，可以從0開始，每次加1，最大255，便於同一個終端對同一個SP的訊息的不同的長簡訊進行識別；
2）位元組五：本條長訊息的的總訊息數，從1到255，一般取值應該大於2；
3）位元組六：本條訊息在長訊息中的位置或序號，從1到255，第一條為1，第二條為2，最後一條等於第四位元組的值。
7位的協議頭格式：06 08 04 XX XX MM NN
byte 1 : 06, 表示剩餘協議頭的長度
byte 2 : 08, 這個值在GSM 03.40規範9.2.3.24.1中規定，表示隨後的這批超長簡訊的標識位長度為2（格式中的XX值）。
byte 3 : 04, 這個值表示剩下簡訊標識的長度
byte 4-5 : XX XX，這批簡訊的唯一標誌，事實上，SME(手機或者SP)把訊息合併完之後，就重新記錄，所以這個標誌是否唯一併不是很重要。
byte 6 : MM, 這批簡訊的數量。如果一個超長簡訊總共5條，這裡的值就是5。
byte 7 : NN, 這批簡訊的數量。如果當前簡訊是這批簡訊中的第一條的值是1，第二條的值是2。
例如：06 08 04 00 39 02 01

到此，長簡訊的傳送設定基本完成，但是有一點要注意：Src_Id 協議裡這個欄位在一條長簡訊中必須要一樣，不然手機會解析成三條，
並三條都 是錯誤簡訊。

折騰了2天，對於Cmpp長簡訊，簡單說，就是cmpp欄位的pk_total和 pk_number需要設定，另外udhi需要設定為1，如果採用6位元組的udhi，則把簡訊內容按134位元組來分割，在頭部新增6位元組udhi，剛好 140位元組。（這是一個邊界點，有些cmpp伺服器，必須小於140位元組，等於也不行，你得自己試）。另外需要注意的是：UDHI頭的後面三個位元組，第一 是順序號，確保不重複就行，其他兩個位元組，和pk_total/pk_num一致；此外；這幾條簡訊的seq_num也要一致。我用Nokia6630接 收正常，手機會自動拼接成1條長簡訊。