專利名稱：多條可拆分及包含簡(jiǎn)單多媒體信息的ussd傳輸方法
技術(shù)領(lǐng)域：
本申請(qǐng)涉及一種多條可拆分及包含簡(jiǎn)單多媒體信息的USSD傳輸方法，所述方法是對(duì)3GPP USSD業(yè)務(wù)信令層3協(xié)議的一種擴(kuò)充。
背景技術(shù)：
關(guān)于當(dāng)前3GPP(3rd Generation Partnership Project，第三代合作伙伴計(jì)劃)USSD(Unstructured Supplementary Service Data，非結(jié)構(gòu)化補(bǔ)充業(yè)務(wù)數(shù)據(jù))業(yè)務(wù)的定義可以參見相關(guān)的技術(shù)規(guī)范，例如3GPP TS 24.080 V3.7.0(2002-06)，以及3G TS 24.090 V3.0.0(1999-05)。
技術(shù)規(guī)范3G TS 24.090 V3.0.0(1999-05)定義了3GPP系統(tǒng)中USSD數(shù)據(jù)操作的層3描述。其中包括，網(wǎng)絡(luò)發(fā)起(network initiated)的USSD數(shù)據(jù)操作USSD request、USSD notification等；以及移動(dòng)端發(fā)起(mobile initiated)的各種USSD數(shù)據(jù)操作。關(guān)于上述操作過程的細(xì)節(jié)可以參見上述文檔的詳細(xì)說明。技術(shù)規(guī)范3GPP TS 24.080 V3.7.0(2002-06)定義了支持3GPP系統(tǒng)中層3移動(dòng)射頻接口上的補(bǔ)充業(yè)務(wù)所必需的信息編碼。
在現(xiàn)有的3GPP中定義的移動(dòng)通信補(bǔ)充業(yè)務(wù)中的USSD業(yè)務(wù)中，由于存在較大不足之處而制約了其應(yīng)用首先，單條ussd-String的長(zhǎng)度有限，這樣對(duì)于包含較多信息的消息只能通過在內(nèi)容上削減、或采取多次交互的方式實(shí)現(xiàn)。
另外，在3GPP的USSD相關(guān)協(xié)議中，ussd-String的內(nèi)容只能包含文本，這在內(nèi)容的豐富及多樣性上是一個(gè)短處。

發(fā)明內(nèi)容
基于USSD業(yè)務(wù)的以上兩個(gè)不足，在考慮與3GPP已有協(xié)議兼容的同時(shí)，提出對(duì)USSD信令層協(xié)議的補(bǔ)充協(xié)議，以擴(kuò)充USSD在現(xiàn)代移動(dòng)通信網(wǎng)絡(luò)中的功能范圍。
對(duì)于USSD信令層協(xié)議的擴(kuò)充，主要基于以上所述之兩大需求進(jìn)行。一是將一條消息放不下的內(nèi)容放在多條消息中傳送，通過在ussd-String中增加UDH(User Data Header，用戶數(shù)據(jù)頭)字段，先在發(fā)送端分拆消息，利用UDH中定義的序號(hào)標(biāo)識(shí)和在接收端進(jìn)行重組(序列號(hào)的取值范圍暫定為0-127，大于或等于128的值用于出錯(cuò)處理)。二在簡(jiǎn)單多媒體內(nèi)容的傳輸上，將簡(jiǎn)單的多媒體內(nèi)容放在UDH中進(jìn)行傳輸。
因此，通過在ussd-String中引入U(xiǎn)DH數(shù)據(jù)字段，可以解決上述的技術(shù)問題。同時(shí)，為了引入U(xiǎn)DH，在各消息中加入U(xiǎn)DHI(User DataHeader Indicator，用戶數(shù)據(jù)頭指示位)以指示UDH是否在ussd-String中存在。
本發(fā)明提出了一種基于3GPP USSD業(yè)務(wù)系統(tǒng)來發(fā)送USSD消息的改進(jìn)方法，所述方法包括如下步驟在ussd-String字段加入用戶數(shù)據(jù)頭(UDH)字段；在發(fā)送端發(fā)送消息時(shí)，將一個(gè)超長(zhǎng)的USSD消息被拆分成多個(gè)單條USSD消息，其中在每個(gè)單條USSD消息中的UDH字段中定義了其序號(hào)標(biāo)識(shí)ID；接收端在每次接收到單條USSD消息后，向發(fā)送方返回一條USSD proceed消息，以確認(rèn)所述單條USSD消息；以及在接收端接收到所述過長(zhǎng)的USSD消息的全部?jī)?nèi)容后，利用所述每個(gè)單條USSD消息的UDH中的序號(hào)標(biāo)識(shí)ID，將多個(gè)單條USSD消息重新組合成初始的USSD消息。
此外，所述USSD proceed消息還包括出錯(cuò)指示(proceed-Succeed)字段，用于指示接收端收到的上一條消息正確或錯(cuò)誤；消息標(biāo)識(shí)號(hào)(proceed-Index)字段，用于標(biāo)識(shí)接收端收到的上一條消息的ID號(hào)；當(dāng)所述出錯(cuò)指示字段指示所接收的單條消息正確時(shí)，發(fā)送方繼續(xù)發(fā)送下一個(gè)單條消息；以及當(dāng)所述出錯(cuò)指示字段指示所接收的單條消息錯(cuò)誤時(shí)，發(fā)送方根據(jù)所述消息標(biāo)識(shí)號(hào)字段所標(biāo)識(shí)的ID號(hào)重新發(fā)送所述出錯(cuò)的單條消息，或者按照現(xiàn)有的出錯(cuò)處理流程釋放本次連接本發(fā)明還提出了一種基于3GPP USSD業(yè)務(wù)系統(tǒng)來發(fā)送USSD消息的改進(jìn)方法，所述方法包括如下步驟在ussd-String字段加入用戶數(shù)據(jù)頭(UDH)字段，所述UDH中包含了簡(jiǎn)單多媒體內(nèi)容；發(fā)送方發(fā)送所述具有UDH字段的USSD消息；以及接收方接收所述具有UDH字段的USSD消息，并提取所述UDH字段中的簡(jiǎn)單多媒體內(nèi)容。
所述用戶數(shù)據(jù)頭(UDH)字段包括UDHL字段，指示ussd-String中的用戶數(shù)據(jù)頭(UDH)的長(zhǎng)度；IEI字段，用于指示IE數(shù)據(jù)的類型；IEIDL字段，用于指示IE數(shù)據(jù)的長(zhǎng)度；IEID字段，用于指示IE數(shù)據(jù)的內(nèi)容。
此外，所述簡(jiǎn)單多媒體內(nèi)容的至少包括預(yù)定義聲音；自定義聲音；預(yù)定義圖片；大尺寸黑白圖片；小尺寸黑白圖片；預(yù)定義動(dòng)畫；大尺寸黑白動(dòng)畫；小尺寸黑白動(dòng)畫；格式定義；以及保留用途。


