專利名稱：用于數(shù)據(jù)傳輸?shù)姆椒ê脱b置的制作方法
技術(shù)領域：
本發(fā)明涉及一種如權(quán)利要求1的前序部分所述的用于傳輸數(shù)據(jù)的方法，一種發(fā)送單元和/或接收單元，一種計算機程序產(chǎn)品和一種通信系統(tǒng)。在這種情況下，在本發(fā)明范圍內(nèi)數(shù)據(jù)還被理解為由各個組成部分組成的每類信息。在此，所述各個組成部分或單元可按不同標準構(gòu)成、組織和/或編碼。據(jù)此數(shù)據(jù)在該意義上也描述多媒體消息，其包含不同標準的各種不同單元。
用于傳輸不同形式或格式的數(shù)據(jù)的方法和裝置是公知的。按全球移動通信系統(tǒng)標準(簡稱為GSM)的移動無線電系統(tǒng)除了提供語音電話，當前也例如提供發(fā)送或接收長度直至160個字符的短文本消息的形式的信息的可能性。該業(yè)務也稱為短消息服務，簡稱SMS。
針對下一代移動無線電系統(tǒng)、通用移動通信系統(tǒng)UMTS，當前標準化移動消息業(yè)務的適合多媒體的變體、所謂的多媒體消息服務MMS被標準化。多媒體消息服務規(guī)定了用于將任意內(nèi)容從該服務的一個用戶通過網(wǎng)絡傳輸給另一個用戶的機制。
作為具有多媒體內(nèi)容的消息的信息在下文為了更好的界定SMS的文本消息還只稱為多媒體消息、簡稱MM。不同于SMS，在多媒體消息服務MMS處取消對純文本內(nèi)容的限制。在多媒體消息服務MMS中也可能，格式化對應于不同喜好的文本，以及將任意內(nèi)容嵌入消息中。例如音頻-和視頻內(nèi)容、狀態(tài)圖(standbilder)、圖畫、文本等等屬于此內(nèi)容。下面公開的教導通常指數(shù)據(jù)集合，該數(shù)據(jù)集合由具有或沒有聲音的文本數(shù)據(jù)和/或圖形數(shù)據(jù)的各個單元組成并分別按相同或不同標準來編碼，即使在按上述標準的應用中應看到針對本發(fā)明的實質(zhì)使用區(qū)域。
多媒體消息服務MMS的目前的規(guī)范基于第三代合作項目3GPP的兩個規(guī)范，該兩個規(guī)范一方面基本說明業(yè)務[1]而另一方面抽象地確定了具體的功能[2]。MMS的一種可能的實現(xiàn)在WAP論壇的三種規(guī)范中被說明[3、4、5]。據(jù)現(xiàn)有技術(shù)，MMS的實施通過無線應用協(xié)議WAP是可實現(xiàn)的。為了渡過適合MMS的終端設備與網(wǎng)絡側(cè)上的WAP網(wǎng)關(guān)之間的空中接口按照[5]規(guī)定WAP無線會話協(xié)議WSP[6]的使用。
本發(fā)明的任務在于，建議一種方法、一種發(fā)送單元和/或接收單元、一種計算機程序產(chǎn)品和一種通信系統(tǒng)，該通信系統(tǒng)給數(shù)據(jù)或消息的發(fā)送者提供另外的可能性，用于在更高靈活度時發(fā)送數(shù)據(jù)、在消息流的效率提高時或更好的利用各自傳輸信道的容量時匹配給定的通信系統(tǒng)。
根據(jù)本發(fā)明，所述任務通過具有權(quán)利要求1的特征的方法和具有權(quán)利要求16的特征的發(fā)送單元和/或接收單元來解決。此外，如權(quán)利要求18所述的計算機程序產(chǎn)品和具有權(quán)利要求20的特征的通信系統(tǒng)分別是所述任務的解決方案。從屬權(quán)利要求分別定義了本發(fā)明的優(yōu)選和有利的實施方案。
用于傳輸通信系統(tǒng)中的數(shù)據(jù)、尤其是用于傳輸具有或沒有聲音的文本數(shù)據(jù)和/或圖形數(shù)據(jù)的本發(fā)明的方法根據(jù)本發(fā)明由此突出，即進行用于從遞交消息的多個變體中確定選擇的標記，在該方法處待傳送的數(shù)據(jù)集合由分別按相同的或不同的標準編碼的各個單元組成。因此根據(jù)本發(fā)明可以使各自遞交的變體依賴于消息的類型和/或長度以及其他特性。
在本發(fā)明的一個方案中遞交的變體由發(fā)送者和/或也由MMS連接單元尤其是依賴于此來選擇，接收者是否在其本地網(wǎng)注冊或在作為本地網(wǎng)絡的另一個網(wǎng)中注冊。該工作情況也稱為“漫游”。對此針對外部網(wǎng)絡中數(shù)據(jù)通信量的成本可更好地被控制。此外所述或另一個新規(guī)定的遞交的變體也由MMS連接單元依賴于用戶優(yōu)先權(quán)或用戶簡檔(nutzerprofils)和/或用戶終端設備的特性和用戶終端設備上的MMS用戶應用來選擇。
在本發(fā)明的一個擴展方案中這樣整理用于發(fā)送的數(shù)據(jù)，該數(shù)據(jù)包含用于傳輸組織信息的頭和用于傳輸各自有用信息的本體。該有用信息在此優(yōu)選地包含多個數(shù)據(jù)包形式的單元。有利地為了將數(shù)據(jù)從一個用戶的用戶應用通過一個網(wǎng)絡傳輸給另一個用戶的用戶應用，在另一個用戶處該傳輸通過傳輸協(xié)議的交易和/或輸送數(shù)據(jù)的信息單元來控制，其中該信息單元包含一個字段名和各自的字段值。在此本發(fā)明方法優(yōu)選地針對數(shù)據(jù)尤其是在移動用戶終端設備或特定的適合WAP的移動電話形式的發(fā)送單元和/或接收單元上被采用，該數(shù)據(jù)作為多媒體消息服務MMS中的多媒體消息MM被傳輸。
目前作為本發(fā)明優(yōu)選的應用區(qū)域的多媒體消息服務MMS還只提供延遲遞交消息、所謂的延遲檢索與不延遲遞交消息、所謂的即時檢索之間的選擇。兩種變體之間的選擇可能性在此唯一地位于各自接收的用戶應用或接收者處。因此目前明顯不可能的是●由發(fā)送的用戶應用和/或MMS連接單元引起的立即遞交，●由發(fā)送的用戶應用和/或MMS連接單元引起的具有MMS接收者通知的消息的直接遞交，不用緊接著發(fā)送MMS遞交消息，其中所述可選地具有或沒有MMS遞交確認的消息是可實現(xiàn)的，以及●由發(fā)送的用戶應用和/或MMS連接單元引起的明顯沒有MMS接收者通知確認的MMS接收者通知。
所述三種通過本發(fā)明方法的實現(xiàn)才成為可能的遞交變體的應用情況是遞交非常短的消息、例如純文本消息，針對該遞交目前的遞交變體將花費十分高。另一種應用可能性是發(fā)送對具有MMS接收者通知的MMS的內(nèi)容之外的內(nèi)容的參閱。此處具有MMS遞交消息的其他MMS內(nèi)容的遞交不再是必需的。
此處根據(jù)本發(fā)明現(xiàn)在實現(xiàn)以下可能性，通過發(fā)送的應用和/或MMS連接單元以所定義的方式準確規(guī)定遞交的類型。本發(fā)明方法在此在通信系統(tǒng)的每個發(fā)送單元和/或接收單元中被采用，也就是例如中繼服務器和/或用戶終端設備中被采用。除了遞交的特殊類型通過縮減或節(jié)約遞交消息或接收確認來保護資參考資料并因此提高傳輸信道的效率，如下面關(guān)于附圖的映射根據(jù)具體實例詳細說明的那樣。
下面參考附圖根據(jù)優(yōu)選的實施例解釋本發(fā)明。圖中示出

