物聯網通訊與普通簡訊通訊的區別和要注意的地方

CMPP3.0中號碼欄位增加到32位，還增加了號碼型別欄位，可能是為了擴充套件不同型別的卡。

Dest_terminal_Id	32*DestUsr_tl	Octet String	接收簡訊的MSISDN號碼。
Dest_terminal_type	1	Unsigned Integer	接收簡訊的使用者的號碼型別，0：真實號碼；1：偽碼。

可是用CMPP3.0協議，也就是說傳送簡訊到物聯網路卡、從物聯網路卡回覆簡訊回來，都可以直接用這套CMPP3.0協議。那麼跟發手機簡訊有何不同之處呢，以下就是幾點不同：

 

1.關於編碼格式

目前物聯網路卡通訊，如果是英文內容，則只支援Ascii碼，也就是Msg_Fmt必須設定成0

Msg_Fmt

1

Unsigned Integer

資訊格式： 0：ASCII串； 3：簡訊寫卡操作； 4：二進位制資訊； 8：UCS2編碼； 15：含GB漢字。。。。。。

如果是傳送中文內容，則只支援UCS2編碼，即Msg_Fmt必須設定成8

另外有個特別費解的問題是，如果是發中文內容，簡訊閘道器會自動在簡訊後面加上一串尾巴，類似【ayf】等。這個問題在開發的時候必須注意，以免傳送的指令不能解析，需要做一些邏輯處理把尾巴去掉。

 

2.關於長簡訊

我們知道一條簡訊只能發140個位元組的內容，如果實際要發的內容超過這個數，就必須拆成多條傳送，這樣會有一些影響。為了髮長簡訊，我們的CMPP傳送程式必須做一些改造，具體請參考我的另一篇博文CMPP3.0 長簡訊實現方案

而對於物聯網路卡來說，收發長簡訊必須使用  7 位的協議頭格式：06 08 04 XX XX MM NN

這也是要注意的一點，否則解析傳送都會出錯。

 

3.關於使用者號碼型別

物聯網的使用者號碼型別選擇Dest_terminal_type=0即可。若選擇1會報錯。

其他

如遇到簡訊閘道器返回碼，可查詢以下網址看返回碼解釋 

http://www.cnblogs.com/tuyile006/p/5849722.html

常見返回碼：173  是物聯網路卡沒開通簡訊功能造成的。

這就是開發物聯網通訊過程中的經驗。

提綱

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 部署安裝