圖1示出了多條可拆分MO USSD request交互順序圖。
圖2示出了多條可拆分MO USSD request中間某條出錯(cuò)的交互順序圖。
圖3示出了對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSDrequest的交互順序圖。
圖4出了對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSDresponse的交互順序圖。
圖5示出了對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSDrequest傳輸中某條出錯(cuò)的交互順序圖。
圖6示出了對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSDresponse傳輸中某條出錯(cuò)的交互順序圖。
圖7示出了多條可拆分MT USSD request交互順序圖。
圖8示出了多條可拆分MT USSD request傳輸中某條出錯(cuò)的交互順序圖。
圖9示出了對(duì)MT USSD request移動(dòng)臺(tái)多條可拆分USSDresponse的交互順序圖。
圖10示出了對(duì)MT USSD request移動(dòng)臺(tái)多條可拆分USSDresponse傳輸中某條出錯(cuò)的交互順序圖。
圖11示出了網(wǎng)絡(luò)結(jié)點(diǎn)釋放MT USSD request交互。如果網(wǎng)絡(luò)結(jié)點(diǎn)需要從移動(dòng)臺(tái)獲取更多信息，則可以按現(xiàn)有的流程繼續(xù)該次USSD交互過程。
圖12示出了多條可拆分MT USSD notification交互順序圖。
圖13示出了多條可拆分MT USSD notification中間某條出錯(cuò)的交互順序圖。
圖14示出了網(wǎng)絡(luò)結(jié)點(diǎn)收到錯(cuò)誤的USSD proceed釋放交互的交互順序圖。
圖15示出了移動(dòng)臺(tái)收到錯(cuò)誤的USSD proceed釋放交互的交互順序圖。
圖16示出了移動(dòng)臺(tái)檢測(cè)到網(wǎng)絡(luò)結(jié)點(diǎn)不支持本擴(kuò)充協(xié)議時(shí)釋放交互的交互順序圖。
圖17示出了網(wǎng)絡(luò)結(jié)點(diǎn)檢測(cè)到移動(dòng)臺(tái)不支持本擴(kuò)充協(xié)議時(shí)釋放交互的交互順序圖。
圖18示出了ussd-String引入U(xiǎn)DH后的數(shù)據(jù)內(nèi)容結(jié)構(gòu)圖。
圖19示出了UDH的數(shù)據(jù)內(nèi)容結(jié)構(gòu)圖。
圖20示出了為16*16圖片的點(diǎn)陣編碼舉例。
圖21示出了補(bǔ)充業(yè)務(wù)軟件部分通常實(shí)現(xiàn)方式架構(gòu)圖。
此外，對(duì)于本技術(shù)領(lǐng)域中常常使用的中英文簡(jiǎn)寫，給出如下對(duì)照表及名詞解釋

