1. 程式人生 > >CMPP3.0 長簡訊實現方案

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_UserType3時該值有效,當Fee_UserType012時該值無意義。

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

資訊格式:

0ASCII串;

3:簡訊寫卡操作;

4:二進位制資訊;

8UCS2編碼;

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訊息定義中有相應的引數配置:   

  1. 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協議長簡訊方案:

  1. Msg_Fmt = 8 ; 
    Tp_Udhi = 1;
  2. 可採用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的值
  3. MsgContent 在第6或7位元組後加上要傳送的簡訊內容,記得要UCS2編碼的哦。
  4. 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協議長簡訊方案:

    1. 設定tlv欄位TP_udhi為0x01,表示訊息內容裡面包含訊息頭(也就是說含長簡訊頭)
    2. 內容前面需要增加6個欄位

      • 位元組一:包頭長度,固定填寫0x05;
      • 位元組二:包頭型別標識,固定填寫0x00,表示長簡訊;
      • 位元組三:子包長度,固定填寫0x03,表示後面三個位元組的長度;
      • 位元組四到位元組六:包內容:
      • 位元組四:長訊息參考號,每個SP給每個使用者傳送的每條參考號都應該不同,可以從0開始,每次加1,最大255,便於同一個終端對同一個SP的訊息的不同的長簡訊進行識別;
      • 位元組五:本條長訊息的的總訊息數,從1到255,一般取值應該大於2;
      • 位元組六:本條訊息在長訊息中的位置或序號,從1到255,第一條為1,第二條為2,最後一條等於第四位元組的值。
    3. 例子: 
      05 00 03 00 02 01 
      05 00 03 00 02 02

    4. 你還需要設定PkTotal和PkNumber 
      這個欄位如果不設定並不影響使用者手機對簡訊的拼裝,但是會影響ismp的健權和計費,一組pktotal pknumber裡面的資料ismp是當一條簡訊健權和計費。

相關推薦

CMPP3.0 簡訊實現方案

長簡訊息:是指超過70個漢字,140個位元組的資訊內容 一、CMPP協議相關欄位分析 CMPP協議具體部分請參考《中國移動網際網路簡訊閘道器介面協議(V3.0.0).doc》 CMPP_SUBMIT訊息定義(SP--->SMG) 欄位名 位元組數 屬性

cmpp2.0簡訊的處理方案