圖1根據(jù)無線應用協(xié)議或WAP標準一方面在發(fā)送者層和供應商層之間而另一方面在供應商層和接收者層之間的屬于數(shù)據(jù)傳輸?shù)陌l(fā)送作為延遲遞交消息時的信令流圖或交易流圖的示意映射；圖2根據(jù)圖1的映射的針對不延遲遞交消息的信令流圖；圖3按照參考資料[4]在WAP中的MMS消息流圖，用于描述根據(jù)本發(fā)明新引入的并由發(fā)送者要求的強制檢索(Forced Retrieval)；圖4按照參考資料[4]在WAP中的MMS消息流圖，用于描述根據(jù)本發(fā)明新引入的沒有具有由發(fā)送者要求的確認的遞交的通知；圖5按照參考資料[4]在WAP中的MMS消息流圖，用于描述根據(jù)本發(fā)明新引入的沒有沒有由發(fā)送者要求的確認的遞交的通知；
圖6按照參考資料[4]在WAP中的MMS消息流圖，用于描述根據(jù)本發(fā)明新引入的沒有具有緊接著的延遲遞交消息的確認的通知；圖7根據(jù)本發(fā)明的新標題字段的編碼；圖8根據(jù)本發(fā)明的新標題字段與已經(jīng)在標準中定義的頭字段名一起編制的編碼；圖9以表格形式列表WAP消息M-Send.req的標題字段以及圖10按照參考資料[2]6.2描述MMS消息或WAP消息M-Notification.ind的內(nèi)容。
具有相同功能和作用方式的單元在圖1至10中分別連貫地采用同樣的參考標記。
在下面的實施例中說明本發(fā)明在針對WAP標準的數(shù)據(jù)傳輸方案1上的應用，如在尤其是圖形數(shù)據(jù)和格式化的文本數(shù)據(jù)的傳輸中在通用移動通信系統(tǒng)、簡稱UMTS標準中應用?？衫斫?，本發(fā)明也可在其他標準或移動無線電系統(tǒng)上以相應地方式傳輸。此處尤其是也指混合的通信系統(tǒng)，其除了移動無線電段之外還包含固定網(wǎng)連接及其他。
如開頭已經(jīng)說明的那樣，在UMTS標準中所規(guī)定的、附加于目前的短消息服務SMS針對消息、也稱為多媒體消息MM的傳輸規(guī)定所謂的多媒體消息服務MMS。因此具有和沒有聲音的格式化的文本和圖形也可被傳輸。取消SMS中存在的對160個字符的消息長度的限制。其中音頻-和視頻消息的傳輸是可能的，其中盡管如此以該系統(tǒng)內(nèi)適合的花費根據(jù)本發(fā)明處理經(jīng)常使用的SMS通知，如隨后的現(xiàn)有技術(shù)的說明所描述的那樣。
MMS是通過使用WAP實現(xiàn)的。在此，針對數(shù)據(jù)、如多媒體消息MM的無線電傳輸，在圖1的映射中示出的通信系統(tǒng)1按照無線會話協(xié)議方案WAPWSP被應用。圖1的映射示出按根據(jù)參考資料[4]的當前現(xiàn)有技術(shù)的消息流圖，其中描繪了在發(fā)送或接收MM時三個參與的實體之間的WAP消息的交換。該通信系統(tǒng)1包含數(shù)據(jù)發(fā)送者層2，該數(shù)據(jù)發(fā)送者也稱為MMS-用戶應用A或用戶代理A M-UA_A。MMS-用戶應用理解為例如移動無線電設備的應用，該應用實現(xiàn)MMS-功能。經(jīng)一步規(guī)定供應商層3，其網(wǎng)絡單元執(zhí)行該服務且以下稱為MMS連接單元或MMS中繼服務器M-SR。MMS-連接單元M-SR是在MMS業(yè)務提供商處的網(wǎng)絡單元，該網(wǎng)絡單元使得MMS用戶應用通過網(wǎng)絡通信成為可能。最后規(guī)定層4為接收者層，該接收者也稱為MMS用戶應用B M-UA_B。
當然可能，在層3中例如出現(xiàn)不只一個供應商。這例如由此可能的是，數(shù)據(jù)發(fā)送者M-UA_A和所選擇的接收者M-UA_B在不同的供應商處。此外不同的供應商還可通過作為網(wǎng)絡運營商的第三供應商相互連接?？墒谴颂庍x擇本簡化的描繪，因為層3中的準確結(jié)構(gòu)對于原則上的信令流程是不重要的。
圖1的映射相應地示出根據(jù)[2]當前現(xiàn)有技術(shù)的所謂的交易流圖，其中描繪了在發(fā)送或接收MM時只在三個參與的實體(MMS用戶代理AM-UA_A、MMS中繼服務器M-SR和MMS用戶代理B M-UA_B)之間WAP消息的交換。數(shù)據(jù)發(fā)送者層2至少包含一個用戶終端設備或電信設備5，同樣接收者層4也至少包含一個用戶終端設備或電信設備6。該電信設備5、6可例如構(gòu)造為通用的手機或構(gòu)造為具有其他輸入-或顯示功能的設備、如膝上型電腦，或構(gòu)造為所述兩類設備的結(jié)合。
現(xiàn)在解釋前述通信系統(tǒng)1中的各個信令的順序，該順序為了將MMS從MMS用戶代理A M-UA_A通過MMS中繼服務器M-SR發(fā)送給MMS用戶代理B M-UA_B是必需的。在所參與的單元之間交換具有消息的信息，該信息在圖1的映射中的消息流圖中用箭頭表示。在此一條消息基本上由一個標題或Header和可選地由數(shù)據(jù)部分、所謂的本體(Body)組成，該數(shù)據(jù)部分含有多媒體對象。消息流包含以下消息●M-SreqMMS-發(fā)送詢問，從發(fā)送的M-UA-A向MMS連接單元M-SR寄出，以為了向所述一個或多個接收者轉(zhuǎn)發(fā)MM的內(nèi)容而引起該MMS-發(fā)送詢問。
●M-SconfMMS發(fā)送確認，從MMS連接單元M-SR向發(fā)送的MMS用戶應用發(fā)送，以向發(fā)送的MMS-用戶應用傳送發(fā)送詢問的狀態(tài)。
●M-NindMMS-接收者通知，用于通知所尋址的MMS用戶應用，已經(jīng)備放著用于遞交的多媒體消息。
●M-NRindMMS-接收者通知確認，從所尋址的MMS-用戶應用向MMS連接單元M-SR寄出，以確認收到MMS接收者通知。
●W-GreqMMS-遞交詢問，從所尋址的MMS-用戶應用向MMS-連接單元M-SR發(fā)送，以引起多媒體消息的遞交。
●M-RconfMMS-遞交消息，從MMS-連接單元M-SR向所尋址的MMS-用戶應用發(fā)送，以傳輸用于MMS-用戶應用的多媒體消息。
●M-AindMMS-遞交確認，從MMS用戶應用向MMS-連接單元M-SR發(fā)送，以向MMS-用戶應用報告該多媒體消息的遞交狀態(tài)。
●M-DindMMS-遞交狀態(tài)通知，從MMS連接單元M-SR向發(fā)送的MMS-用戶應用發(fā)送并用于通知發(fā)送的MMS用戶應用，關(guān)于所遞交的消息的狀態(tài)。
在發(fā)送者M-UA_A的電信設備5中撰寫的或通過該設備轉(zhuǎn)發(fā)的多媒體消息MM可含有一個或多個單元或數(shù)據(jù)組，例如各個圖形、影片段、文本及其他。MM首先作為在WAP協(xié)議中名為M-Send.req的詢問發(fā)送向?qū)?中的供應商M-SR發(fā)送。從該處所輸入的發(fā)送向?qū)?的發(fā)送者M-UA_A回應回饋發(fā)送M-Sconf。按照WAP協(xié)議這稱為回饋發(fā)送M-send.conf。
接下來從供應商M-SR向?qū)?中的接收者M-UA-B發(fā)送信息M-Nind，利用該信息知道，針對其在供應商M-SR處為了下載備放著消息，按WAP協(xié)議稱為M-Notification.ind。
對此供應商M-SR例如自動含有回應的回饋通知M-NRind或M-NotifyResq.ind根據(jù)WAP標準由接收者M-UA-B的電信設備6從層4發(fā)送回層3。
在由接收者利用發(fā)送W-Greq或相應的WSP GET.req提出要求之上供應商M-SR才利用向接收者M-UA-B發(fā)送M-Rconf或M-retrieve.com轉(zhuǎn)發(fā)MM。在層4中消息M-Aind或M-Acknowledge.ind回應MM的接收。結(jié)束消息M-Dind或M-Delivery.ind將接收確認從層3向?qū)?中的發(fā)送者M-UA-A回復。
為了管理前述發(fā)送應用所謂的標題字段，也就是真正的MM和/或前置各個單元的字段，其中可包含關(guān)于來參考資料、發(fā)送時間、文件大小和其他細節(jié)的信息。目前多媒體消息服務MMS只提供按圖1所示的延遲遞交消息、所謂的延遲檢索與不延遲遞交消息、所謂的即時檢索之間的選擇。消息的未延遲遞交類似于圖1的描繪在圖2中繪出。此處與此對應地缺少MMS接收者通知確認M-NRind，因為MMS遞交詢問W-Greq被立即發(fā)出。此處兩種變體之間的選擇可能性唯一地位于接收的用戶應用M-UA_B處。
由發(fā)送的用戶應用M-UA_A引起的立即遞交因此同樣很少可能，如由發(fā)送的用戶應用引起的具有MMS接收者通知的消息的直接遞交一樣，不用緊接著發(fā)送MMS遞交消息。針對這兩種遞交變體的應用情況是遞交十分短的文本消息、例如以喜歡的SMS的形式，針對該形式目前的遞交變體將花費十分高。其他的應用可能是發(fā)送對具有MMS-接收者通知的MMS的內(nèi)容之外的內(nèi)容的參閱。此處具有MMS-遞交消息的其他MMS-內(nèi)容的遞交將不再必需。
根據(jù)本發(fā)明通過在多媒體消息服務MMS的協(xié)議中引入一個新的信令單元完成一個相應的擴展。據(jù)此在MMS規(guī)范中為了按參考資料[5]編碼MMS的消息引入標題字段形式的一個新的信令單元，即如圖7中給出的字段“X-Mms-檢索模式(X-Mms-Retrieval-Scheme)”。利用該單元發(fā)送的MMS-用戶應用可直接影響用于MM的遞交的消息流。根據(jù)本發(fā)明該新的信令單元提供下列值，該值在圖7的描繪中被總結(jié)為●作為標準預先規(guī)定的接收者判定(Recipient’s-decision)該值說明當前的現(xiàn)有技術(shù)所接收的MMS-用戶應用可在延遲檢索和即時檢索之間選擇。在此值“接收者判定(Recipient’s-decision)”如上述描述了現(xiàn)有技術(shù)并為了通過M-UA_B的目前的選擇可能只用于反向兼容。
●作為強制的、立即遞交的類型的強制檢索(Forced-retrieval)該值說明由發(fā)送的MMS-用戶應用或MMS-連接單元M-SR要求的向接收的MMS-用戶應用立即遞交MM。在接收該信令時接收的MMS-用戶應用應立即通過向MMS-連接單元M-SR發(fā)送MMS-遞交詢問來引起多媒體消息的遞交，如圖3的映射中的那樣，通過缺少MMS接收者通知確認M-NRind來指出。在此應不發(fā)生用戶的交互作用。在此消息流對應于圖2中所描繪的即時檢索。
●具有確認的通知(Notification-only-with-acknowledgement)，具有確認的直接遞交其用于，當約只應傳送SMS消息或?qū)ν獠績?nèi)容的參閱時，遞交具有MMS-接收者通知的多媒體消息的整個內(nèi)容，這優(yōu)選地在MM的不豐富的內(nèi)容處應用。接收的MMS-用戶應用利用具有MMS接收者通知確認的遞交變體的信令答復MMS-接收者通知的接收。這明確地沒有進行MMS-遞交詢問。最終MMS-遞交狀態(tài)通知從MMS-連接單元向發(fā)送的MMS-用戶應用根據(jù)現(xiàn)有技術(shù)被寄出。相應的信令流程在圖4的映射中再現(xiàn)。
●沒有確認的通知(Notification-only-without-acknowledgement)，也就是沒有確認的直接遞交其實質(zhì)上對應于以前說明的遞交變體?？墒桥c此不同的是，也取消了MMS-接收者通知確認并因此也取消了可選的MMS-遞交狀態(tài)通知。整個消息流已經(jīng)在所進行的MMS-接收者通知之后結(jié)束。因此該遞交變體是具有最少被交換的消息的遞交變體并因此特別適用于諸如實體消息或SMS消息的短消息。該實施方案的相應的信令流程在圖5的映射中再現(xiàn)。
●沒有確認的接收者判定(Recipient’s-decision-without-acknowledgement)，該遞交可按接收者的選擇或者直接地(immediate)或者延遲地(deferred)進行。在延遲遞交時接收的用戶應用應不發(fā)送MMS-接收者通知確認M-NRind。當MMS-接收者通知確認的發(fā)送分別歸因于所接收的用戶應用或用戶時，這譬如可是這種情況，即在作為本地網(wǎng)絡的另一個網(wǎng)絡中發(fā)生傳送時，就像在所謂的漫游的情況中一樣，這是尤其有利的。MMS-連接單元M-SR在這種情況下可通過將此處所建議的信息嵌入到MMS-接收者通知中來引起接收的MMS-用戶應用的相應特性。
取代前述的遞交變體的顯式信令按照一個未繼續(xù)執(zhí)行的建議借助針對已經(jīng)存在的標題字段所定義的值一個隱式信令也將是可能的。對此例如可在標題字段X-Mms-內(nèi)容位置(X-Mms-Content-Location)中應用簡化的統(tǒng)一資源標識符(簡稱URI)“Notification.only.without.acknowledgement@MMS.org”。但是該解決方案只在以下變體中起作用，該變體得沒有MMS-接收者遞交消息。所有其他變體最終要求實際上在MMS-遞交詢問中待使用的所謂的內(nèi)容位置(Content-Location)的傳輸，也就是參考MMS連接單元的管轄范圍中的消息。
關(guān)于圖7的描繪所說明的本發(fā)明的優(yōu)點是提高的使用MMS的靈活性、提高的發(fā)送MMS-用戶應用的影響可能性和更有效的使用系統(tǒng)的單元之間的接口尤其是在傳輸不豐富的文本-或SMS-消息時，由此MM的內(nèi)容不再強制性地利用MMS-遞交消息來傳送，而且可為此目的使用總之必要的MMS-接收者通知，其中完全取消MMS-遞交消息。具有當前標準的結(jié)構(gòu)一致的擴展的本發(fā)明方法的實質(zhì)優(yōu)點在于提高以下可能，更靈活地和更有效地使用多媒體消息服務。一方面發(fā)送的MMS-用戶應用可要求接收的用戶應用不可延遲地下載MMS-連接單元的消息，另一方面在不豐富的多媒體消息的內(nèi)容處實現(xiàn)縮短的并因此更有效的消息流。此外由MMS-連接單元M-SR發(fā)出信令表示對MMS-接收者通知確認的放棄并因此減少空中接口上的流量，這在一定條件下使得該業(yè)務的客戶友好的結(jié)算成為可能。
現(xiàn)在在下面的實施例中，該實施例基于由WAP論壇定義的在MMS中交換的消息的二進制編碼，在MM的頭部顯示利用信令單元X-Mms-檢索-模式(X-Mms-Retrieval-Scheme)標記的可能性。
在此例如假設下列情形MMS-用戶應用A M-UA_A向MMS-用戶應用B M-UA_B寄發(fā)具有短文本的多媒體消息，該文本含有對網(wǎng)址的參閱。發(fā)送者針對沒有確認的直接遞交決定。
下列消息在所述單元之間傳輸。
MM向收件者遞交。
M-Sreq(M-UA A→M-SR)X-Mms-Message-Typem-send-reqX-Mms-Transaction-IDTRANSACTION-ID#1X-Mms-Version1.0DateTue，22 May 2001 11:11:11 +0200FromNutzerA@SP-A.deToNutzerB@SP-B.deSubjectHi NutzerB，schau doch mal auf meine neue Homepage(http://www.NutzerA.de)！MfG，NutzerA；-)X-Mms-Retrieval-SchemeNotification-only-without-acknowledgementContent-Type*/*本發(fā)明的新的遞交變體通過新的信令單元“X-Mms-Retrieval-SchemeNotification-only-without-acknowledgement”來編碼。按現(xiàn)有技術(shù)規(guī)定的字段內(nèi)容類型設為值“*/*”。
按現(xiàn)有技術(shù)MMS用戶代理A的發(fā)送詢問(在WAP中稱為M-Send.req)回應M-SR的消息M-Sconf(在WAP中M-Send.conf)。在本發(fā)明的本實施方案的范圍內(nèi)該消息不被修改并因而不在此處提及。
在MMS中按參考資料[1、2]規(guī)定，通知MMS用戶一條新消息，該消息針對該用戶存在并準備用于下載。接收者通知M-Nind(在WAP中M-Notification.ind)滿足該目的。在該實例中向接收者用戶B發(fā)送一條通知。
M-Nind an NutzerB(M-SR->M-UA-B)X-Mms-Message-Typem-notification-indX-Mms-Transaction-IDTRANSACTION-ID#2X-Mms-Version1.0FromNutzerA@SP-A.deSubjectHi NutzerB，schau doch mal auf meine neue Homepage(http://www.NutzerA.de)！MfG，NutzerA；-)X-Mms-Message-ClassPersonalX-Mms-Message-Size0X-Mms-Expiry0X-Mms-Retrieval-SchemeNotification-only-without-acknowledgement除了通用字段接收者通知也包含新的單元X-Mms-檢索-模式(X-Mms-Retrieval-Scheme)。此外應注意，不再有消息由MMS-連接單元下載。消息大小(Message-Size)的所規(guī)定的說明或者取消、這按照現(xiàn)有技術(shù)當前是不可能的，或者如實例中一樣設為零。
同樣的情況適用于字段X-Mms-屆滿(X-Mms-Expiry)，該字段在正常的應用情況中通過MMS-連接單元M-SR說明消息存儲的持續(xù)時間。如果沒有下載消息就涂去所述時間，則該消息在服務器上失效。該字段在采用沒有MMS-遞交消息的遞交變體時是沒有意義的。此處也存在以下可能，可選地做出該字段并在這種情況下扔掉，或者針對此處說明的情況規(guī)定一定的值-譬如零。最后的可能性如上所述。
利用該消息整個消息流已經(jīng)結(jié)束。其他在MMS中通用的消息可因此為了有效地發(fā)送數(shù)據(jù)通信量被分攤到該傳輸信道。
多媒體消息服務MMS規(guī)定用于將任意內(nèi)容從該服務的一個用戶通過一個網(wǎng)絡傳輸?shù)搅硪粋€用戶的機制，其中可十分靈活地采用該消息的針對消息傳輸可使用的信息單元、標題字段?？偠灾糜谥С钟形Φ膽每赡苄缘那笆龅牟煌赡軐τ诟鞣N已經(jīng)公知的消息類型也在MMS中介紹，其中該消息流的效率有利地由此改善，即根據(jù)本發(fā)明放棄在前述情況中不必要的消息。目前說明的不同消息流針對多媒體內(nèi)容的傳輸而開發(fā)并針對短消息的傳輸-如約短消息服務SMS的消息的傳輸-或其他參考資料的參閱沒有優(yōu)化，就是說譬如參考互聯(lián)網(wǎng)網(wǎng)頁，該網(wǎng)頁可接著利用外部應用被調(diào)用，例如利用互聯(lián)網(wǎng)瀏覽器來調(diào)用。本發(fā)明使得針對公知的和新的數(shù)據(jù)格式的結(jié)構(gòu)一致的列入公知的消息流以匹配的形式與各自優(yōu)點的使用一起成為可能。
尤其是在下面總結(jié)對WAP和MMS的背景說明[1]3G TS 22.140 version 4.1.0，Release 4；Third GenerationPartnership Project；Technical Specification Group Termi-nals；Multimedia Messaging Service(MMS)；Service As-pects；Stage 1，2001.3G TS 23.140 version 4.2.0，Release 4；Third GenerationPartnership Project；Technical Specification Group Termi-nals；Multimedia Messaging Service(MMS)；Functional De-scription；Stage 2，2001.WAP-205-MMS Architecture Overview，Approved Specifica-tion；Wireless Application Protocol，Multimedia MessagingService；Architecture Overview Specification，2002.WAP-206-MMS Client Transactions，Approved Specification；Wireless Application Protocol；WAP Multimedia MessagingService Client Transactions；2002.WAP-209-MMSEncapsulation，Approved Specification；wire-less Application Protocol；Multimedia Messaging Service；Message Encapsulation；2002.WAP-203-WSP，Specification，Approved Version，WirelessApplication ProtocolWireless Session Protocol；2000
權(quán)利要求
1.方法，用于傳輸通信系統(tǒng)中的數(shù)據(jù)，尤其是用于傳輸具有或沒有聲音的文本和/或圖形數(shù)據(jù)，其中待傳送的數(shù)據(jù)集合由各個單元組成，該單元分別按相同的或不同的標準編碼，其特征在于，進行用于從遞交消息的多個變體中確定選擇的標記。
2.如權(quán)利要求1所述的方法，其特征在于，這樣整理用于發(fā)送的數(shù)據(jù)，該數(shù)據(jù)優(yōu)選地以多個數(shù)據(jù)包的形式包含用于傳送組織信息的頭和用于傳送各自的有用信息的本體作為單元
3.如上述兩個權(quán)利要求之一所述的方法，其特征在于，所述數(shù)據(jù)作為多媒體消息(MM)在多媒體消息服務(MMS)中被傳輸。
4.如上述權(quán)利要求所述的方法，其特征在于，所述數(shù)據(jù)在移動用戶終端設備上傳輸、尤其是適合WAP的移動電話上傳輸。
5.如前述權(quán)利要求之一所述的方法，其特征在于，除了所述不延遲遞交消息或延遲遞交消息至少發(fā)出信令表示下列遞交變體之一-強制的、立即遞交(Forced-retrieval)，-具有確認的直接遞交(Notification-only-with-acknowledgement)和/或-沒有確認的直接遞交(Notification-only-without-acknowledgement)。
6.如前述權(quán)利要求之一所述的方法，其特征在于，發(fā)出信令表示沒有MMS-接收者通知確認的接收者方所選擇的遞交(Recipient’s-decision-without-acknowledgement)。
7.如上述權(quán)利要求所述的方法，其特征在于，發(fā)出信令表示所述不延遲遞交消息或延遲遞交消息作為標準化的預調(diào)節(jié)(Recipient’s-decision)。
8.如前述權(quán)利要求之一所述的方法，其特征在于，為了標記完成一個附加的標題字段。
9.如上述權(quán)利要求所述的方法，其特征在于，信令通過一個新的數(shù)據(jù)單元或一個附加的標題字段(X-Mms-Retrieval-Scheme)來進行。
10.如上述兩個權(quán)利要求之一所述的方法，其特征在于，字段名的編碼和/或字段值的編碼被執(zhí)行。
11.如上述兩個權(quán)利要求之一所述的方法，其特征在于，所述關(guān)于標題字段的信令在WAP中如下進行字段名X-Mms-Retrieval-Scheme的編碼為0x1F或者各自遞交變體的信令通過針對該標題字段X-Mms-Content-Location所定義的值來進行。
12.如上述權(quán)利要求所述的方法，其特征在于，在消息MMS-發(fā)送詢問(M-Send.req)和MMS-接收者通知(M-Notification.ind)中新的信令得到應用。
13.如前述權(quán)利要求之一所述的方法，其特征在于，附加的標題字段(X-Mms-Retrieval-Scheme)的值的編碼作為如下來進行-Recipient′s-decision(default)＝<Octet 128>，-Forced-retrieval＝<Octet 129>，-Notification-only-with-acknowledgement＝<Octet 130>，-Notification-only-without-acknowledgement＝<Octet 131>und/oder-Recipient′s-decision-without-acknowledgement＝<Octet 132>.
14.如前述權(quán)利要求之一所述的方法，其特征在于，MMS-連接單元(M-SR)將信令根據(jù)前述權(quán)利要求嵌入多媒體消息(MM)中。
15.如上述權(quán)利要求所述的方法，其特征在于，MMS-連接單元(M-SR)將依賴于接收者的用戶簡檔、接收的MMS-用戶應用和移動用戶終端設備的特性和/或依賴于所述網(wǎng)絡的信令嵌入到MMS-接收者通知，在該網(wǎng)絡中所述移動用戶終端設備注冊。
16.用于傳輸和/或描繪具有或沒有聲音的文本數(shù)據(jù)和/或圖形數(shù)據(jù)形式的數(shù)據(jù)的發(fā)送單元和/或接收單元，該數(shù)據(jù)作為待傳送的數(shù)據(jù)集合的單元按照相同的或不同的標準被編碼，其特征在于，構(gòu)造發(fā)送單元和/或接收單元用于轉(zhuǎn)換如前述權(quán)利要求之一所述的方法并尤其是構(gòu)造為用戶終端設備。
17.如上述權(quán)利要求所述的發(fā)送單元和/或接收單元，所述發(fā)送單元和/或接收單元構(gòu)造為移動電話，尤其是按照UMTS標準。
18.計算機程序產(chǎn)品，該計算機程序產(chǎn)品包含計算機可讀的存儲介質(zhì)，在該介質(zhì)上存儲一個程序，該計算機程序產(chǎn)品使得數(shù)據(jù)處理裝置或計算機可能，在該程序被加載到該計算機的存儲器中之后，在通信系統(tǒng)和尤其是移動無線電網(wǎng)絡中的數(shù)據(jù)傳輸內(nèi)為待傳輸?shù)臄?shù)據(jù)按照預先規(guī)定通過發(fā)送者進行單元的標記，以從向接收者遞交消息的多個變體中確定選擇。
19.如上述權(quán)利要求所述的計算機程序產(chǎn)品，其特征在于，該程序產(chǎn)品在移動無線電網(wǎng)絡中發(fā)送數(shù)據(jù)時執(zhí)行如權(quán)利要求1至15之一所述的一種方法。
20.通信系統(tǒng)其特征在于，至少所述通信系統(tǒng)的一個部件、尤其是一個MMS-連接單元(M-SR)被構(gòu)造來用于轉(zhuǎn)換如權(quán)利要求1至15中的一個或多個所述的一種方法和/或包含如權(quán)利要求16至17之一所述的發(fā)送單元和/或接收單元和/或含有如權(quán)利要求18至19之一所述的計算機程序產(chǎn)品或其使用。
全文摘要
本發(fā)明涉及一種如權(quán)利要求1的前序部分所述的用于傳輸數(shù)據(jù)的方法、一個用戶終端設備、一個計算機程序產(chǎn)品和一個通信系統(tǒng)。為了建議一種方法、一個用戶終端設備、一個計算機程序產(chǎn)品和一個通信系統(tǒng)，該通信系統(tǒng)給數(shù)據(jù)或消息的發(fā)送者另外的可能性用于在更高靈活度時發(fā)送數(shù)據(jù)、用于匹配在改善了消息流的效率時所給出的通信系統(tǒng)，建議，進行用于從遞交消息的變體中確定選擇的標記。因此根據(jù)本發(fā)明可能的是，使各自的遞交變體依賴于消息的類型和/或長度和其他特性。
文檔編號H04L12/58GK1656756SQ03811852
公開日2005年8月17日 申請日期2003年5月9日 優(yōu)先權(quán)日2002年5月24日
發(fā)明者C·沃茨施克, R·普倫策爾, B·耶爾比, M·特勞伯格, A·施密德特 申請人:西門子公司