司雨濛,謝海濤,靳華中,葉志偉,張程暉
(1. 湖北工業(yè)大學 計算機學院, 湖北 武漢 430068;2. 上海交通大學 高性能計算中心, 上海 200240)
短信服務(SMS: Short Message Service)是通信從模擬轉向數(shù)字技術最成功的商業(yè)應用之一,短信業(yè)務已在銀行證券、商貿(mào)物流、行政管理和公共服務等諸多行業(yè)得到廣泛應用。SMS數(shù)據(jù)由服務提供商(SP:Service Provider)產(chǎn)生,通過互聯(lián)網(wǎng)連接到電信運營商的行業(yè)網(wǎng)關轉發(fā)到用戶手機終端。根據(jù)短信協(xié)議規(guī)定,短信長度在140字節(jié)以內(nèi),即一條短信不能超過70個漢字。如果需要發(fā)送長度超過140字節(jié)(70個漢字)的超長短信,通常的處理方法是先將其按單條長度140字節(jié)(70字)分拆成多條短信,然后逐條發(fā)送,因此手機終端收到的短信也是逐條顯示。顯然,上述處理方式存在若干弊端。例如:用戶需要查看多條短信才能獲取短信的全部內(nèi)容,查看短信很不方便;長短信拆分成多條后,分別通過多個短消息網(wǎng)關設備進行存儲轉發(fā)可能導致部分短信的丟失或失序,容易導致用戶對短信內(nèi)容理解的偏差;按字符編碼拆分短信可能導致部分內(nèi)容出現(xiàn)亂碼,影響用戶使用短信時的體驗。隨著網(wǎng)絡通信和智能終端的發(fā)展,人們對超長短信的應用需求日益增長,短信內(nèi)容長度限制已經(jīng)嚴重影響短信業(yè)務的推廣,如何解決超長短信問題的發(fā)送與接收已越來越受到廣大研究者的關注。1999年GSM03.40標準已經(jīng)開始支持長短信協(xié)議[1],3GPP標準則進一步對長短信協(xié)議進行規(guī)范[2]。本文研究超長短信的發(fā)送和接收技術,對短信增值業(yè)務的拓展和短信應用系統(tǒng)的研究、開發(fā)和應用具有重要意義。
超長短信(CSMS: Concatenated Short Messages)是指長度超過140字節(jié)(或70漢字)的短信。手機終端發(fā)送短信時,按照一條短信進行編輯并發(fā)送,接收時也按一條短信整體顯示出來。實際上,在電信運營商網(wǎng)絡中短信是按多條分別傳輸,也按照多條短信進行計費。短信在發(fā)送時按照一定規(guī)范自動拆分成多條,而接收時則合并成一條。實現(xiàn)超長短信的基本原理如圖1所示。
(1)發(fā)送端。手機終端或SP需要發(fā)送超長短信時,自動將該條長短信拆分成多條長度小于140字節(jié)(或70漢字)的短信,每條短信分別發(fā)送給運營商網(wǎng)絡。短信拆分時,按照長短信協(xié)議要求,每條短信均添加長短信標識,并逐一編號,在短信內(nèi)容部分封裝長短信協(xié)議頭部。
(2)運營商網(wǎng)絡。對拆分的多條短信分別進行獨立傳輸。由于采用存儲轉發(fā)方式分別對多條短信進行傳輸,短信到達接收端時順序與原有的發(fā)送順序可能不一致。
(3)接收端。對接收到的多條短信分別進行存儲。根據(jù)長短信協(xié)議字段標識,判斷是否已經(jīng)接收到所有的分拆短信。若只接收部分短信,則將它們暫時存儲,不顯示出來。當所有的分拆短信全部接收完成后,再將它們按原有的編號順序合并成一條完整的長短信并顯示給客戶。
為了支持超長短信,GSM03.04定義TP_UDHI字段作為超長短信的標識[1],如果該字段為0,則表示普通短信;如果該字段為1,則該短信為長短信中的一條子短信。同時,每條子短信需要設置一個6字節(jié)長的長短信協(xié)議頭,位于短信內(nèi)容字段(TP_UD)的前6個字節(jié),協(xié)議頭部分設置了該子短信的序號等信息,用于接收端對這些子短信進行設并重新合并成一條長短信。6個字節(jié)長短信協(xié)議頭格式如表1所示。
表1 6字節(jié)長短信協(xié)議頭格式
在表1中,各個協(xié)議字段的具體含義分別表示如下:LH(Length of the Header):協(xié)議頭的總長度,標識當前字節(jié)之后剩余長協(xié)議頭的長度,對6字節(jié)的協(xié)議頭而言,該字段為05;
IEI(Information Element Idientifier):信息單元標識。GSM03.40規(guī)范中定義IEI=00表示隨后的這批長短信的標識位(即RN)長度為1[1];
LSH(Length of the Sub-Header):信息單元頭長度,表示長短信協(xié)議頭部分剩下長度,這里為03;
RN(Reference Number):長短信編號,是長短信的唯一標識,取值范圍1~255;
MAP(Maximum Amount of Pieces):本超長短信總條數(shù),標識這批長短信一共分成多少條子短信分片,每條分片最長的短信長度是134字節(jié)(67字)。
Sequence Number:短信序號,當前短信在這批長短信中的位置,取值為1~MAP。
6字節(jié)長短信協(xié)議中用于標識長短信編號的RN字段只有1個字節(jié),取值范圍從1~255,當需要大量發(fā)送超長短信而不能保證接收端能完全接收到所有的子短信時,有可能出現(xiàn)兩條具有相同編號的子短信拼接在一起而引起短信內(nèi)容的異常。3GPP協(xié)議定義了7字節(jié)的超長短信協(xié)議頭,格式如表2所示。與6字節(jié)協(xié)議頭不同的是:RN從1個字節(jié)擴充為2個字節(jié),一定程度上避免了出現(xiàn)錯誤合并超長短信的問題。
表2 7字節(jié)長短信協(xié)議頭格式
根據(jù)GSM中對超長短信的定義,本文設計了SP端針對長短信的發(fā)送和接收系統(tǒng),該系統(tǒng)采用6位協(xié)議頭格式對超長短信(短信內(nèi)容為漢字)進行封包,下面分別對短信的發(fā)送(Mobile Terminate ,MT表示從SP端發(fā)送到手機終端)和接收(Mobile Originate, MO表示從手機終端發(fā)向SP端)過程進行闡述。
用戶將待發(fā)送的短信存儲在短信數(shù)據(jù)庫的待發(fā)送短信表中,由系統(tǒng)定時查詢數(shù)據(jù)庫中是否有需要發(fā)送的短信。如果有,則交由短信發(fā)送模塊進行發(fā)送,將該記錄從待發(fā)送表中刪除,同時在發(fā)送歷史表中記錄該短信的相關信息(如發(fā)送時間、收信人手機號、發(fā)送ID和狀態(tài)等)。超長短信發(fā)送處理模塊的處理流程如圖2所示。
圖2 MT長短信發(fā)送流程圖
由圖2可知,對提取的待發(fā)送短信數(shù)據(jù),首先判斷短信內(nèi)容的長度CSMS_Length,如果短信長度小于70個字,則該短信為普通短信,將TP_UDHI字段置0,并將短信內(nèi)容直接封裝在短信數(shù)據(jù)包中。如果短信長度大于70個字,則將該長短信拆分為多條子短信分別處理:首先將每條分段短信的TP_UDHI字段設置為1,然后計算短信分片的數(shù)量Cnt,計算方法如下:
Cnt=「CSMS_Length/67?
(1)
執(zhí)行如下循環(huán)對超長短信進行拆分并封裝成多條子短信數(shù)據(jù)包:
for(int i=1;i<=Cnt;i++){
(1)生成本段長短信分片的編號:RNi=Rand(i)
(2)填充本段長短信分片的協(xié)議頭:05,00,03,RNi,Cnt,i
(3)填充本段長短信分片的內(nèi)容:if(i==Cnt)CSMS(67i,CSMS_Length)else CSMS(67i,67i+67}
當組成本長短信的各條分片分別組裝成短信數(shù)據(jù)包后,再由號碼判斷模塊根據(jù)接收手機號碼判斷由哪個運營商的通信協(xié)議去處理。電信SMGP[3]、聯(lián)通SGIP[4]和移動CMPP[5]分別為三家運營商的短消息協(xié)議處理模塊,對各自手機的短信進行協(xié)議處理,交由各行業(yè)網(wǎng)關發(fā)至用戶手機終端,同時返回該短信的發(fā)送狀態(tài)報告(成功或失敗原因),短消息協(xié)議處理模塊將收到的狀態(tài)信息記錄到短信發(fā)送記錄表中作為計費依據(jù),也可根據(jù)狀態(tài)報告進行錯誤重傳。各條分片短信到達手機終端后根據(jù)長短信協(xié)議頭部分信息自動合并為一條超長短信。
用戶主動發(fā)起對MO短信或MT短信的回復,通過運營商網(wǎng)絡由行業(yè)網(wǎng)關傳遞到短消息協(xié)議處理模塊,分別由電信SMGP、聯(lián)通SGIP和移動CMPP進行接收,解析出MO短信數(shù)據(jù)包的短信內(nèi)容和TP_UDHI字段后,根據(jù)這些信息檢測和合并MO超長短信內(nèi)容,超長短信接收處理模塊的處理流程如圖3所示。由圖3可知,超長短信MO處理模塊首先判斷TP_UDHI字段的值,若為0,則該MO短信為普通短信,直接將該短信存儲在接收短信數(shù)據(jù)庫中。若TP_UDHI字段為1,說明該短信為長短信中的某個分片,需要對該長短信的所有分片信息處理后才能合并成回復該長短信的內(nèi)容。具體處理過程如下:
(1)從短信內(nèi)容字段中取出長協(xié)議頭部分,判斷第一個字節(jié)的值。若為05,則取出前6個字節(jié)作為長短信協(xié)議頭。若為06,則取出前7個字節(jié)。
圖3 MO長短信發(fā)送流程圖
(2)對長短信協(xié)議頭部分進行解析,將收到相同RN字段的長短信分片內(nèi)容(剔除長短信協(xié)議頭部分)緩存,同時設置該長短信接收超時時限。
(3)根據(jù)Cnt字段和Seq字段內(nèi)容,判斷該長短信的所有分片是否已接收。若全部分片接收完畢,則根據(jù)Seq字段將緩存的長短信分片按照序號重新排列后合并成一條長短信。同時,記錄該長短信接收信息。若沒有收到所有短信分片,則繼續(xù)接收。
(4)超過超時時限仍未收到所有長短信分片,則放棄對該長短信的合并處理,并記錄出錯信息,同時刪除緩存的長短信分片。
實現(xiàn)超長短信處理是影響短信系統(tǒng)性能的關鍵。本文對超長短信的原理進行分析,設計SP端的超長短信功能,實現(xiàn)了超長短信發(fā)送時進行自動拆分和接收時自動合并。通過短信的自動拆分和合并,使得超長短信在SP端和手機終端之間變得透明,以提升短信的可讀性和可用性。
[參 考 文 獻]
[1] GSM 03.40 V7.3.0[S].ETSI TC-SMG.
[2] 3GPP TS 23.040 V9.2.0 [EB/OL].(2010-03-10).[2014-04-02].http://www.3gpp.org.
[3] 中國-03移動通信互聯(lián)網(wǎng)短信網(wǎng)關接口協(xié)議(V2.0)[S].中國移動通信,2003.
[4] 中國聯(lián)合通信公司短消息網(wǎng)關系統(tǒng)接口協(xié)議(SGIP) [S].2版. 中國聯(lián)合通信公司,2001.
[5] 中國電信短信網(wǎng)關接口協(xié)議SMGP(V3.0)[S].中國電信,2008.