CMPP3.0 长短信实现方案
長短信息:是指超過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消息定義中有相應的參數配置: ??
?
- 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協議長短信方案:
?
Tp_Udhi = 1;
- 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的值
?
聯通SGIP1.2協議長短信方案
?
只測試了6字節協議頭的,方法與以上移動使用的6字節協議頭一樣。?
MessageCoding= 8 ;?
Tp_Udhi = 1;?
MessageContent前三個字節為:0x05, 0x00, 0x03?
第四個字節為批號;?
第五個字節為這批短信的總條數;?
第六個字節這條短信在長短信中的序號,從1開始。?
3、MessageContent在第6字節后加上要發送的短信內容的UCS2編碼
?
電信SMGP3協議長短信方案:
?
內容前面需要增加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 物聯網數據卡系統源碼——前篇 1.1 物聯網技術架構圖 1.2 物聯網的主要應用領域 1.3 物聯網傳感器61個應用領域 1.4 物聯網常見通信協議梳理 2 物聯網數據卡系統源碼——通信模塊 2.1 通信模塊整體概述 2.2 協議封裝和實現 2.3 長短信 2.4 粘包的處理 2.5 物聯網通訊與普通短信通訊的區別和要注意的地方 3 物聯網數據卡系統源碼——Windows服務模塊 3.1 Windows服務模塊概述 3.2 Windows服務模塊實現 3.3 高并發回調處理 3.4 部署安裝 |
轉載于:https://www.cnblogs.com/tuyile006/p/5707271.html
總結
以上是生活随笔為你收集整理的CMPP3.0 长短信实现方案的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 开发小技巧总结
- 下一篇: oracle按某个字段分组然后从每组取出