1. 程式人生 > >CMPP協議對長簡訊的支援

CMPP協議對長簡訊的支援

1。CMPP3.0 超長簡訊
http://59905.blog.spforum.net/26058.html
1、長簡訊息:是指超過70個漢字,140個位元組的資訊內容。      

        最近在做一個某地市公司運營商的GPRS導引專案的時候,運營商要求將對使用者的提示簡訊息(超過140個位元組)傳送到使用者手機,在使用者的手機上一次全顯 示。

        上網搜尋了一些相關的資料,現在將實現總結如下:

一、CMPP協議相關欄位分析(在此只講髮長簡訊相關的cmpp_submit訊息,cmpp的其他內容的請參考《中國移動網際網路簡訊閘道器介面協議 (V3.0.0).doc》

欄位名 位元組數 屬性 描述
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
                     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 

               
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    

二. 實現程式碼(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++)