CMPP協議對長簡訊的支援
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++)