以下將參考附圖更完整地描述本發(fā)明，附圖中示出了本發(fā)明的優(yōu)選實(shí)施例。但是本發(fā)明可體現(xiàn)在許多其他的形式中，而不應(yīng)當(dāng)被理解為限于這里所述的實(shí)施例；相反提供這些實(shí)施例是為了公開內(nèi)容將會(huì)詳盡和完整，并且將會(huì)完整地將本發(fā)明的范圍傳達(dá)給本領(lǐng)域的技術(shù)人員。
具體實(shí)施例方式
如前所述，在現(xiàn)有的3GPP中定義的移動(dòng)通信補(bǔ)充業(yè)務(wù)中的USSD業(yè)務(wù)中，由于存在較大不足之處而制約了其應(yīng)用單條USSD STRING的長(zhǎng)度有限，這樣對(duì)于包含較多信息的消息只能通過在內(nèi)容上削減、或采取多次交互的方式實(shí)現(xiàn)，很不方便。
根據(jù)本發(fā)明的一個(gè)實(shí)施例，將一條消息放不下的內(nèi)容放在多條消息中傳送，先在發(fā)送端分拆消息，隨后在接收端進(jìn)行重組，因此，需要對(duì)現(xiàn)有的USSD業(yè)務(wù)流程進(jìn)行改進(jìn)。
下面的第1節(jié)將介紹本發(fā)明提出的對(duì)現(xiàn)有USSD業(yè)務(wù)流程的改動(dòng)。
1.1 USSD proceed的引入為了實(shí)現(xiàn)本發(fā)明的發(fā)明目的，提出了一種全新的數(shù)據(jù)操作USSDproceed。
對(duì)于超長(zhǎng)內(nèi)容分拆后的多條USSD，接收端在收到第一條后，首先判斷其UDH中的內(nèi)容，如果UDH中顯示該USSD消息是一條多條消息，則向發(fā)送端發(fā)送一條USSD proceed(proceeding)消息。發(fā)送端在收到該條消息后，繼續(xù)依次發(fā)送余下的消息。接收端在收到最后一條消息后，才根據(jù)其內(nèi)容做出響應(yīng)，發(fā)送USSD response或者發(fā)送一條RELEASE COMPLETE以釋放此次交互。接收端在收到某條消息后發(fā)現(xiàn)此消息數(shù)據(jù)損壞或出現(xiàn)其他錯(cuò)誤，應(yīng)向發(fā)送端發(fā)送一條USSD proceed(error)，指明接收的數(shù)據(jù)出錯(cuò)，發(fā)送端在收到該出錯(cuò)消息后應(yīng)重發(fā)該條消息，或者在無法處理的情況下，釋放此次交互。
USSD proceed的協(xié)議數(shù)據(jù)的詳細(xì)定義請(qǐng)參見后文第2節(jié)。
以下結(jié)合附圖1-17來具體說明本發(fā)明所提出的改進(jìn)流程。
1.2 MO USSD request流程的改動(dòng)注在本節(jié)及以下兩小節(jié)的USSD消息順序流程圖中，為簡(jiǎn)化，將MSC，HLR，VLR視為統(tǒng)一的網(wǎng)絡(luò)結(jié)點(diǎn)，不考慮USSD消息需要中繼的情況。
如附圖1所示，MO USSD request為一個(gè)多條消息的順序圖。
圖2顯示了MO USSD request中間某條出錯(cuò)的消息順序圖。如果在收到某條消息后，網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)現(xiàn)此條消息已經(jīng)損壞或出現(xiàn)了其他錯(cuò)誤，則向MS發(fā)送USSD proceed(error)消息，MS在收到出錯(cuò)消息后可以選擇重發(fā)或者直接釋放此次交互。
網(wǎng)絡(luò)結(jié)點(diǎn)在每收到一條消息時(shí)，則保存該條消息，在收到最后一條消息后，分析其內(nèi)容(MMI-mode時(shí))或者將組合后的內(nèi)容交給指定的應(yīng)用程序(application mode時(shí))處理。
消息處理完畢后，網(wǎng)絡(luò)結(jié)點(diǎn)將給移動(dòng)臺(tái)發(fā)送USSD response(RELEASE COMPLETE)同時(shí)釋放該次交互，或者發(fā)送USSDrequest(FACILITY)，以從移動(dòng)臺(tái)處獲取進(jìn)一步的內(nèi)容。如果該條USSD response或USSD request也是一條需要多條消息才能發(fā)送的消息，則也按多條內(nèi)容的方式進(jìn)行處理。如果是USSD response(RELEAS ECOMPLETE)，移動(dòng)臺(tái)在收到最后一條單條消息，網(wǎng)絡(luò)結(jié)點(diǎn)收到移動(dòng)臺(tái)對(duì)最后一條的確認(rèn)后才認(rèn)為該次交互完全結(jié)束。
圖3顯示了對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSDrequest的交互順序圖。
圖4顯示了對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSDresponse的交互順序圖。
當(dāng)移動(dòng)臺(tái)檢查到收到的單條消息出錯(cuò)時(shí)，也可以選擇要求網(wǎng)絡(luò)結(jié)點(diǎn)重發(fā)該條消息或發(fā)送一條空的USSD response表明需要中止當(dāng)前交互，網(wǎng)絡(luò)結(jié)點(diǎn)收到后則向移動(dòng)臺(tái)發(fā)送RELEASE COMPLETE直接釋放該交互，不再繼續(xù)發(fā)送后續(xù)的消息。如圖5、圖6所示。
圖5是對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSD request傳輸中某條出錯(cuò)的交互順序圖。
圖6是對(duì)MO USSD request網(wǎng)絡(luò)結(jié)點(diǎn)為多條可拆分USSDresponse傳輸中某條出錯(cuò)的交互順序圖。
移動(dòng)臺(tái)也可在任何時(shí)候向網(wǎng)側(cè)發(fā)送RELEASE COMPLETE釋放該次交互。
1.3 MT USSD request流程的改動(dòng)當(dāng)網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)起MT USSD request消息時(shí)，此消息可能是一個(gè)多條消息，移動(dòng)臺(tái)也需要向網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)送USSD proceed消息以確認(rèn)對(duì)前一條消息的接收。
圖7顯示了多條可拆分MT USSD request交互順序圖。
當(dāng)移動(dòng)臺(tái)檢查到收到的單條消息出錯(cuò)時(shí)，也可以選擇要求網(wǎng)絡(luò)結(jié)點(diǎn)重發(fā)該條消息或發(fā)送一條空的USSD response表明需要中止當(dāng)前交互，網(wǎng)絡(luò)結(jié)點(diǎn)收到后則向移動(dòng)臺(tái)發(fā)送RELEASE COMPLETE直接釋放該交互，不再繼續(xù)發(fā)送后續(xù)的消息。
圖8顯示了多條可拆分MT USSD request傳輸中某條出錯(cuò)的交互順序圖。
在移動(dòng)臺(tái)收到全部單條消息后，對(duì)其消息內(nèi)容進(jìn)行重組，然后將其內(nèi)容顯示在移動(dòng)臺(tái)屏幕上讓用戶進(jìn)行下一步操作(MMI-mode)，或者將其完整地轉(zhuǎn)送給ME/TE/SIM(application mode)。在用戶或者應(yīng)用程序做出響應(yīng)后，如果該響應(yīng)也需要拆分后多條發(fā)送，移動(dòng)臺(tái)就按序依次向網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)送。圖9顯示了對(duì)MT USSD request移動(dòng)臺(tái)多條可拆分USSD response的交互順序圖。
如果網(wǎng)絡(luò)結(jié)點(diǎn)收到移動(dòng)臺(tái)的USSD response中出現(xiàn)錯(cuò)誤，則網(wǎng)絡(luò)結(jié)點(diǎn)可以選擇要求移動(dòng)臺(tái)重發(fā)或者直接發(fā)送RELEASE COMPLETE以釋放該次交互。如圖10，是對(duì)MT USSD request移動(dòng)臺(tái)多條可拆分USSD response傳輸中某條出錯(cuò)的交互順序圖。
網(wǎng)絡(luò)結(jié)點(diǎn)在完全收到移動(dòng)臺(tái)的響應(yīng)后，可以發(fā)送RELEASECOMPLETE來釋放此次交互。如圖11，是網(wǎng)絡(luò)結(jié)點(diǎn)釋放MT USSDrequest交互。如果網(wǎng)絡(luò)結(jié)點(diǎn)需要從移動(dòng)臺(tái)獲取更多信息，則可以按現(xiàn)有的流程繼續(xù)該次USSD交互過程。
移動(dòng)臺(tái)也可在任何時(shí)候向網(wǎng)側(cè)發(fā)送RELEASE COMPLETE釋放該次交互。
1.4 MT USSD notification流程的改動(dòng)當(dāng)網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)送的MT USSD notification也是一個(gè)多條消息時(shí)，也需要按次序依次發(fā)送，移動(dòng)臺(tái)在收到全部的單條消息后再向網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)送響應(yīng)消息。網(wǎng)絡(luò)結(jié)點(diǎn)收到USSD response后按正常流程向移動(dòng)臺(tái)發(fā)送RELEASE COMPLETE以釋放此次交互。順序圖如圖12所示，是多條可拆分MT USSD notification交互順序圖。
若移動(dòng)臺(tái)收到的USSD notification的單條消息出錯(cuò)，則移動(dòng)臺(tái)可以要求網(wǎng)絡(luò)結(jié)點(diǎn)重發(fā)該條消息，或者發(fā)送一條USSD response以讓網(wǎng)絡(luò)結(jié)點(diǎn)釋放此次交互。順序圖如圖13，是多條可拆分MT USSDnotification中間某條出錯(cuò)的交互順序圖。
移動(dòng)臺(tái)也可在任何時(shí)候向網(wǎng)側(cè)發(fā)送RELEASE COMPLETE釋放該次交互。
1.5 對(duì)USSD proceed的出錯(cuò)處理如果發(fā)送端收到USSD proceed，發(fā)現(xiàn)該條USSD proceed本身是一條錯(cuò)誤消息，無法解析。則發(fā)送端應(yīng)向接收端發(fā)一條出錯(cuò)消息。如果網(wǎng)絡(luò)結(jié)點(diǎn)為發(fā)送端，則向移動(dòng)臺(tái)直接發(fā)一條Facility為Return error的RELEASE COMPLETE消息釋放此次交互。如圖14所示，網(wǎng)絡(luò)結(jié)點(diǎn)收到錯(cuò)誤的USSD proceed釋放交互的交互順序圖。
如果移動(dòng)臺(tái)為發(fā)送端，則向網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)送一條Facility為Returnerror的FACILITY消息通知網(wǎng)絡(luò)結(jié)點(diǎn)釋放此次交互。如圖15，移動(dòng)臺(tái)收到錯(cuò)誤的USSD proceed釋放交互的交互順序圖。
移動(dòng)臺(tái)或網(wǎng)絡(luò)結(jié)點(diǎn)在發(fā)出某條拆分后的單條USSD消息后，應(yīng)等待接收USSD proceed，同時(shí)啟動(dòng)一個(gè)定時(shí)器。在定時(shí)器到時(shí)后若還未收到，則可以認(rèn)為對(duì)端沒有響應(yīng)，應(yīng)發(fā)送一條RELEASE COMPLETE釋放此次交互同時(shí)以某種方式通知用戶。
1.6 與當(dāng)前版本USSD信令層協(xié)議信令流程中兼容性的考慮如果移動(dòng)臺(tái)或網(wǎng)絡(luò)的一方并不支持多條消息的處理，在當(dāng)前的協(xié)議下，接收方不會(huì)發(fā)送USSD proceed給發(fā)送方。在這種情況下，發(fā)送方發(fā)現(xiàn)接收方未發(fā)來USSD proceed，如果發(fā)送方是移動(dòng)臺(tái)，網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)的響應(yīng)可能有以下幾種情況1、為RELEASE COMPLETE，F(xiàn)acility為正常響應(yīng)或者error，則此次交互自然結(jié)束；2、為FACILITY，不管里面的內(nèi)容如何，移動(dòng)臺(tái)檢測(cè)到是這種情況時(shí)，向網(wǎng)絡(luò)結(jié)點(diǎn)發(fā)送空的USSD response，通知網(wǎng)絡(luò)中止此次交互。如圖16所示，移動(dòng)臺(tái)檢測(cè)到網(wǎng)絡(luò)結(jié)點(diǎn)不支持本擴(kuò)充協(xié)議時(shí)釋放交互的交互順序圖。
如果發(fā)送方是網(wǎng)絡(luò)結(jié)點(diǎn)，則網(wǎng)絡(luò)結(jié)點(diǎn)直接向移動(dòng)臺(tái)發(fā)送RELEASE COMPLETE以釋放此次交互。如圖17所示，網(wǎng)絡(luò)結(jié)點(diǎn)檢測(cè)到移動(dòng)臺(tái)不支持本擴(kuò)充協(xié)議時(shí)釋放交互的交互順序圖。
2.定義USSD proceed如上所述，根據(jù)本發(fā)明的一個(gè)實(shí)施例，將一條消息放不下的內(nèi)容放在多條消息中傳送，通過在ussd-String中增加UDH字段，先在發(fā)送端分拆消息，利用UDH中定義的序號(hào)標(biāo)識(shí)和在接收端進(jìn)行重組(序列號(hào)的取值范圍暫定為0-127，大于或等于128的值用于出錯(cuò)處理)。
為了實(shí)現(xiàn)上述第1節(jié)描述的相關(guān)流程改進(jìn)，本發(fā)明提出了上述的USSD proceed。USSD proceed用來移動(dòng)臺(tái)與網(wǎng)絡(luò)結(jié)點(diǎn)間傳輸對(duì)對(duì)端傳來的多條組合式USSD消息中的某一條的回應(yīng)；用來確認(rèn)對(duì)端傳來的該單條消息出錯(cuò)同時(shí)要求對(duì)端重傳該條USSD。
USSD proceed的ASN.1的定義如下
UnstructuredSS-Proceed OPERATIONARGUMENTproceed-Arg SEQUENCE{proceed-Succeed
IMPLICIT BOOLEAN OPTIONAL，proceed-Index[1]IMPLICIT INTEGER(0..255)OPTIONAL，...，｝RESULTussd-Res SEQUENCE{ussd-DataCodingScheme OCTET STRING(SIZE(1))，ussd-String OCTET STRING(SIZE(1..160))，...，ussd-String-Udhi
IMPLICIT BOOLEAN OPTIONAL}ERRORS--systemFailure--localValue34，--unexpectedDataValue--localValue36，--callBarred--localValue13}∷＝localValue58上述定義中，proceed-Succeed字段用來標(biāo)識(shí)接收端收到的上一條消息正確或錯(cuò)誤。proceed-Index用來標(biāo)識(shí)接收端收到的上一條消息的ID號(hào)。當(dāng)proceed-Succeed取值為TRUE時(shí)，proceed-Index字段可以省略。proceed-Succeed字段本身也可以省略，此時(shí)proceed-Index字段也必須省略，用來表示上一條消息接收成功。當(dāng)proceed-Succeed取值為FALSE時(shí)，proceed-Index字段可以填入接收到的錯(cuò)誤消息的ID號(hào)(見下述4.4節(jié))。當(dāng)接收到的錯(cuò)誤消息中UDH損壞無法得知ID時(shí)，該字段也可省略。由發(fā)送方收到該USSD proceed時(shí)自行判斷哪一條出錯(cuò)。
3.定義USSD UDHI參數(shù)為了在中ussd-String引入U(xiǎn)DH，需要在USSD request，USSDresponse，USSD notification中加上UDHI。它的具體作用就是指示在ussd-String中是否有UDH存在。
UDHI的取值如下1、TRUE，表示ussd-String中含有UDH；2、FALSE，表示ussd-String中不包含UDH。
則在ProcessUnstructuredSS-Request的ASN.1定義中增加UDHI如下processUnstructuredSS-Request OPERATIONARGUMENTussd-Arg SEQUENCE{ussd-DataCodingScheme OCTET STRING(SIZE(1))，ussd-String OCTET STRING(SIZE(1..160))，...，alertingPattern OCTET STRING(SIZE(1))OPTIONAL，msisdn
IMPLICIT OCTET STRING(SIZE(1..20))(SIZE(1..9))OPTIONALussd-String-Udhi
IMPLICIT BOOLEAN OPTIONAL}RESULTussd-ResSEQUENCE{ussd-DataCodingSchemeOCTET STRING(SIZE(1))，ussd-String OCTET STRING(SIZE(1..160))，...，ussd-String-Udhi
IMPLICIT BOOLEAN OPTIONAL}ERRORS{--systemFailure--localValue34，--dataMissing--localValue35，
--unexpectedDataValue--localValue36，--unknownAlphabet--localValue71，--callBarred--localValue13}∷＝localValue62則在unstructuredSS-Request的ASN.1定義中增加UDHI如下unstructuredSS-Request OPERATIONARGUMENTussd-ArgSEQUENCE{ussd-DataCodingScheme OCTET STRING(SIZE(1))，ussd-String OCTET STRING(SIZE(1..160))，...，alertingPattern OCTET STRING(SIZE(1))OPTIONAL，msisdn
IMPLICIT OCTET STRING(SIZE(1..20))(SIZE(1..9))OPTIONALussd-String-Udhi
IMPLICIT BOOLEAN OPTIONAL}RESULTussd-Res SEQUENCE{ussd-DataCodingScheme OCTET STRING(SIZE(1))，ussd-String OCTET STRING(SIZE(1..160))，ussd-String-Udhi
IMPLICIT BOOLEAN OPTIONAL，...，ussd-String-Udhi
IMPLICIT BOOLEAN OPTIONAL}ERRORS{--systemFailure--localValue34，--dataMissing--localValue35，--unexpectedDataValue--localValue36，--absentSubscriber--localValue27，
--illegalSubscriber--localValue9，--illegalEquipment--localValue12，--unknownAlphabet--localValue71，--ussd-Busy--localValue72}∷＝localValue60則在unstructuredSS-Notify的ASN.1定義中增加UDHI如下unstructuredSS-Notify OPERATIONARGUMENTussd-Arg SEQUENCE{ussd-DataCodingScheme OCTET STRING(SIZE(1))，ussd-String OCTET STRING(SIZE(1..160))，...，alertingPattern OCTET STRING(SIZE(1))OPTIONAL，msisdn
IMPLICIT OCTET STRING(SIZE(1..20))(SIZE(1..9))OPTIONALussd-String-Udhi
IMPLICIT BOOLEAN OPTIONAL}ERRORS{--systemFailure--localValue34，--dataMissing--localValue35，--unexpectedDataValue--localValue36，--absentSubscriber--localValue27，--illegalSubscriber--localValue9，--illegalEquipment--localValue12，--unknownAlphabet--localValue71，--ussd-Busy--localValue72}∷＝localValue61
網(wǎng)絡(luò)結(jié)點(diǎn)或移動(dòng)臺(tái)在處理時(shí)，若發(fā)現(xiàn)沒有UDHI，則應(yīng)認(rèn)為這非擴(kuò)充協(xié)議的USSD信令層協(xié)議數(shù)據(jù)單元，應(yīng)按現(xiàn)在方式以單條USSD處理。
4.定義USSD UDH參數(shù)4.1 ussd-String的結(jié)構(gòu)ussd-String在3GPP的定義中是1至160個(gè)字節(jié)長(zhǎng)的數(shù)據(jù)，本身并沒有什么格式，可以理解成就是一塊BUFFER，里面用來填充需要發(fā)送的內(nèi)容。
根據(jù)本發(fā)明的一個(gè)實(shí)施例，在ussd-String中引入U(xiǎn)DH后，其結(jié)構(gòu)如圖18，是ussd-String引入U(xiǎn)DH后的數(shù)據(jù)內(nèi)容結(jié)構(gòu)圖。
UDH的長(zhǎng)度為整數(shù)字節(jié)，剩下的內(nèi)容為按ussd-DataCodingScheme編碼的文本內(nèi)容。如果文本內(nèi)容是以GSM7bit編碼的，若其編碼后的長(zhǎng)度不是整數(shù)字節(jié)，則在最后一個(gè)字節(jié)的末尾填充0補(bǔ)齊。
4.2 UDH的結(jié)構(gòu)如前所述，在現(xiàn)有的3GPP的USSD相關(guān)協(xié)議中，USSD String的內(nèi)容只能包含文本，這在內(nèi)容的豐富及多樣性上是一個(gè)短處。
而根據(jù)本發(fā)明的另一個(gè)實(shí)施例，提出了在簡(jiǎn)單多媒體內(nèi)容的傳輸上，將簡(jiǎn)單的多媒體內(nèi)容放在UDH中進(jìn)行傳輸。
在USSD的信令層擴(kuò)充協(xié)議中，UDH的結(jié)構(gòu)設(shè)計(jì)如圖19所示，是UDH的數(shù)據(jù)內(nèi)容結(jié)構(gòu)圖。其中的字段含義如下

