專利名稱：：在傳輸消息時擴充信息流的方法、裝置和軟件程序的制作方法
技術領域：
：本發明涉及在經由移動無線網絡、尤其是經由一個UMTS網絡傳輸尤其是多媒體消息的消息時擴充信息流的方法，和相應的裝置和軟件程序。
背景技術：
：除了語音電話，移動無線系統GSM(GSM-全球移動通信系統)還提供發送和接收160字長以內的文本短消息的可能性。該業務叫做SMS(SMS-短消息業務)。在GSM03.40版本7.4.0、1998年版；數字蜂窩電信系統；短消息業務(SMS)的技術實現中可以找到更準確詳細的資料。對于下一代UMTS(UMTS-通用移動電信系統)移動無線系統，現在正在標準化另一種移動消息業務，其具有多媒體功能性，叫做MMS(MMS-多媒體消息業務)，參見3GPPTS22.140版本4.3.0笫4版；第三代合伙項目；集群業務和系統方面的技術規范；業務方面；第1階段；多媒體消息業務(MMS)，也可參見3GPPTS23.140版本4.3.0第4版；笫三代合伙項目；群終端的技術說明；多媒體消息業務(MMS);功能性描述；第2階段。具有多媒體內容的消息在下文被僅僅稱為短MMs(MM-多媒體消息，詞尾s表示復數)，為的是與SMS的文本消息更好地區分開。與SMS相比，這里不再有純文本內容的限制。MMS將允許根據個人品位定制文本，允許將音頻和視頻內容嵌入消息中。圖1示出了從3GPP(第3代合伙項目)角度看的在現有技術基礎上MMS的網絡體系結構。MMS用戶代理(縮寫UA)可被理解為例如位于移動無線電話上、或位于與移動無線電話相連的且實現MMS的設備上(譬如膝上型電腦，或類似的)的應用。發送消息的應用在下文被稱作發送應用，它在特定的MMS代理A中(在此縮寫為UAA)，而進行接收的應用4皮稱作接收應用，它在特定的MMS用戶代理B中(在此縮寫為UAB)。如圖1所示，發送應用UAA1采用空中接口-記為MM1-通過無線網絡7發送一個MM到網元5，該網元5被記為MMS中繼/服務器A(在此縮寫為RSA;以下MMS中繼/服務器縮寫為RS)，其在MMS業務提供商3(MMS業務提供商)的職責范圍內、也即所謂的"MMSE"(MMSE-多媒體消息業務環境)內為UAs提供MMS功能性。然后利用MM4接口把消息傳送給被記為MMS中繼/服務器B(縮寫為RSB)的網元6，該網元6位于接收側MMS業務提供商4(MMS業務提供商B)的職責范圍內，業務提供商4再利用MM1接口通過無線網絡8向接收應用UAB2發送消息。圖1示出了發射側網元RSA1和接收側網元RSB2是不同的的一般情況。然而現有技術中已經知道只包括一個MMSE的特殊情況，同樣，實際上并不需要MM1接口一定是空中接口的形式。在上述發射側和接收側RSs相同的特殊情況下，在以上3GPPTS23.140版本4.3.0、第4版中所描述的MMS的一個特征是所謂的"應答-計費"，在此基礎上，始發方發送一條MM來表示它準備接受來自接收方的應答-消息的費用，尤其是多媒體應答(應答-MM)。在此，始發方此外還可以規定時限。如果帶有相應的應答計費-標識的MM提供在網元RS上給接收方下載，則首先通知接收方，然后下載這條MM到它的終端。此時，在通知中和在下載MM時都告訴所述的接收方其可以免費地對該所謂的"始發-MM"發送一條應答-消息。如果他想利用這一點，則只需要將一條在他的終端上編譯的MM標識為前一個接收的始發MM的應答-MM，并將其發送出去。迄今只在MMSE中定義了應答計費-功能性。具體的描述可以在3GPPTS23.140版本4.3.0，第4版附錄E中找到。為發送MM而需要的所有信息同樣象應答計費-功能性的補充信息一樣被作為信息元素而錄入到在3GPPTS23.140版本4.3.0、第4版所定義的抽象消息中。如果參與數據交換的設備(應用UA或網元RS)不識別信息元素，則該信息元素將被不變地進行傳送。這種特性對于應答計費-功能性可能是有問題的，因為上述的應答計費-功能性只有在參與數據交換的所有設備(即UAs和RS)都支持應答計費-功能性時才基于現有技術進行工作。譬如，如果只有發送應用UAA和接收應用UAB都支持應答計費-功能性，而所參與的網元RS不支持(可能是因為它支持一個老的MMS版本)，那么網元RS將不能識別應答-MM,甚至也不能拒絕它，也就是說，應答-MM的始發方(-始發-MM的接收方)仍錯誤地認為他所發送的應答-MM的費用將被接收方(=始發-MM的始發方)接受。在標準化委員會3GPP和WAP的論壇中，既沒有公開一種方法來解決以上所述的兼容問題(網元RS不支持應答計費-功能性)，也沒有公開一種解決方法來把應答計費-功能性擴大到多個MMSE。對于其它相似的情況也存在上述問題，其中，始發方請求業務提供商提供特殊的功能性，而發送方和/或接收方不知道在一個或多個業務提供商的職責范圍內所相應參與的網元是否支持所請求的功能性。例如考慮今后在MMS中引入其它新的功能性-如"MMS的回叫"-，這些功能性雖然得到發送和接收單元的支持，但可能不受所參與的網元的支持。現有技術的另一個問題在于，含有應答-計費-指示的始發-消息的始發方不能防止接收方給他發送回過長的、因而非常昂貴的應答-消息。
發明內容本發明的目的在于，當發送/接收一條消息而該消息包舍有在業務提供商職責范圍中所參與的網元的特定功能性的請求時，使信息傳輸對用戶更友好。就方法而言，該目的是這樣實現的，即本發明的第一個方面通過獨立權利要求l的特征，本發明的第二個方面通過獨立權利要求11的特征，以及本發明的第三個方面通過獨立權利要求13的特征來實現。就裝置而言，該目的是通過權利要求17到20的特征來實現的。就軟件程序而言，該目的是通過權利要求21和22的特征來實現的。本發明以如下方式解決了在現有技術所產生的兼容問題，即根據本發明的笫一個方面，在參與數據交換的設備之間傳輸所述的信息，以支持所請求的、發射側和/或接收側網元的應答計費-功能性。在此處的第一種情況下，發射側和接收側網元、即尤其是MMS業務提供商的職責范圍內的相關網元RS是相同的。根據本發明，尤其把涉及相關網元的應答的信息傳送到接收應用。同樣，給發送應用的確認也是本發明的一部分。在發送和/或接收應用的那一方接收該信息同樣也是本發明的組成部分。基于笫一方面，本發明還允許對所請求的功能性進行擴充，也即譬如應答計費-功能性或在始發方請求回叫時的消息回叫-功能性，也利用需要不同MMS業務提供商的MMS(即在兩個MMSE之間)的發送應用和接收應用。通過傳送附加的數據-即關于網元RS支持或是否支持所請求的功能性的信息-，當在兩條子鏈路上從發射側網元RS(始發方的MMS中繼/服務器)向接收側網元RS(接收方的MMS中繼/服務器)、或從接收側網元RS向接收應用UAB傳送MM時，也允許在不同的MMSE之間所請求的功能性，并解決了上逸的兼容問題。因此，通過傳送如下信息，即網元RS是否支持所請求的功能性以作為對子鏈路上從網元RS向接收應用UAB發送MM的直接反應，便可以顯著地提高有關功能性的靈活性。基于第二方面，本發明提供了這樣的可能性，即當發射側和接收側網元不同時，從發射側網元可以向接收側網元傳送附加的信息，尤其是給接收方指示出可以進行應答計費的指示、應答計費的標識碼-其優選地對應于始發-消息的標識碼-、用于應答始發-消息的時限和/或應答-消息的最大允許長度。基于本發明的第三方面，通常規定始發方可以在應答計費時給出應答-消息大小的最大限制。例如利用多個上限可以做到這一點，由始發消息的始發方從中選擇一個。作為選擇方案，始發方可以確定其自己選定的、應答-消息的最大長度。這樣，始發方就保證了應答-消息將不會產生超過始發方自己選定的費用。除了這些方法外，本發明還涉及一些相應參與的裝置，即帶有相應控制單元的網元，還涉及一些采用相應接收和/或發送應用的移動無線用戶設備。在此，這些應用-如上已述-是直接安裝在移動無線電話上，還是安裝在膝上型電腦、筆記本或同類設備上，這并不重要。概念"移動無線用戶設備"也覆蓋了這些實施方案。此外，相應的軟件程序也是本發明的一部分。下面參照附圖進一步解釋本發明，其中圖1示出了依照3GPP規范的MMS網絡體系結構；圖2示出了只利用一個網元RS從發送應用(UAA)向接收應用(UAB)發送MM的情況下的事務流程圖3示出了利用兩個網元(RSs)從發送應用(UAA)向接收應用(UAB)發送MM的情況下的事務流程圖，和圖4示出了在WAP中利用兩個網元(PRs)從發送應用(CA)向接收應用(CB)發送MM的情況下的事務流程圖。具體實施例方式下面將借助特定的功能性"應答-計費"來以例子講述，如何在MMSE內利用MM1接口上的附加信息交換來解決上面提到的兼容問題(情形l)。接下來介紹了覆蓋一般情況的本方法的擴展，其中在不同的MMS業務提供商的兩個不同MMSEs之間交換MMs(情形2)。在此，變化不僅涉及到MM1接口而且還涉及MM4接口。最后，針對被實施為空中接口的WAP(WAP-無線應用協議)接口MM1而講述了在一般情形2(在兩個MMSE間的MMs交換)中所述的方法的一種可能實現。I.情形l:單個MMSE中的應答計費首先，借助圖2考慮這樣的情況，即發送應用UAA1(MMS用戶代理A)和接收應用UAB2(MMS用戶代理B)都使用同一個MMS業務提供商的MMS，即MM僅在一個MMSE內傳送，圖2示出相關的符合3GPP的"事務流程圖，，，其中給出了在3GPPTS23.140版本4.3.0、第4版中定義的抽象消息。由A用戶建立MM，標識其為"應答-計費"，并利用抽象消息N1(MM1—提交.REQ)通過MM1接口將其發送到他的MMS業務提供商的MMSE中的網元RS。該RS是一個發射側網元，同時也是接收側網元，因此被標識為兩個不同的參考符號5和6(參看圖1)。網元RS5,6利用抽象消息N2(MM1一提交.RES)確i人正確接收來自發送應用UAA1的MM,并利用抽象消息N3(MM1—通知.REQ)把準備下載的MM通知給接收方B。抽象消息N4(MM1—通知.RES)只是被用作接收應用UAB2正確接收到該通知的確認。抽象消息N5(MM1—檢索.REQ)可以被用戶B用來啟動下載一條在網元RS5，6上提供的MM。網元RS5，6利用抽象消息N6(MM1—檢索.RES)發送MM到接收應用UAB2。然后利用抽象消息N7(MM1—確認.REQ)進行確i人。根據本發明，如果網元RS支持所請求的應答計費-功能性，則網元RS增加另一個信息元素到兩個抽象消息N3(MM1一通知.REQ=通知MM)和/或N6(MM1—檢索.RES-發送MM)中。例如新的信息元素可以稱為"應答-計費-支持"。它指示了網元RS(或更一般地MMS業務提供商)是否支持應答計費-功能性。表1和2示出了發明的補充項，即在抽象消息N3(MM1—通知.REQ)和N6(MM1—檢索.RES)中的新信息元素"應答-計費-支持"，它在兩種情況下被優選地插入到已知的信息元素"應答-計費，，之后。<table>tableseeoriginaldocumentpage11</column></row><table>表l:按照情形1在抽象消息N3(MM1—通知.REQ)和N6(MM1檢索.RES)中增加的信息元素。不支持所請求的應答計費-功能性的網元RS優選繼續不變地傳送其未知的所有信息元素，而不補充信息元素"應答-計費-支持"。這樣，接收方的接收應用UAB便能識別在它的MMS業務提供商的MMSE中是否支持應答計費-功能性，并相應地作出反應。也就是說，只有當抽象消息N3(MM1—通知.REQ)和/或N6(MML檢索.RES)中存在所述由網元RS設定的信息元素"應答-計費-支持"時，始發-MM的接收方才能在發送被適當標識的應答-MM時確信MMS業務提供商支持應答計費-功能性。為提高應答計費-功能性的靈活性，以上重新定義的信息元素"應答-計費-支持"優選地也被插入到抽象消息N2(MM1—提交.RES)中，以用于在網元RS發送MM后來確認正確地接收到它(參見圖2)。這樣，在發送包含應答計費-標識符的始發-MM之后，可以通知發送應用UAA1關于MMS業務提供商是否支持請求的應答計費-功能性，正如在發送帶有相應標識的應答-MM之后的接收應用UAB2—樣。表2示出了抽象消息N2(MM1—提交.RES)中增加的信息元素"應答-計費-支持"，該信息元素被優選地插入到已知的信息元素"消息ID之后。信息元素存在狀態注釋"應答-計費-支持"可選MMS業務提供商支持應答計費-功能性的信息表2:按照情形1在抽象消息N2(MM1—提交.RES)中增加的寸息元素。II.情形2:兩個不同MMSE之間的應答計費以下來考慮這種情況，即發送應用UAA和接收應用UAB使用不同的MMS業務提供商的MMS，也就是說在兩個MMSE間傳送一條包含應答計費-標識符的MM。在這種情況下，只有除發送和接收應用以外發送方的網元RSA和接收方的網元RSB也都支持應答計費-功能性，那么應答計費才正常工作。在此，本發明通過在傳輸MM時伴隨傳輸附加信息來解決不同MMSE之間的應答計費時的兼容問題，該附加信息指示了相應的網元(RSA，RSB)是否支持應答計費-功能性。圖3示出了圖2的事務流程圖的相應擴展。除在那兒所示的抽象消息之外，圖3在此還示出了用于MM4接口(也參見圖1)的抽象消臺依照圖3，由用戶A建立一條MM，標識其為"應答-計費，，，并通過MM1接口將其發送到他的業務提供商A的MMSE中的網元RSA5。依照本發明，如果MMS業務提供商A支持所請求的應答計費-功能性，則由網元RSA5在抽象消息N8(MM^發送.REQ)中把如下的信息與MM—起發送到接收方的MMSE中的網元RSB6-在本情形中不需要解釋圖3中的消息N9(MM4—發送.RES)-:1.始發方準備接受來自接收方的應答-MM的費用(信息元素"應答-計費")，2.用于發送免費應答-MM的時限("應答-計費-期限")，3.應答-MM的最大長度(信息元素"應答-計費-大小")，4.關于始發方的MMS業務提供商支持或是否支持所請求的應答計費-功能性的信息(典型被稱為"應答-計費-支持-在-始發方-MMSE"的信息元素)，或(如果傳輸的MM是應答-MM;這種情況下，應答-MM凈皮視為是一個新的始發-MM):5.(初始的)始發-MM的消息-ID("應答-計費-ID")。表3示出了本發明的抽象消息N8(MM4—發送,REQ)中的附加信息元素，其中新的信息元素"應答-計費-ID"優選地是插入到已知的信息元素"消息-ID"之后，且其它四個新的信息元素插入到已知的信息元素"內容"之后。<table>tableseeoriginaldocumentpage13</column></row><table>表3:依照情形2在抽象消息N8(]>1]\14_發送.11￡0)中的附加f息元素。在表3中沒有提到的信息元素"應答-計費"、"應答-計費-期限和"應答-計費-ID"在此不需要重新定義。它們已經以公知的方式在MM1接口上采用，并在此依照本發明被傳送到新的MM4接口。信息元素"應答-計費-支持-在-始發方-MMSE"將在下面詳細描述由于在告知或傳送MM期間，如果不支持應答計費-功能性，則網元RSB6將把網元RSA5所設定的信息元素"應答-計費-支持"不變地傳遞到接收應用UAB2,所以，在此處所描述的情形中采取在上面情形1中為傳送關于MMS業務提供商支持或是否支持所請求的應答計費-功能性的信息而定義的信息元素"應答-計費-支持"將是不夠的。這一特性可能被接收應用UAB2錯誤地解釋。它需要關于參與MM傳輸的兩個網元5，6(RSA，RSB)支持或是否支持所請求的應答計費-功能性的信息。由于該原因，本發明在網元RSA5和網元RSB6之間的MM4接口上定義了一個不同于網元RSB6和接收應用UAB2之間的MM1接口上的信息元素。作為例子，這兩個新的信息元素可以被稱作"應答-計費-支持-在-始發方-MMSE"(在發射側的MMSE方支持應答計費)和"應答-計費-支持-在-接收方-MMSE"(在接收側的MMSE方支持應答計費)。在表3，5和6中示出了它們。在抽象消息N3(表5)和N6(表6)中，信息元素"應答-計費-支持-在-接收方-MMSE"被優選地插入到信息元素"應答-計費，，之后。如杲網元RSB支持應答計費-功能性，則它必須在通知接收方之前或在發送MM之前檢驗抽象消息N8(MM^發送.REQ)是否包含相應的信息元素"應答-計費-支持-在-始發方-MMSE"。如果是這樣，則網元RSB必須在此時把相應的信息元素"應答-計費-支持-在-接收方-MMSE"插入到抽象消息N3(MMl一通知.REQ-通知準備下載的MM)或抽象消息N6(]\1]\11_檢索.1^8=發送MM)中。可選地，如果或只要網元RSB能識別它，則他還可以在完成檢驗之后再刪除由網元RSA設置的信息元素"應答-計費-支持-在-始發方-MMSE，，，以減輕空中接口的負載。接收方的接收應用UAB可以利用這種方法、并通過分析信息元素"應答-計費-支持-在-接收方-MMSE"的有無來簡單地識別所參與的兩個MMS業務提供商是否都能處理一個對始發-MM的應答-MM的發送。信息元素"應答-計費-大小"標示了應答-MM所允許的大小，其也是本發明申請的主題。為了增強應答計費-功能性的靈活性，優選地補充了抽象消息N1(MM1JI:交.REQ),N8(MM4—發送.REQ),N3(MMlJt知.REQ)和N6(MM1—檢索.RES)。利用該新的信息元素，始發-MM的始發方不僅可以規定應答-MM的時限，而且還可以規定其最大長度。可選擇地或額外地，它也可以被所述參與MM傳輸的MMS業務提供商之一用來限制應答-MM的大小。表3~6示出了在相應的抽象消息中新定義的信息元素"應答-計費-大小"，其中該信息元素在抽象消息Nl,N3和N6中被優選地分別插入到已知的信息元素"應答-期限"之后。<table>tableseeoriginaldocumentpage15</column></row><table>表4:在抽象消息N1(MM1—提交.REQ)中的附加信息元素。<table>tableseeoriginaldocumentpage15</column></row><table>表5:依照情形2的抽象消息N3(MM^通知.REQ)中的附加信息元素。<table>tableseeoriginaldocumentpage16</column></row><table>表6:依照情形2的抽象消息N6(MML檢索.RES)中的附加信息元素。類似于在情形1中所描述的方案，在此處引入的信息元素"應答-計費-支持-在-始發方-MMSE"也可優選地被插入到抽象消息N2(MM1—提交.RES)中，由網元RS利用它來確認正確地接收一條MM。這明顯增強了應答計費-功能性的靈活性，因為利用該方法，可以在帶有應答計費-標識符的始發-M!VM皮發送之后告知發送應用UAA、以及在相應標識的應答-MM^皮發送之后告知接收應用UAB(在此，接收應用UAB是應答-MM的"始發方")關于各個MMS業務提供商是否支持所請求的應答計費-功能性的信息。表7示出了在抽象消息N2(MM1一提交.RES)中的附加信息元素"應答-計費-支持-在-始發方-MMSE"，其優選地被插入到信息元素"消息ID"之后，<table>tableseeoriginaldocumentpage16</column></row><table>表7:依照情形2的在抽象消息N2(MM1—提交.RES)中的附加信息元素。III.在WAP中實現本發明在現有技術基礎上，可以只使用WAP(WAP-無線應用協議)實現MMS。為在適用于MMS的終端和WAP網關之間搭建空中接口(在3GPP中MM1)，按照3GPPTS22.140版本4.1.0,第4版(見上面)和WAP-209.102-MMS封裝，2001年2月8日，(無線應用協議；WAP多媒體消息業務；消息封裝；MMS草案SCD)而規定使用WAPWSP傳輸協議。因此，在接下來的章節中來講述如何能把在上面為應答計費而重新定義的3GPP抽象-消息的信息元素轉變成所述WAP實現中的WAP消息。在此作為例子，依照情形2(兩個MMSE間的應答計費)來實現該實施方案變型，這是因為它描繪了更一般的情況，而且提供了更大的機會以在3GPP和WAP中實現；最后還因為它消除了對只有一個MMSE的限制。圖4示出了WAP中基于現有技術的、依照WAP-209.102-MMS封裝(見上面)的"事務流程圖，，，其中給出了當傳送MM時在四個參與的實例之間的WAP消息交換，這四個實例是發送應用la(MMS客戶A，縮寫為CA),發射側網元5a(MMS代理-中繼A，縮寫為PRA),接收側網元6a(MMS代理-中繼B，縮寫為PRB)和接收應用2a(MMS客戶B，縮寫為CB)。本發明申請所涉及的WAP消息，也即Nla(M-發送.req)、N2a(M隱發送.conf)、N3a(M-通知.ind)和N6a(M-檢索.conf)在此是用粗體示出的。在此，WAP消息Nla對應于前面提到的消息Nl，WAP消息N2a對應于前面提到的消息N2，等等。此外還給出了已知的消息N10a(M-傳送.ind)。作為指示符，這里可以注意到在WAP中不存在那些在3GPP中定義的概念MMS用戶代理，MMS中繼/服務器和MMSE。由于該原因，在該章節中只4吏用MMS客戶和MMS代理-中繼這樣的概念或它們的縮寫，而這些縮寫指的是同樣的實例。對于3GPP概念MMSE，在WAP中不存在類似的表達。依照WAP-203.102-MMS封裝(見上面)，在WAP消息的首字段包含一個字段名，其后接著一個至少包含一個字節(8-比特-字)字段值。表8中給出了十六進制數值至字段名之間的分配關系。當前有24個字段名。因此，在本發明申請中重新定義的字段名優選地在第25號開始(十六進制0x19)。它們在表9中給出。<table>tableseeoriginaldocumentpage17</column></row><table><table>tableseeoriginaldocumentpage18</column></row><table>表8:字段名的分配(根據現有技術)。<table>tableseeoriginaldocumentpage18</column></row><table>表9:根據本發明新定義的字段名。由于根據WAP-209.102-MMS封裝(見上面)，WAP消息的首字段總是包含一個字段名和一個字段值，所以需要為這里每一個重新定義的首字段定義至少一個字段值。下面給出更詳細的解釋對首字段的字段值進行編碼共有四種可能性，其中首字節決定了編碼的類型和長度(見表IO)。<table>tableseeoriginaldocumentpage19</column></row><table>表10:字段值編碼的四種可能性(現有技術)。為降低在空中接口上傳輸的數據量，兩個新定義的首字段"應答-計費-支持-在-始發方-MMS-代理-中繼"和"應答-計費-支持-在-接收方-MMS-代理-中繼"的字段值優選地專門是來自于第四個數值范圍(128到255)。新的首字段"應答-計費-支持-在-始發方-MMS-代理-中繼，，和"應答-計費-支持-在-接收方-MMS-代理-中繼"的一個可能定義可以是以下的形式字段名應答-計費-支持-在-始發方-MMS-代理-中繼字段值應答-計費-支持-在-始發方-MMS-代理-中繼-值-是l否是=<字節128>否=<字節129>字段名應答-計費-支持-在-接收方-MMS-代理-中繼字段值應答-計費-支持-在-接收方-MMS-代理-中繼-值-是l否是=<字節128>否=<字節129>新定義的首字段"應答-計費-大小，，的字段值可以逐級地(應答-MM可大到X,Y或Z千字節)或具體地(應答-MM可能大小只為X千字節)給定。對于帶有應答-消息可能大小等級的新首字段"應答-計費-大小"，其一種可能的定義可以具有如下的形式(數值范圍4):字段名應答-計費-大小字段值應答-計費-大小-值=200|400|600|800200=<字節128>400=<字節129>600=<字節130>800=<字節131>帶有應答-消息可能大小具體數據的新首字段"應答-計費-大小"的一種可能的定義可以具有下面的形式(數值范圍1):字段名應答-計費-大小字段值應答-計費-大小-值=長-整型在此不再更詳細地討論其它的編碼可能性。很明顯，本發明的范圍內存在不同的編碼可能性。按本發明對WAP消息Nla(M-發送.req)，N2a(M-發送.conf)，N3a(M-通知.ind)和N6a(M-檢索.conf)的補充在表11到14中給出。因為在3GPP中定義的信息元素的精確實現至今在WAP論壇中還沒有完成，所以為在一個MMSE內實現應答計費-功能性所需要的其余首字段在那里未給出。在WAP消息Nla(M-發送.req)中補充了首字段"應答-計費-大小"-優選地被插入到首字段"內容-類型"之后-，而且可以被那個想使用應答計費-功能性的應用CAla用來在發送MM時給出時限和限制應答-MM的大小。字段名內容說明"X-Mms-應答-計費-大小"應答計費-大小-值可選。規定了應答-MM的大小表ll:在WAP消息Nla(M-發送.req)中新定義的首字段。在WAP消息N2a(M-發送.conf)中已補充了首字段"應答-計費-支持-在-始發方-MMS-代理-中繼"-優選地被插入到首字段"消息-ID，，之后，并可以被用來告知已發送一條MM的發送應用CAla:相應的網元PRA5a是否已知道/接受所述始發方準備接受應答-MM的費用，或對前面所接收的和相應標識的始發-MM而作出的應答-MM的費用。字段名內容說明"X-Mms-應答-計費-支持-在-始發方-MMS-代理-中繼"應答計費-支持-在-始發方-MMS-代理-中繼-值可選。指示了在發射方是否支持應答計費表12:在WAP消息N2中新定義的首字段(M-發送.conf)。WAP消息N3a(M-通知.ind)和N6a(M-檢索.conf)還包含有(除了可能存在的關于始發方的網元PR5a支持應答計費-功能性的信息之外)由接收方網元PR6a設置的首字段"應答-計費-支持-在-接收方-MMS-代理-中繼"。然而，對于接收方的接收應用CB2a，只是有無"應答-計費-支持-在-接收方-MMS-代理-中繼"是非常重要的。只有發射側網元PRA5a和接收側網元PRB5a都支持應答計費-功能性，才優選地對此進行設定。如果它存在，則接收應用CB2a便能確信所參與的兩個MMS業務提供商得知了對前面所接收的始發-MM的應答-MM。在WAP消息N3a的情況下，首字段"X-Mms-應答-計費-支持畫在-接收方-MMS-代理-中繼，，優選地插入到已知的首字段"X-Mms-內容-位置"之后，并在WAP消息N6a的情況下插入到已知的首字段"內容類型"之后。在WAP消息N3a的情況下，首字段"X-Mms-應答_計費_大小"優選地插入到已知的首字段"X-Mms-期限"之后，并在WAP消息N6a情況下優選地插入到已知的首字段"X-Mms-讀-應答"之后。<table>tableseeoriginaldocumentpage21</column></row><table>表13:在WAP消息N3a(M-通知.ind)中新定義的首字段。<table>tableseeoriginaldocumentpage21</column></row><table>-MMS陽代理-中繼"中繼國值支持應答計費表14:在WAP消息N6a(M-檢索.conf)中新定義的首字段。借助應答計費-功能性已經詳細解釋本發明的第一方面，然而本發明也可以用在其他移動無線用戶所請求的功能性上。此外，本發明不僅可以用于多媒體消息，而且例如還可以相應地應用于SMS消息的發送和接收。參考符號清單1發送應用(醒S用戶代理A=UAA)la發送應用(畫S客戶A=CA)2接收應用(畫S用戶代理B-UAB)2a接收應用(醒S客戶B-CB)3醒S業務提供商(匪S業務提供商A)4醒S業務提供商(醒S業務提供商B)5發射側網元(麗S中繼服務器A-RSA)5a發射側網元(MMS代理-中繼A-RPA)6接收側網元(應S中繼服務器B-RSB)6a接收側網元(MMS代理-中繼B=PRB)7無線網絡8無線網絡醒l接口醒4接口Nl消息MM1—提交.REQNlaWAP消息M-發送.reqN2消息畫l-提交.RESN2aWAP消息M-發送.confN3消息MMl-通知.REQN3aWAP消息M-通知.indN4消息MMl-通知.RESN4aWAP消息M-通知Resp.reqN5消息MMl-檢索.REQN5aWAP消息WSPGETN6消息MM-檢索.RESN6aWAP消息M-檢索.confN7消息醒l-確i人.REQN7aWAP消息M-確i人.indN8消息醒4-發送.REQN9消息麗4_發送.RESN10aWAP消息M-傳送.ind權利要求1.用于經通信網絡利用發射側網元(5，5a)和與該發射側網元不同的接收側網元(6，6a)從發送應用(1，1a)向接收應用(2，2a)傳輸消息的方法，其中所述的發射側網元和接收側網元位于兩個業務提供商(3，4)的職責范圍內，以及其中，所述的消息包含關于始發方準備接受來自接收方的應答-消息的付費的信息(應答計費)，其特征在于:下面的信息中的至少一個從發射側網元(5，5a)被傳輸到接收側網元(6，6a)或被后者接收:·始發方準備接受來自接收方的應答-消息的付費(信息元素“應答-計費”)；·發送免費應答-消息的時限(信息元素“應答-計費-期限”)；·應答-消息的最大長度(信息元素“應答-計費-大小”)；·當傳送應答-消息時的始發-消息(信息元素“應答-計費-ID”)的消息-標識號(消息-ID)。2.如權利要求1的方法，其特征在于在相互不同的發射側和接收側網元中，在消息"MM4一發送.REQ"中傳輸或接收所述信息中的至少一個。3.如權利要求1或2的方法，其特征在于所述的通信網絡是畫TS網絡。4.如權利要求1或2的方法，其特征在于所述的消息是多媒體消息。5.用于經通信網絡利用發射側網元(5，5a)和接收側網元(6，6a)從發送應用(1，la)向接收應用(2，2a)傳輸消息的方法，其中所述的發射側網元和接收側網元是相同或不同的，并且位于一個或兩個業務提供商(3，4)的職責范圍內，以及其中，所述的消息包含關于始發方準備接受來自接收方的應答-消息的付費的信息(應答計費)，其特征在于由所述的發送應用(1，la)、發射側網元(5,5a)、接收側網元(6,6a)和/或接收應用(2，2a)傳送或接收用于應答-消息最大允許長度的信息。6.如權利要求5的方法，其特征在于所述用于最大允許長度的信息在消息MM1一提交.REQ(Nl)或M-發送.req(Nla)中從發送應用(1，la)凈皮一同傳輸給發射側網元(5，5a)，或由該發射側網元進行接收。7.如權利要求5或6的方法，其特征在于所述用于最大允許長度的信息在消息MM1一通知.REQ(N3)或M-通知.ind(N3a)和/或MM1一檢索.RES(N6)或M國檢索.conf(N6a)中從接收側網元(6,6a)被一同傳輸給接收應用(2，2a)，或由該接收應用進行接收。8.如權利要求5的方法，其特征在于在WAP消息M-發送.req(Nla)、M-通知.ind(N3a)和/或M誦檢索.conf(N6a)中使用新的、采用十六進制字段名編碼的首字段("應答-計費-大小")，該字段名的字段值優選地包含多個可能的分級最大值之一，或包含一個由始發方為該應答-消息允許的長度所選擇的具體值。9.如權利要求5或6的方法，其特征在于由所述的接收應用(2，2a)分析是否存在關于所述發送和/或接收側網元(5，5a;6，6a)支持所請求的功能性的信息，并促使或禁止為操作員輸出相應的信息。10.如權利要求5或6的方法，其特征在于所述的通信網絡是移動無線網絡。11.如權利要求5或6的方法，其特征在于所述的消息是多媒體消息。12.在一個業務提供商(3,4)的職責范圍內的網元(5，5a;6,6a)，其中，該網元被分配給一個發送應用(1，la)和/或一個接收應用(2，2a)，其中，這種網元可以;故用來從一個發送應用(1，la)向一個接收應用(2，2a)傳輸消息，以及其中，所述的消息包含關于始發方準備接受來自接收方的應答-消息的費用的信息(應答計費)，其特征在于所述的網元(5，5a;6,6a)被設計成這樣，使得它能傳輸或接收和分沖斤以下^f言息中的至少一個在發射側和接收側網元(5，5a;6,6a)不同的情況下向接收應用(2,2a)傳輸始發方準備接受來自接收方的應答-消息的費用(信息元素"應答-計費")；在發射側網元和接收側網元不同的情況下，由發射側網元(5，5a)傳輸或由接收側網元(6，6a)接收用于發送免費應答-消息的時限(信息元素"應答-計費-期限")；向或由另一參與數據交換的設備(1，la;2，2a;5,5a;6,6a)傳輸或接收應答-消息的最大長度(信息元素"應答-計費-大小")；當傳輸應答-消息時，向或由所述相對于應答-消息為接收方的網元傳輸或接收始發-消息(信息元素"應答-計費-ID")的消息-標識號(消息-ID)。13.如權利要求12的網元，其特征在于所述的網元是移動無線網絡的網元。14.如權利要求12的網元，其特征在于所述的消息是多媒體消命15.在一個業務提供商的職責范圍內的網元(5，5a;6，6a)，它被分配給一個發送應用(1，la)和/或一個接收應用(2，2a),其中，這種網元(5，5a;6，6a)可以被用來從一個發送應用(1,la)向一個接收應用(2，2a)傳輸消息，以及其中，所述的消息被用來在至少一個業務提供商的職責范圍內請求一個應答-計費功能性，其特征在于所述的網元(5,5a;6,6a);故設計成這樣，使得它能把關于用于應答-消息最大允許長度的信息傳送給另一參與數據交換的設備(l，la;2，2a;5，5a;6,6a)，或由后者接收該信息。16.如權利要求15的網元，其特征在于所述的網元是移動無線網絡的網元。17.如權利要求15的網元，其特征在于所述的消息是多媒體消臺18.用于在通信網絡中進行通信的用戶設備，它具有用于從一個業務提供商(3，4)的職責范圍內的一個網元(5，5a;6，6a)發送和/或接收消息的發送應用和/或接收應用(1，la;2，2a),其中，所述的消息可以包含關于始發方準備接受來自接收方的應答-消息的費用的信息(應答-計費)，其特征在于將所述的用戶設備設計成這樣，使得它能傳輸或接收至少以下信息之一在發射側和接收側網元(5，5a;6，6a)不同的情況下，接受并分析關于始發方準備接受來自接收方的應答-消息的費用的信息(信息元素"應答-計費")；傳送和/或接收用于應答-消息最大允許長度的信息(信息元素"應答-計費-大小")；接收并分析關于所述相對于始發-消息或應答-消息為發射方的網元(l，la或2，2a)支持應答計費-功能性的信息(信息元素"應答-計費-支持-在-始發方-MMSE");接收并分析關于所述相對于始發-消息或應答-消息為接收方的網元(2，2a)支持應答計費-功能性的信息(信息元素"應答-計費-支持-在-接收方-MMSE"),19.如權利要求18的用戶設備，其特征在于所述通信網絡是移動無線網絡。20.如權利要求18的用戶設備，其特征在于所述的消息是多媒體消息。21.用于在通信網絡中進行通信的用戶設備，它具有至少一個接收應用(2，2a)以用于從一個業務提供商(3，4)的職責范圍內的一個網元(5，5a;6，6a)接收消息和/或向其發送消息，其中，所述的消息包含在業務提供商的職責范圍內對應答-計費功能性的請求，其特征在于將所述的用戶設備設計成這樣，使得它可以發送和/或接收和分析關于應答-消息最大允許長度的信息。22.如權利要求21的用戶設備，其特征在于所述通信網絡是移動無線網絡。23.如權利要求21的用戶設備，其特征在于所述的消息是多媒體消息。24.能夠在一個帶有處理器的設備上運行的軟件程序，所述的設備尤其是權利要求12或1S的網元或權利要求18或21的用戶i殳備，該軟件程序被如此地運行，使得它同所述的設備一起在該設備方執行如權利要求1到11之一所述的方法步驟。全文摘要在傳輸消息時擴充信息流的方法、裝置和軟件程序，用來在至少一個業務提供商的職責范圍內在功能性方面簡化信息流，尤其是對UMTS中的多媒體消息，其中，該功能性已由用戶進行請求。這樣功能性的例子有應答計費或消息回叫。本發明尤其提出了傳輸如下信息的方法，即從該信息可以得出在業務提供商職責范圍內的網元是否支持所請求的功能性。本發明還提出了在應答計費時對應答-消息的最大尺寸進行限制。文檔編號H04L12/58GK101384001SQ20081009037公開日2009年3月11日申請日期2002年8月9日優先權日2001年8月10日發明者A·施密德特,J·勞門,M·特勞貝格,S·范尼克爾克申請人:西門子公司