長簡訊處理方案 上次寫過對簡訊傳送的處理,並沒有體現出對長簡訊的處理方案,在實際應用中發現了以下問題,對於簡訊長度超過指定的大小時會出現截短的現象. 原資訊地址:(裡面有原始碼,和相關的配置),主要對以下方法進行修改 1)這種方案是處理長簡訊的方式(可以實現向客戶端傳送的連

CMPP傳送簡訊,我可以實現了 CMPP2簡訊實現(java版)

辭職後我就在yiDong從事簡訊和群發的工作,從北京方面的專家哪裡學會了傳送簡訊,一開始只能傳送短簡訊,就是不超過140個字元,如果超過我就分割然後分成短的傳送。一直不能傳送超過140字元的。後來經過我閱讀了很多人帖子才實現,主要是看了下面的內容,然後修改了程式碼才實現的

Hadoop2.0 Namenode HA實現方案介紹及彙總

基於社群最新release的Hadoop2.2.0版本,調研了hadoop HA方面的內容。hadoop2.0主要的新特性(Hadoop2.0穩定版2.2.0新特性剖析): namenode federation: namenode在叢集規模大了之後會成為效能瓶頸,尤其是

CMPP3.0-超長簡訊

超長簡訊:簡訊內容超過70個漢字,提交給閘道器時候需要分成多條,但是使用者手機接收時候是一條(sp角度,手機發送長簡訊概念一樣)。 在cmpp協議裡,CMPP-_SUBMIT訊息定義中有相應的引數配置: TP_udhi :0代表內容體裡不含有協議頭資訊 1

CMPP3.0實現物聯網絡卡發簡訊遇到的問題

當下物聯網發展迅猛,物聯網絡卡可以接受簡訊指令,實現千里之外儘可掌控。本人做過一個這類專案,把相關經驗記錄下來,分享給需要的人。 物聯網絡卡通訊其實跟電話卡一樣,可以使用CMPP協議。不過由於物聯網絡卡位數為13位,未測試CMPP2.0是否支援,直接保險一點用

移動端html5頁面實現高亮全選文字內容的相容解決方案

最近需要給html5的WebAPP在頁面上實現一個複製功能:使用者點選長按文字會全選文字並彈出系統“複製”選單,使用者可以點選“複製”進行復制操作,然後貼上到AppStore搜尋對應的應用。之所以不是採用連結形式直接跳轉到AppStore對應應用是為了通過使用者的主動輸入關鍵詞搜尋給推廣的企業App

實時報表 T+0實現方案

一 問題背景   在報表的應用系統中,使用者越來越關注資料的實時性,希望最新發生的資料能在報表中體現出來,也就是我們常說的T+0場景, 以此及時輔助決策、驅動運營。 比如交通大資料應用的場景:需要結合實時資料瞭解車輛通行密度,合理進行道路規劃,同時根據歷史資料預測線路擁堵情況、

【外掛分享】 簡訊如何實現Destoonb2b_V6.0對接簡訊驗證碼

對接簡訊的時候發現一家簡訊公司,有些不錯的簡訊驗證碼的外掛,對接起來挺方便的,有需求的可以看一下。http://www.ihuyi.com/ 外掛說明本外掛系互億無線針對DestoonB2B_V6.0簡訊外掛開發,外掛內的所有檔案均為對原檔案的修改,如果你的系統經過二次開發,安裝本外掛之前,請仔細核對修改。

原創安卓手機QQ7.0登入介面動態背景視訊實現方案

qq7.0登入介面動態背景實現 qq7.0登入介面動態視訊背景實現 android動態視訊背景 android動態背景 分析qq7.0: 視訊在開啟登入介面就開始播放 了,而且期間無黑屏 而且是迴圈播放的 畫質問題這裡就不說了,這個看視訊源了。

網站二級域名用asp.net 2.0實現方案

基本思路:1. 域名支援泛解析,即是指:把A記錄 *.域名.com  解析到伺服器IP,伺服器IIS中做繫結,繫結時主機頭為空;2. 為了實現完全的二級域,建兩個站點,一個為主站用,一個為使用者用,兩個站點目錄都指到一個同一網站目錄3. 在Web程式中或取URL來源中的二級域名主機頭,比如:abc.域名.co

安卓6.0請求許可權實現簡訊打電話

安卓6.0的許可權申請有了變化,更加安全了,具體變化不再多說了, 很多許可權不再是簡單的在註冊清單裡註冊了。 找了一個工具類,使用起來還不錯。 Github https://github.com/a5533348/XPermission PermissionUtils.ja

米聯客(MSXBO)USB3.0 UVC攝像頭實現基於FT602Q晶片方案

USB3.0 UVC攝像頭實現基於FT602Q晶片方案 USB3.0介面晶片FT602Q支援UVC協議,可以很方便的實現一個US

《程式碼統計分析工具 4.0》多國語言實現方案

【翻譯工具】- PoEdit【軟體開發工具】- Code::Blocks- wxWidgets- GCC【程式碼示例】程式碼裡使用 _("string") 方式,將需要翻譯的字串標記起來,PoEdit工具會自動識別這些字串,自動生成 .po檔案,翻譯並儲存會生成 .mo 檔案。 wxArraySt

架構設計:資料服務系統0到1落地實現方案

本文原始碼:[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、基於業務 資料服務通常有很

vue2.0結合Element實現select動態控制input禁用

嘻嘻 [0 attr 折騰 解決 model utf del logs 今天有一個盆友問小穎,怎麽實現用select動態控制input禁用,也就是說,input默認是可編輯的,但是每當我選一次select,input就會變成禁用,雖然小穎不知道她為什麽這樣做,因為小

針對敲詐病毒(WanaCrypt0r2.0)的應對方案

補丁 處理 應對 敲詐病毒 wanacrypt0r 2.0 病毒背景 5月12日起,Onion、WNCRY兩類敲詐者病毒變種在全國乃至全世界大範圍內出現爆發態勢,中國大陸大量教育網用戶和企業用戶中招。 與以往不同的是,這次的新變種病毒添加了NS

Python error: Microsoft Visual C++ 9.0 is required 解決方案

compile blank 安裝ipython con pan code logs onf pre 換了新電腦,在使用python2.7 pip 安裝ipython時,報錯了 error: Microsoft Visual C++ 9.0 is required. Get

邊框0.5px的實現方法

pan web -i tran webkit css3 borde index html 原理: css3 的縮放 ----> transform: scale()   完整代碼如下: <!DOCTYPE html> <html lang

spark提交jar包時出現unsupported major.minor version 52.0錯誤的解決方案

模式 classname jdk版本 images pil 編譯器 就會 home spark 一、問題:     最近在spark集群上做一個項目,打包提交jar包時,出現了unsupported major.minor version 52.0的報錯,而在local模式