表1UDH的數(shù)據(jù)內(nèi)容字段定義
UDHL，IEIDL的取值都為整型，指明UDH和IEI的包含的字節(jié)數(shù)。UDHL的值應(yīng)不大于159(0x9F)。
在UDH中可能包含一個(gè)或多個(gè)IE，每個(gè)IE可能是同一或不同類型的數(shù)據(jù)。但是如果IE代表的是多條可拆分USSD的序號(hào)時(shí)，此類型IE在UDH中應(yīng)只出現(xiàn)一次。
IEID中的數(shù)據(jù)可能因?yàn)镮E的類型不同而其長(zhǎng)度非整數(shù)字節(jié)，則USSD發(fā)送方應(yīng)根據(jù)IE的類型決定如何將其填充為整數(shù)字節(jié)。不一定填零。
4.3 IE的類型IE的類型定義如下表，包括多條可拆分USSD與簡(jiǎn)單多媒體內(nèi)容的定義。

表2UDH的IEI取值當(dāng)IEI的取值在09-FF時(shí)，USSD的接收方應(yīng)忽略該IE。為今后擴(kuò)充協(xié)議升級(jí)考慮，不向發(fā)送方發(fā)出錯(cuò)消息。
接收方在判斷IEI的類型后，按照其類型分別處理。
4.4 多條可拆分USSD的IE設(shè)置當(dāng)IEI的值為0x00時(shí)，IEID為多條可拆分USSD的序號(hào)。序號(hào)的取值以0x00開始，以1遞增，以0xFF結(jié)束。
如果IEI的類型為多條可拆分USSD，則此IE應(yīng)為UDH中第一個(gè)IE。
接收方在收到包括可拆分指示位IEI的USSD時(shí)，表明多條可拆分的USSD的發(fā)送開始。在收到序號(hào)為0xFF的可拆分USSD時(shí)，接收方把之前收到的所有USSD的內(nèi)容組合后在待機(jī)界面顯示或者轉(zhuǎn)送給應(yīng)用程序處理。
接收方在收到第二條開始的可拆分USSD時(shí)，若檢測(cè)到其中的序號(hào)與上一次接收到的序號(hào)比較后發(fā)現(xiàn)序號(hào)有誤，應(yīng)按上述1.5中所述的流程釋放此次交互。
4.5 聲音的IE設(shè)置當(dāng)IEI的值為0x01時(shí)，IEID的值為預(yù)定義的存儲(chǔ)在移動(dòng)臺(tái)的聲音的ID值(整型)。這種IE一般只存在于MT的USSD中。如果這也是一個(gè)多條交互，則應(yīng)在多條可拆分USSD全部收取后再行處理。
在處理時(shí)，在人機(jī)界面模式下(MMI-mode)，移動(dòng)臺(tái)將在顯示文本內(nèi)容的同時(shí)，播放預(yù)定義在移動(dòng)臺(tái)側(cè)的聲音。在應(yīng)用程序模式(application mode)下，應(yīng)用程序播放預(yù)定義在應(yīng)用程序中的聲音。一般來說，此預(yù)定義的聲音應(yīng)為移動(dòng)臺(tái)或駐留在移動(dòng)臺(tái)的應(yīng)用程序與網(wǎng)絡(luò)結(jié)點(diǎn)約定好的聲音內(nèi)容。
下表是一個(gè)預(yù)定義聲音的推薦約定

