CDMA長簡訊問題

來源:互聯網
上載者:User

   CDMA的長簡訊與GSM的長簡訊一樣使用UDH的方式,也就是在簡訊的內容裡面前面增加長簡訊必要的資料。由於遵循GSM規範,所以CDMA使用者與GSM使用者間可以互髮長簡訊(當然前提是手機需要支援)。由於在簡訊內容裡面增加了6個位元組的資料,所以如果手機不支援收到的簡訊前面有6個位元組無法識別,會出現亂碼,由於存在/0的資料,部分手機也可能無法正常顯示餘下的內容。

 

    中國電信的簡訊接入提供了兩種方式,一種是ISAG方式接入,一種是SMGP協議接入。ISAG本身自行有長簡訊的封裝,由於廠家不同,支援的長度也存在差異。SMGP協議接入SP端需要自行封裝長簡訊協議。如何在SMGP的協議中發送長簡訊。我們需要做三件事情,分別為:
 一、設定tlv欄位TP_udhi為0x01,表示訊息內容裡麵包含訊息頭(也就是說含長簡訊頭)
     TLV欄位說明
      TLV是選擇性參數 Tag,Length,Value的縮寫

      其中
         Tag是2個位元組,表示欄位的標籤,說明是啥值
        Length是2個位元組,表示後面具體值的長度
         Value可變長度,長度為Length,欄位的內容

     TP_udhi的 Tag為:0x0002,Length為:0x0001 Value:為0x01,具體TLV參數設定參考SMGP3.1協議

 

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

  例子:
  05 00 03 00 02 01
  05 00 03 00 02 02
         參考代碼如下:
private static byte[] addContentHeader(byte[] content, int total, int num) { // 為了加訊息頭參數為(原資料,總條數,當前條數)<br /> // int curlong = content.length;<br /> byte[] newcontent = new byte[content.length + 6];<br /> newcontent[0] = 0x05;<br /> newcontent[1] = 0x00;<br /> newcontent[2] = 0x03;<br /> newcontent[4] = (byte) total;<br /> newcontent[5] = (byte) num;<br /> System.arraycopy(content, 0, newcontent, 6, content.length);<br /> return newcontent;<br /> }<br />  

 

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

 

   需要說明的是:

   一、如果網關方式長簡訊建議用ucs-2編碼
        因為在gbk編碼的過程中,英文當1個位元組;usc-2 中英文都2位元組,對於即將分割的長簡訊你很難確保中間不會混排中英文,所以拆分的時候不會出現漢字被截半個的問題。出現的現象為第一條簡訊正常,第二條簡訊開始存在亂碼。

   二、長簡訊成功率的問題也是不得不考慮的
       對於一組長簡訊,如果中間有一條簡訊丟了就無法拼回來長簡訊了,也就是說這組簡訊要全部都發送到使用者手機這裡才能正常拼裝和顯示,如果丟1條,其他的簡訊就等於白髮。假設簡訊發送成功率是95%,那2條拼接的長簡訊成功率是0.95*0.95=90.25%,如果10條簡訊拼接的長簡訊的成功率是0.95^10=59.87%。可以看出越長的長簡訊下行以後的成功率越低,可能會抵到超過你的想象。

   三、SMGP2.0協議無法發送長簡訊
       雖然部分CDMA的簡訊網關支援2.0協議,但是由於2.0協議未定義有TLV欄位,所以無法設定長簡訊必要的參數:TP_udhi

   四、長簡訊最大長度

       長簡訊目前根據網關的實際測試,最長可以由10條簡訊拼接,所以理論上發送最大的漢字為:(140-6(6個位元組的udh))  *10/2 = 670個漢字,不過需要說明的是,如此長的長簡訊正如第二點所說的成功率是低的驚人的。

 

   更多的協助可以參考我在Google上的項目:http://smgp.googlecode.com 該API已經對長簡訊進行了封裝,可以直接使用。

 

      

 

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.