長短信息：是指超過70個漢字，140個字節的信息內容
一、CMPP協議相關字段分析
CMPP協議具體部分請參考《中國移動互聯網短信網關接口協議（V3.0.0）.doc》
CMPP_SUBMIT消息定義（SP--->SMG）
| 字段名 |
字節數 |
屬性 |
描述 |
| Msg_Id |
8 |
Unsigned Integer |
信息標識。 |
| Pk_total |
1 |
Unsigned Integer |
相同Msg_Id的信息總條數，從1開始。 |
| Pk_number |
1 |
Unsigned Integer |
相同Msg_Id的信息序號，從1開始。 |
| Registered_Delivery |
1 |
Unsigned Integer |
是否要求返回狀態確認報告： 0：不需要； 1：需要。 |
| Msg_level |
1 |
Unsigned Integer |
信息級別。 |
| Service_Id |
10 |
Octet String |
業務標識，是數字、字母和符號的組合。 |
| Fee_UserType |
1 |
Unsigned Integer |
計費用戶類型字段： 0：對目的終端MSISDN計費； 1：對源終端MSISDN計費； 2：對SP計費； 3：表示本字段無效，對誰計費參見Fee_terminal_Id字 段。 |
| Fee_terminal_Id |
32 |
Octet String |
被計費用戶的號碼，當Fee_UserType為3時該值有效，當Fee_UserType為0、1、2時該值無意義。 |
| Fee_terminal_type |
1 |
Unsigned Integer |
被計費用戶的號碼類型，0：真實號碼；1：偽碼。 |
| TP_pId |
1 |
Unsigned Integer |
GSM協議類型。詳細是解釋請參考GSM03.40中的9.2.3.9。 |
| TP_udhi |
1 |
Unsigned Integer |
GSM協議類型。詳細是解釋請參考 GSM03.40中的9.2.3.23,僅使用1位，右對齊。 |
| Msg_Fmt |
1 |
Unsigned Integer |
信息格式： 0：ASCII串； 3：短信寫卡操作； 4：二進制信息； 8：UCS2編碼； 15：含GB漢字。。。。。。 |
| Msg_src |
6 |
Octet String |
信息內容來源(SP_Id)。 |
| FeeType |
2 |
Octet String |
資費類別： 01：對“計費用戶號碼”免費； 02：對“計費用戶號碼”按條計信息費； 03：對“計費用戶號碼”按包月收取信息費。 |
| FeeCode |
6 |
Octet String |
資費代碼（以分為單位）。 |
| ValId_Time |
17 |
Octet String |
存活有效期，格式遵循SMPP3.3協議。 |
| At_Time |
17 |
Octet String |
定時發送時間，格式遵循SMPP3.3協議。 |
| Src_Id |
21 |
Octet String |
源號碼。SP的服務代碼或前綴為服務代碼的長號碼, 網關將該號碼完整的填到SMPP協議Submit_SM消息相應的source_addr字段，該號碼最終在用戶手機上顯示為短消息的主叫號碼。 |
| DestUsr_tl |
1 |
Unsigned Integer |
接收信息的用戶數量(小於100個用戶)。 |
| Dest_terminal_Id |
32*DestUsr_tl |
Octet String |
接收短信的MSISDN號碼。 |
| Dest_terminal_type |
1 |
Unsigned Integer |
接收短信的用戶的號碼類型，0：真實號碼；1：偽碼。 |
| Msg_Length |
1 |
Unsigned Integer |
信息長度(Msg_Fmt值為0時：<160個字節；其 它<=140個字節)，取值大於或等於0。 |
| Msg_Content |
Msg_length |
Octet String |
信息內容。 |
| LinkID |
20 |
Octet String |
點播業務使用的LinkID，非點播類業務的MT流程不使用該字段。 |
紅色部分表示發長短信要更改的字段
洋紅色部分表示發長短信可以更改或者不更改的字段
在cmpp協議里，CMPP_SUBMIT消息定義中有相應的參數配置：
- TP_udhi ：0代表內容體里不含有協議頭信息 1代表內容含有協議頭信息（長短信，push短信等都是在內容體上含有頭內容的）當設置內容體包含協議頭，需要根據協議寫入相應的信息，長短信協議頭有兩種：
- 6位協議頭格式：05 00 03 XX MM NN
a) byte 1 : 05, 表示剩余協議頭的長度
b) byte 2 : 00, 這個值在GSM 03.40規范9.2.3.24.1中規定，表示隨后的這批超長短信的標識位長度為1（格式中的XX值）。
c) byte 3 : 03, 這個值表示剩下短信標識的長度
d) byte 4 : XX，這批短信的唯一標志，事實上，SME(手機或者SP)把消息合並完之后，就重新記錄，所以這個標志是否唯一並不是很 重要。
e) byte 5 : MM, 這批短信的數量。如果一個超長短信總共5條，這里的值就是5。
f) byte 6 : NN, 這批短信的數量。如果當前短信是這批短信中的第一條的值是1，第二條的值是2
例如：05 00 03 39 02 01
- 7 位的協議頭格式：06 08 04 XX XX MM NN
a) byte 1 : 06, 表示剩余協議頭的長度
b) byte 2 : 08, 這個值在GSM 03.40規范9.2.3.24.1中規定，表示隨后的這批超長短信的標識位長度為2（格式中的XX值）。
c) byte 3 : 04, 這個值表示剩下短信標識的長度
d) byte 4-5 : XX XX，這批短信的唯一標志，事實上，SME(手機或者SP)把消息合並完之后，就重新記錄，所以這個標志是否唯一並不是很重要。
e) byte 6 : MM, 這批短信的數量。如果一個超長短信總共5條，這里的值就是5。
f) byte 7 : NN, 這批短信的數量。如果當前短信是這批短信中的第一條的值是1，第二條的值是2
例如：06 08 04 00 39 02 01
二、實現代碼(C#)
| byte[] messageUCS2 = Encoding.BigEndianUnicode.GetBytes(MtMsg); int messageUCS2Len = messageUCS2.Length; int maxMessageLen = 140; if (messageUCS2Len > maxMessageLen) { int messageUCS2Count = messageUCS2Len / (maxMessageLen - 6) + 1; //長短信分為多少條發送 byte[] tp_udhiHead = new byte[6]; tp_udhiHead[0] = 0x05; tp_udhiHead[1] = 0x00; tp_udhiHead[2] = 0x03; tp_udhiHead[3] =//0x0A; tp_udhiHead[4] = (byte)messageUCS2Count; tp_udhiHead[5] = 0x01; //默認為第一條 for (int i = 0; i < messageUCS2Count; i++) { tp_udhiHead[5] = (byte)(i + 1); byte[] msgContent; if (i != messageUCS2Count - 1) { //不為最后一條 msgContent =BIConvert.byteAdd(tp_udhiHead, messageUCS2, i * (maxMessageLen - 6), (i + 1) * (maxMessageLen - 6)); } else { msgContent = BIConvert.byteAdd(tp_udhiHead, messageUCS2, i * (maxMessageLen - 6), messageUCS2Len); } } }
|
三、總結
以上是移動CMPP中長短信的實現方法，在聯通、電信短信協議中，實現方法一樣。
移動CMPP協議長短信方案：
- Msg_Fmt = 8 ；
Tp_Udhi = 1； - 可采用6字節協議頭，也可采用7字節協議頭，實測都通過。
- 6字節協議頭：
- MsgContent的前三個字節為：0x05, 0x00, 0x03（0x05表示后面還有5字節，0x03表示后面還有3字節）
- 第四個字節為批號，合成同條長短信的小短信填一樣的值即可。（同時給同個號碼發多條長短信的要分不同長短信填寫）；
- 第五個字節為Pk_total的值，即這批短信的總條數。
- 第六個字節為Pk_number的值，即這條短信在長短信中的序號，從1開始。。
- 7字節協議頭：
- MsgContent的前三個字節為：0x06, 0x08, 0x04（0x06表示后面還有6字節，0x04表示后面還有4字節）
- 第四、五個字節為批號，合成同條長短信的小短信填一樣的值即可。（同時給同個號碼發多條長短信的要分不同長短信填寫）；
- 第六個字節為Pk_total的值
- 第七個字節為Pk_number的值
- 6字節協議頭：
- MsgContent 在第6或7字節后加上要發送的短信內容，記得要UCS2編碼的哦。
- Pk_total和Pk_number 可以不設置，如果要設置，就要分別跟TP_udhi的MM和NN字段一致
聯通SGIP1.2協議長短信方案
只測試了6字節協議頭的，方法與以上移動使用的6字節協議頭一樣。
MessageCoding= 8 ；
Tp_Udhi = 1；
MessageContent前三個字節為：0x05, 0x00, 0x03
第四個字節為批號；
第五個字節為這批短信的總條數；
第六個字節這條短信在長短信中的序號，從1開始。
3、MessageContent在第6字節后加上要發送的短信內容的UCS2編碼
電信SMGP3協議長短信方案:
- 設置tlv字段TP_udhi為0x01，表示消息內容里面包含消息頭(也就是說含長短信頭)
-
內容前面需要增加6個字段
- 字節一：包頭長度，固定填寫0x05；
- 字節二：包頭類型標識，固定填寫0x00，表示長短信；
- 字節三：子包長度，固定填寫0x03，表示后面三個字節的長度；
- 字節四到字節六：包內容：
- 字節四：長消息參考號，每個SP給每個用戶發送的每條參考號都應該不同，可以從0開始，每次加1，最大255，便於同一個終端對同一個SP的消息的不同的長短信進行識別；
- 字節五：本條長消息的的總消息數，從1到255，一般取值應該大於2；
- 字節六：本條消息在長消息中的位置或序號，從1到255，第一條為1，第二條為2，最后一條等於第四字節的值。
-
例子：
05 00 03 00 02 01
05 00 03 00 02 02 -
你還需要設置PkTotal和PkNumber
這個字段如果不設置並不影響用戶手機對短信的拼裝，但是會影響ismp的健權和計費，一組pktotal pknumber里面的數據ismp是當一條短信健權和計費。
| 提綱 1 物聯網數據卡系統源碼——前篇 2 物聯網數據卡系統源碼——通信模塊 2.2 協議封裝和實現 3 物聯網數據卡系統源碼——Windows服務模塊 3.1 Windows服務模塊概述 3.2 Windows服務模塊實現 3.3 高並發回調處理 3.4 部署安裝 |