表3預(yù)定義聲音的推薦取值當(dāng)IEI的值為0x02時(shí)，IEID的值為iMelody格式定義的聲音，長(zhǎng)度最長(zhǎng)為128個(gè)字節(jié)。IEIDL用來指示IEID的長(zhǎng)度。與預(yù)定義的聲音一樣，這種IE一般只存在于MT的USSD中。如果這也是一個(gè)多條交互，則應(yīng)在多條可拆分USSD全部收取后再行處理。
在處理時(shí)，也與預(yù)定義的聲音類似。在人機(jī)界面模式下(MMI-mode)，移動(dòng)臺(tái)將在顯示文本內(nèi)容的同時(shí)，將該IEID中的聲音數(shù)據(jù)轉(zhuǎn)換后播出。在應(yīng)周程序模式(application mode)下，應(yīng)用程序?qū)⒃揑EID中的聲音數(shù)據(jù)轉(zhuǎn)換后播出。
為避免沖突，USSD消息中類型為預(yù)定義或自定義聲音的IE最好只包含一個(gè)。
關(guān)于iMelody格式的聲音，請(qǐng)參考Specifications for Ir MobileCommunications(IrMC)iMelody，Infrared Data Association，October 24th2000。
4.6 圖片的IE設(shè)置當(dāng)IEI的值為0x03時(shí)，IEID的值為預(yù)定義的存儲(chǔ)在移動(dòng)臺(tái)的黑白兩色圖片的ID值(整型)。如果這也是一個(gè)多條交互，則應(yīng)在多條可拆分USSD全部收取后再行處理。
在處理時(shí)，在人機(jī)界面模式下(MMI-mode)，移動(dòng)臺(tái)將在顯示文本內(nèi)容的同時(shí)，顯示該預(yù)定義圖片。在應(yīng)用程序模式(applicationmode)下，應(yīng)用程序自己決定如何處理預(yù)定義在應(yīng)用程序中的圖片。一般來說，此預(yù)定義的圖片應(yīng)為移動(dòng)臺(tái)或駐留在移動(dòng)臺(tái)的應(yīng)用程序與網(wǎng)絡(luò)結(jié)點(diǎn)約定好的圖片。
下表是一個(gè)預(yù)定義圖片的推薦約定

表4預(yù)定義圖片的推薦取值當(dāng)IEI的值為0x04或0x05時(shí)，IEID為黑白圖片數(shù)據(jù)，長(zhǎng)度最長(zhǎng)為128(32*32)或者32個(gè)字節(jié)(16*16)。IEIDL用來指示IEID的長(zhǎng)度。如果這也是一個(gè)多條交互，則應(yīng)在多條可拆分USSD全部收取后再行處理。
在處理時(shí)，在人機(jī)界面模式下(MMI-mode)，移動(dòng)臺(tái)將在顯示文本內(nèi)容的同時(shí)，顯示該自定義圖片。在應(yīng)用程序模式(applicationmode)下，應(yīng)用程序自己決定如何處理該自定義圖片。
自定義圖片的點(diǎn)陣定義如下圖片的每一個(gè)點(diǎn)對(duì)應(yīng)一個(gè)bit，每一行從左到右對(duì)應(yīng)一個(gè)字節(jié)的高位到低位，第一行的第一個(gè)字節(jié)對(duì)應(yīng)圖片數(shù)據(jù)的第一個(gè)字節(jié)，接下來是第一行的其余字節(jié)，第二行的第一個(gè)字節(jié)，依次類推。
圖20為16*16圖片的點(diǎn)陣編碼舉例。
4.7 動(dòng)畫的IE設(shè)置當(dāng)IEI的值為0x06時(shí)，IEID的值為預(yù)定義的存儲(chǔ)在移動(dòng)臺(tái)的黑白兩色動(dòng)畫的ID值(整型)。如果這也是一個(gè)多條交互，則應(yīng)在多條可拆分USSD全部收取后再行處理。
在處理時(shí)，在人機(jī)界面模式下(MMI-mode)，移動(dòng)臺(tái)將在顯示文本內(nèi)容的同時(shí)，顯示該預(yù)定義動(dòng)畫。在應(yīng)用程序模式(applicationmode)下，應(yīng)用程序自己決定如何處理預(yù)定義在應(yīng)用程序中的動(dòng)畫。一般來說，此預(yù)定義的動(dòng)畫應(yīng)為移動(dòng)臺(tái)或駐留在移動(dòng)臺(tái)的應(yīng)用程序與網(wǎng)絡(luò)結(jié)點(diǎn)約定好的動(dòng)畫。
下表是一個(gè)預(yù)定義動(dòng)畫的推薦約定

表5預(yù)定義動(dòng)畫的推薦取值當(dāng)IEI的值為0x07或0x08時(shí)，IEID為黑白圖片數(shù)據(jù)，長(zhǎng)度最長(zhǎng)為128(16*16 times 4)或者32個(gè)字節(jié)(8*8 times 4)。IEIDL用來指示IEID的長(zhǎng)度。如果這也是一個(gè)多條交互，則應(yīng)在多條可拆分USSD全部收取后再行處理。
在處理時(shí)，在人機(jī)界面模式下(MMI-mode)，移動(dòng)臺(tái)將在顯示文本內(nèi)容的同時(shí)，顯示該自定義動(dòng)畫。在應(yīng)用程序模式(applicationmode)下，應(yīng)用程序自己決定如何處理該自定義動(dòng)畫。
自定義動(dòng)畫的每幀按照自定義圖片的點(diǎn)陣編碼方式編碼，按照各幀的播放順序按順序組織動(dòng)畫數(shù)據(jù)。
4.8 格式定義的IE設(shè)置當(dāng)IEI的值為0x09時(shí)，IEID的值為本IE后的IE(圖片或動(dòng)畫)在文本內(nèi)容中的位置，從0開始。
若圖片IE或動(dòng)畫IE前無格式定義IE，則由接收方自行決定該多媒體內(nèi)容顯示在文本內(nèi)容的位置。一般來說，多媒體內(nèi)容放在文本內(nèi)容的最前面。
5.參考實(shí)現(xiàn)本USSD業(yè)務(wù)補(bǔ)充協(xié)議只需要在處理USSD的L3消息的網(wǎng)絡(luò)結(jié)點(diǎn)(包括移動(dòng)臺(tái)，MSC，HLR，VLR)處稍加修改就可以實(shí)現(xiàn)。
在軟件處理的層次上看，USSD業(yè)務(wù)一般的軟件實(shí)現(xiàn)如圖21，補(bǔ)充業(yè)務(wù)軟件部分通常實(shí)現(xiàn)方式架構(gòu)圖。
本補(bǔ)充協(xié)議在實(shí)現(xiàn)時(shí)，一般來說，需要修改L3處理部分以及應(yīng)用層處理部分。
一、發(fā)送USSD消息時(shí)、應(yīng)用層接受用戶或其他應(yīng)用的輸入，將USSD內(nèi)容(包括超長(zhǎng)文本或多媒體消息)構(gòu)建成內(nèi)部數(shù)據(jù)或消息發(fā)送給L3處理部分。
在L3處理部分，在接收到應(yīng)用層發(fā)來的USSD發(fā)送請(qǐng)求時(shí)，判斷相應(yīng)的USSD內(nèi)容的長(zhǎng)度，以及是否包含多媒體消息，計(jì)算出是否需要分拆消息及構(gòu)建UDH參數(shù)。發(fā)送完某條單條消息后等待USSDproceed消息，正常收到時(shí)繼續(xù)發(fā)送后續(xù)消息直至結(jié)束。在出錯(cuò)時(shí)按第二章中定義的流程處理錯(cuò)誤情況。
二、接收USSD消息時(shí)、L3處理部分在收到分拆的第一條USSD消息時(shí)不立即將結(jié)果傳送給應(yīng)用層，而是等全部消息接收完畢后構(gòu)建相應(yīng)的內(nèi)部消息，將分拆的文本合并，加入收到的多媒體內(nèi)容，然后再把內(nèi)部數(shù)據(jù)或消息傳送給應(yīng)用層處理。在收到的分拆的USSD消息出錯(cuò)時(shí)，L3處理部分向?qū)Χ税l(fā)送USSD proceed(error)消息，若不能收到對(duì)方重發(fā)的上一條出錯(cuò)的分拆消息，則向應(yīng)用層發(fā)送出錯(cuò)消息。
應(yīng)用層處理部分，收到L3發(fā)來的內(nèi)部消息時(shí)，向用戶顯示該超長(zhǎng)消息，若包含圖片或動(dòng)畫，則按格式定義與文本一起顯示；若包含聲音信息，則按聲音信息的類型調(diào)用相應(yīng)功能播放。應(yīng)用層處理部分的另一種可能處理是再轉(zhuǎn)送給駐留于該網(wǎng)絡(luò)結(jié)點(diǎn)的某一應(yīng)用進(jìn)行處理。若L3處理部分發(fā)來的是出錯(cuò)指示，則向用戶提示出錯(cuò)。
在前述描述和相關(guān)附圖中給出的教導(dǎo)的幫助下，本發(fā)明所屬領(lǐng)域的技術(shù)人員將會(huì)想到本發(fā)明的許多修改和其他實(shí)施例。因此，要理解本發(fā)明不限于所公開的特定實(shí)施例，修改和其他實(shí)施例想要被包括在所附權(quán)利要求書的范圍內(nèi)。雖然這里采用了特定術(shù)語，但是它們只是在一般的描述性意義上使用的，而不是用于限制目的。
作為對(duì)詳細(xì)描述的結(jié)論，應(yīng)該注意本領(lǐng)域的技術(shù)人員將會(huì)很清楚可對(duì)優(yōu)選實(shí)施例做出許多變化和修改，而實(shí)質(zhì)上不脫離本發(fā)明的原理。另外，這種變化和修改想要被包含在所附權(quán)利要求書所述的本發(fā)明的范圍之內(nèi)。此外，在以下權(quán)利要求書中，結(jié)構(gòu)、材料、行為和所有裝置的等同物或者步驟加功能元素想要包含用于執(zhí)行其引證的功能的任何結(jié)構(gòu)、材料或行為。
權(quán)利要求
1.一種基于3GPP USSD業(yè)務(wù)系統(tǒng)來發(fā)送USSD消息的改進(jìn)方法，所述方法包括如下步驟在ussd-String字段加入用戶數(shù)據(jù)頭(UDH)字段；在發(fā)送端發(fā)送消息時(shí)，將一個(gè)超長(zhǎng)的USSD消息被拆分成多個(gè)單條USSD消息，其中在每個(gè)單條USSD消息中的UDH字段中定義了其序號(hào)標(biāo)識(shí)ID；接收端在每次接收到單條USSD消息后，向發(fā)送方返回一條USSDproceed消息，以確認(rèn)所述單條USSD消息的接收；以及在接收端接收到所述超長(zhǎng)的USSD消息的全部?jī)?nèi)容后，利用所述每個(gè)單條USSD消息的UDH字段中的序號(hào)標(biāo)識(shí)ID，將多個(gè)單條USSD消息重新組合成初始的USSD消息。
2.根據(jù)權(quán)利要求1的方法，其中所述USSD消息是指Operationtype為UnstructuredSS-Request、UnstructuredSS-Notify、或ProcessUnstructuredSS-Request的任意USSD消息。
3.根據(jù)權(quán)利要求1的方法，還包括在USSD消息中加入用戶數(shù)據(jù)頭指示位(UDHI)字段，其中UDHI字段可指示UDH字段的存在與否。
4.根據(jù)權(quán)利要求3的方法，其中UDHI的取值如下TRUE，表示ussd-String中含有UDH；FALSE，表示ussd-String中不包含UDH。
5.根據(jù)權(quán)利要求1的方法，其中所述USSD proceed消息還包括出錯(cuò)指示(proceed-Succeed)字段，用于指示接收端收到的上一條消息正確或錯(cuò)誤；消息標(biāo)識(shí)號(hào)(proceed-Index)字段，用于標(biāo)識(shí)接收端收到的上一條消息的ID號(hào)；當(dāng)所述出錯(cuò)指示字段指示所接收的單條消息正確時(shí)，發(fā)送方繼續(xù)發(fā)送下一個(gè)單條消息；以及當(dāng)所述出錯(cuò)指示字段指示所接收的單條消息錯(cuò)誤時(shí)，發(fā)送方根據(jù)所述消息標(biāo)識(shí)號(hào)字段所標(biāo)識(shí)的ID號(hào)重新發(fā)送所述出錯(cuò)的單條消息，或者按照現(xiàn)有的出錯(cuò)處理流程釋放本次連接。
6.根據(jù)權(quán)利要求1的方法，還包括當(dāng)拆分消息的發(fā)送方收到的USSD proceed消息本身是錯(cuò)誤消息時(shí)，發(fā)送方釋放此次交互。
7.根據(jù)權(quán)利要求1的方法，還包括當(dāng)移動(dòng)臺(tái)或網(wǎng)絡(luò)之一不支持所述多條拆分業(yè)務(wù)時(shí)，接收方不發(fā)送USSD Proceed確認(rèn)消息給發(fā)送方，該交互被釋放。
8.根據(jù)權(quán)利要求1的方法，所述用戶數(shù)據(jù)頭(UDH)字段位于ussd-String的頭部。
9.根據(jù)權(quán)利要求1的方法，所述用戶數(shù)據(jù)頭(UDH)字段至少包括如下之一UDHL字段，指示ussd-String中的用戶數(shù)據(jù)頭(UDH)的長(zhǎng)度；IEI字段，用于指示IE數(shù)據(jù)的類型；IEIDL字段，用于指示IE數(shù)據(jù)的長(zhǎng)度；IEID字段，用于指示IE數(shù)據(jù)的內(nèi)容。
10.根據(jù)權(quán)利要求9的方法，還包括將IE數(shù)據(jù)類型IEI設(shè)置為多條可拆分USSD指示位，以及IEID數(shù)據(jù)表示多條可拆分USSD消息的序號(hào)ID。
11.根據(jù)權(quán)利要求9的方法，其中相應(yīng)于IEI字段的數(shù)值，IE數(shù)據(jù)的類型還包括如下預(yù)定項(xiàng)的至少之一預(yù)定義聲音；自定義聲音；預(yù)定義圖片；大尺寸黑白圖片；小尺寸黑白圖片；預(yù)定義動(dòng)畫；大尺寸黑白動(dòng)畫；小尺寸黑白動(dòng)畫；格式定義；以及保留用途。
12.根據(jù)權(quán)利要求10的方法，還包括接收方在收到其IEI是多條可拆分USSD指示位的USSD時(shí)，表明多條可拆分的USSD的發(fā)送開始；在收到序號(hào)為0xFF的可拆分USSD時(shí)，接收方把之前收到的所有USSD的內(nèi)容組合后在待機(jī)界面顯示或者轉(zhuǎn)送給應(yīng)用程序處理。
13.一種基于3GPP USSD業(yè)務(wù)系統(tǒng)來發(fā)送USSD消息的改進(jìn)方法，所述方法包括如下步驟在ussd-String字段加入用戶數(shù)據(jù)頭(UDH)字段，所述UDH中包含了簡(jiǎn)單多媒體內(nèi)容；發(fā)送方發(fā)送所述具有UDH字段的USSD消息；接收方接收所述具有UDH字段的USSD消息，并提取所述UDH字段中的簡(jiǎn)單多媒體內(nèi)容。
14.根據(jù)權(quán)利要求13的方法，其中所述USSD消息是指Operationtype為UnstructuredSS-Request、UnstructuredSS-Notify、或ProcessUnstructuredSS-Request的任意USSD消息。
15.根據(jù)權(quán)利要求13的方法，還包括在USSD消息中加入用戶數(shù)據(jù)頭指示位(UDHI)字段，其中UDHI字段可指示UDH字段的存在與否。
16.根據(jù)權(quán)利要求13的方法，其中UDHI的取值如下TRUE，表示ussd-String中含有UDH；FALSE，表示ussd-String中不包含UDH。
17.根據(jù)權(quán)利要求13的方法，所述用戶數(shù)據(jù)頭(UDH)字段位于ussd-String的頭部。
18.根據(jù)權(quán)利要求13的方法，所述用戶數(shù)據(jù)頭(UDH)字段至少包括如下之一UDHL字段，指示ussd-String中的用戶數(shù)據(jù)頭(UDH)的長(zhǎng)度；IEI字段，用于指示IE數(shù)據(jù)的類型；IEIDL，用于指示IE數(shù)據(jù)的長(zhǎng)度；IEID，用于指示IE數(shù)據(jù)內(nèi)容。
19.根據(jù)權(quán)利要求18的方法，其中相應(yīng)于IEI的數(shù)值，IE數(shù)據(jù)的類型包括如下預(yù)定的簡(jiǎn)單多媒體內(nèi)容的至少之一預(yù)定義聲音；自定義聲音；預(yù)定義圖片；大尺寸黑白圖片；小尺寸黑白圖片；預(yù)定義動(dòng)畫；大尺寸黑白動(dòng)畫；小尺寸黑白動(dòng)畫；格式定義；以及保留用途。
全文摘要
本發(fā)明針對(duì)USSD現(xiàn)有業(yè)務(wù)的不足，在考慮與3GPP已有協(xié)議兼容的同時(shí)，提出對(duì)USSD信令層協(xié)議的補(bǔ)充協(xié)議，以擴(kuò)充USSD在現(xiàn)代移動(dòng)通信網(wǎng)絡(luò)中的功能范圍。對(duì)于USSD信令層協(xié)議的擴(kuò)充，主要基于以上所述之兩大需求進(jìn)行。一是將一條消息放不下的內(nèi)容放在多條消息中傳送，通過在ussd－String中增加UDH(User Data Header，用戶數(shù)據(jù)頭)字段，先在發(fā)送端分拆消息，利用UDH中定義的序號(hào)標(biāo)識(shí)和在接收端進(jìn)行重組。二在簡(jiǎn)單多媒體內(nèi)容的傳輸上，將簡(jiǎn)單的多媒體內(nèi)容放在UDH中進(jìn)行傳輸。
文檔編號(hào)H04W4/14GK101047879SQ20061002530
公開日2007年10月3日 申請(qǐng)日期2006年3月30日 優(yōu)先權(quán)日2006年3月30日
發(fā)明者胡慶 申請(qǐng)人:上海宇夢(mèng)通信科技有限公司