用於傳送多媒體文件的方法
2023-06-07 13:05:51
專利名稱：用於傳送多媒體文件的方法
技術領域：
本發明涉及通信。更具體而言，本發明涉及一種用於有效傳送多媒體文件比如包含多媒體內容的多媒體消息傳送服務的消息的技術。
背景技術：
隨著無線網絡吞吐量的增加以及移動通信裝置的完善，多媒體消息傳送服務(MMS)型數據傳送正在變得日益在用戶中流行。然而，用於傳送這種消息的當前技術是沒有效率的，並且消耗不必要的網絡資源，同時還導致傳送和接收MMS的延遲。
對於常規系統，MMS通常從始發方網絡部件被發送到與其關聯的伺服器或中繼器，該伺服器或中繼器將多媒體消息轉發給與接收方網絡部件(或簡單地為接收方)關聯的伺服器或中繼器。接收方伺服器然後把MMS通知給接收方，接收方從伺服器檢索內容。內容檢索和讀取答覆由接收方確認，並且被返回到始發方伺服器並最終返回到始發方網絡節點。
圖1提供一種信令圖100，該圖詳述了關於使用常規技術進行MMS傳送的在始發終端的始發方MMS用戶代理(UA)110、始發方MMS中繼器/伺服器(或簡短地為始發方MMS伺服器)120、接收方MMS中繼器/伺服器(或簡短地為接收方MMS伺服器)130以及接收方終端的接收方MMS UA 140之間交換的信號。請求經由信號1A(例如MM1_submit.REQ)發出，以將MMS從始發方MMS UA 110傳送給始發方MMS伺服器130，該伺服器130經由信號1B(例如MM1_submit.RES)答覆。此後，始發方MMS伺服器120經由信號1C(例如MM4_forward.REQ)把請求轉發給接收方MMS伺服器130，該伺服器130通過信號1D(例如M4_forward.RES)答覆。接收方MMS伺服器130然後經由信號1E(例如MM1_notification.REQ)把該請求通知給接收方MMS UA 140，該接收方MMS UA 140通過信號1F(例如MM1_notification.RES)進行響應。
如果接收方MMS UA 140選擇接受如在該請求中所提供的MMS的傳送，則生成信號1G(例如MM1_retrieve.REQ)並將其發送給接收方MMS伺服器130，然後響應經由信號1H(例如MM1_retrieve.RES)被送回給接收方MMS UA 140。接收方MMS UA140利用信號1I(例如MM1_acknowledgment.REQ)把內容檢索確認發送給接收方MMS伺服器130，該伺服器130然後把報告有關內容的信號1J(例如MM4_delivery_report.REQ)發送給始發方MMS伺服器120，該伺服器120隨後經由信號1K(例如MM4_delivery_report.RES)答覆。始發方MMS伺服器120然後向始發方MMS UA 110發送確認傳送報告的信號1L(例如MM1_delivery_report.REQ)。接收方MMS UA 140還經由信號1M(例如MM1_read_reply_reciplent.REQ)發送讀取答覆確認，然後向始發方MMS伺服器120發送報告有關內容的信號1N(例如MM4_delivery_report.REQ)，伺服器120隨後經由信號1K(例如MM4_delivery_report.REQ)答覆。始發方MMS伺服器120此後向始發方MMS UA 110發送讀取答覆確認信號1P(例如MM1_read_reply_originator.REQ)。
儘管MMS的流行性在增長，但是傳送MMS所需的時間量可能過長。結合圖2的信令圖200顯示傳送延遲的一個原因，圖2說明了在始發網絡部件例如始發終端210、短消息傳送服務中心220(SMS-C)、WAP代理230、推送代理網關240(PPG)以及始發多媒體消息傳送中心(MMC)即始發方MMS中繼器/伺服器250之間的信令。始發終端210經由WAP代理230發送信號2A中的MMS，並向始發MMC 250發送信號2B。對於慢速網絡接入，可能花費高達四十(40)秒把MMS內容完全上載到MMC 250。在完成上載之後，始發MMC 250經由信號2C和2D確認MMS的接收。始發方MMC 250然後將MMS轉發給也確認MMS的接收的接收方MMS中繼器/伺服器(未示出)。
圖3說明具有與圖2類似部件的信令圖300，但是與由接收方網絡部件例如接收方終端對MMS的檢索相關。從MMC即與接收方終端310關聯的接收方MMS中繼器/伺服器350經由信號3A將推送接入協議消息發送給PPG 340，PPG 340經由信號3B確認該消息。從PPG 340把短消息對等協議消息3C發送給SMS-C 320，SMS-C 320隨後經由信號3D將MMS通知給接收方終端310。接收方終端310然後可以發送一個通知以經由WAP代理330獲得信號3E中MMS，並把信號3F發送給接收方MMC 350。MMC 350然後經由信號3G和3H把MMS下載到接收方終端。類似於MMS到始發方MMC 250的上載，從接收方MMC 350到接收方終端310的下載可能也花費高達四十(40)秒，這取決於網絡的速度。
因此根據上述將認識到，MMS的傳送基本上通過三個獨立的階段完成1.始發網絡部件到始發方MMS中繼器/伺服器；2.始發方MMS中繼器/伺服器到接收方MMS中繼器/伺服器；以及3.接收方MMS中繼器/伺服器到接收方網絡部件。
因此，使用常規技術的MMS傳送不必要地過長(尤其是如果僅僅存在可用的低速網絡接入的話)，並且導致消耗始發方和接收方MMS中繼器/伺服器中顯著的緩衝器空間(其部分地基於大量的並行進行的傳輸)。這種延遲可以隨著MMS大小的增加(例如在大的視頻剪輯的情況下)而增加。
接收MMS的延遲消極地影響在接收方網絡部件上的用戶體驗，並且可能阻止用戶發送MMS(由此降低網絡運營商的潛在吞吐量收入)。例如，在一些情況下，比如關於體育或新聞剪輯，用戶可能急切等待MMS被完全加載。在其它情形下，用戶可能知道MMS在途中，比如當用戶也正在參加與始發用戶的語音會話並且並行發送MMS(例如經由組合服務等等)時，以及用戶可能知道傳送的延遲會消極地影響與其它用戶的交互。延遲在單個用戶向所有參與者發送MMS的多用戶組會話中也成問題。當接收參與者可能已經為多用戶內容而註冊時，他們被認為對內容接收是準備好的。
因此，仍然需要一種用於從始發方向接收方傳送MMS或類似消息的改進的技術。
發明內容
本發明體現為一種從始發方向接收方傳送多媒體數據文件比如MMS的方法，所述始發方具有與其關聯的始發方伺服器，所述接收方具有與其關聯的接收方伺服器。這種方法可以包括經由始發方伺服器和接收方伺服器建立從始發方到接收方的通信路徑。該方法還可以包括由接收方伺服器從始發方伺服器接收數據文件的各部分(每個數據文件部分或完整數據文件從始發方被上載到始發方伺服器)。此後，在不等待完整數據文件的接收的情況下，接收方伺服器單獨轉發從始發方伺服器接收的數據文件部分，以用於由接收方重組。
到接收方伺服器以及也到接收方的通信路徑可以在整個數據文件被上載到始發方伺服器之前被建立。所以，接收方(或者處理數據文件的其內部部件，比如MMS用戶代理)可以在最初已經是在線且可達的(例如在數據文件到始發方伺服器的上載開始之前)。因而通過數據文件內容的同時上載、傳播和下載，可以加速數據文件的傳送。可選擇地，可以以兩個或更多個步驟來建立通信路徑(例如在數據文件上載期間或者在數據文件被上載到始發方伺服器之後)。
各個數據文件部分可以經由在數據文件傳輸時間建立的(半)永久通信路徑直接轉發給接收方。在許多情況下，建立到接收方的通信路徑所必需的信息是最初可得到的(例如在數據文件內容或者其部分到始發方伺服器的上載開始之前)。為了建立通信路徑，可以執行協商(以便也商定用於數據文件傳送的通信原則)。在這方面所交換的信息可以包括關於待傳送的數據文件的大小的信息。正如可以認識到的，可以根據期望配置對該方法作出各種可選修改。例如，該方法還可以包括由接收方伺服器接收數據文件被正確地重組的確認的步驟。另外或者作為選擇，該方法還可包括以下步驟由接收方伺服器向始發方伺服器或者由接收方向接收方伺服器再向始發方伺服器發送一個指示數據文件部分未被接收的消息。類似地，可以由接收方伺服器向始發方伺服器或者由接收方向接收方伺服器再向始發方伺服器發送消息，該消息指示數據文件部分已經被正確接收。
為了最小化經由無線網絡的數據文件部分的傳送，始發方伺服器和接收方伺服器中的至少一個可以高速緩存已接收的數據文件部分，以使如果相鄰部件在數據業務流內沒有正確接收這種數據文件部分，則可以快速重發該數據文件部分。
該方法還可以包括由始發方和始發方伺服器中的至少一個把數據文件細分成數據文件部分的步驟。如果數據文件被始發方細分，則消耗更少的網絡資源。結果，網絡運營商可以根據數據文件是否被始發方或者被始發方伺服器或某一其它網絡部件細分來收取不同費用(尤其是如果始發方和接收方中的至少一個是移動通信裝置的話)。在這方面，該方法還可包括以下步驟基於由始發方伺服器和接收方伺服器中的至少一個所利用的處理能力的量，把記帳費用與數據文件的傳送相關聯。
該方法還可包括建立或協商用於從始發方到接收方傳送數據文件的參數的多個步驟。對於該變化，該方法還可以包括以下步驟由接收方伺服器接收響應於來自始發方的請求而生成的來自始發方伺服器的傳送查詢，該傳送查詢包含或涉及關於數據文件的傳送的初始參數；由接收方伺服器確定是否修改初始參數；由接收方伺服器對傳送查詢發送包括或涉及最終參數的的響應，所述最終參數包括初始參數的接受或已修改參數；以及由接收方伺服器接收根據最終參數所傳送的數據文件，以用於向接收方傳送。本領域技術人員還將認識到，可以結合上述的數據文件傳送方法來利用以及分別利用這樣的預傳送協商，並且該協商技術還可以適用於其它通信情況。
與數據文件的傳送有關的參數可以涉及各種因素，並且可以可選地從包括以下各項的組中進行選擇數據文件內容類型、數據文件內容大小、用於編碼內容的編解碼器、數據文件的部分的數量、每個數據文件部分的大小、數據文件部分的順序編號、請求丟失的數據文件部分的過程、接收方的數量、以及所利用的確認協議。
為了最小化關於通信參數的建立所交換的信號或消息的數量，初始參數可以包含至少兩種用於把數據文件傳送給接收方的技術，並且響應可以包括所述至少兩種不同技術之一的接受或者已修改參數。該方法還可提供始發方從至少兩個預定義的通信參數集中選擇通信參數，並且這些集最終可以被轉發給接收方伺服器和/或接收方。
該方法還可提供始發方伺服器存儲該請求，並且它還可提供接收方伺服器存儲傳送查詢，例如在需要重傳這種消息(或由此產生的消息)的情況下，或者在轉碼要被執行的情況下。
可以被包含在該方法中的附加步驟包括由接收方伺服器把傳送查詢轉發給接收方；以及由接收方伺服器對傳送查詢接收包括最終參數的響應。可選擇地，當接收方伺服器轉發傳送查詢時，它可以根據預定的傳送查許標準來修改該傳送查詢(再將其存儲在資料庫中)，並且把已修改的傳送查詢轉發給接收方。作為選擇，該方法可以包括以下步驟由接收方伺服器(而不是由接收方)基於預定的傳送標準來生成對傳送查詢的響應。預定的傳送標準可以包括接收方的已知能力。
而且，該方法還可包括以下步驟由接收方或接收方伺服器把所述響應轉換成與始發方伺服器和始發方中的至少一個兼容的格式。
在另一個實施例中，提供一種從始發方向接收方傳送多媒體數據文件比如MMS的方法，所述始發方具有與其關聯的始發方伺服器，所述接收方具有與其關聯的接收方伺服器，該方法包括經由始發方伺服器和接收方伺服器建立從始發方到接收方的通信路徑。該方法還包括由始發方伺服器從始發方接收數據文件或數據文件的各部分，並且如果接收到數據文件，就把該數據文件分成多個數據文件部分；以及由始發方伺服器在不等待完整數據文件的接收的情況下，單獨轉發從始發方接收的數據文件部分，以用於由接收方重組。
根據一個變型，始發方伺服器和接收方伺服器中的至少一個接收一個或多個數據文件部分，包括與數據文件有關的報頭和控制信息中的至少一個。根據另一個變型，始發方伺服器接收在單個消息中的數據文件以及報頭和控制信息中的至少一個。這兩種變型允許始發方伺服器和/或接收方伺服器立即開始處理報頭和控制信息中的至少一個，而不用等待數據文件的完整接收。所以，始發方伺服器和/或接收方伺服器可以確定傳輸有關方面，象數據文件的接收方和/或在數據文件傳輸的非常早階段的數據文件的長度。
事實上，中間節點比如始發方伺服器和接收方伺服器不需要關於數據文件內容的任何知識來開始它們專用的處理操作。因此，始發方伺服器可以把與將由始發方伺服器所轉發的數據文件有關的信息通知給接收方伺服器，同時始發方伺服器仍然從始發方接收數據文件或數據文件部分。這一方面在始發方伺服器與始發方之間以及另一方面在始發方伺服器與接收方伺服器之間產生了同時的或「交織的」(即不嚴格連續)消息傳送過程。這種過程的優點在於這樣的事實，即接收方伺服器例如可以對於它將接收的數據文件分配資源和/或在非常早的階段向接收方通知數據文件傳輸。
本發明還可體現為一種可以被存儲在計算機可讀記錄介質上的電腦程式產品，該電腦程式產品包括程序代碼部分，用於當電腦程式產品在一個或多個計算機或計算機系統上運行時執行在此所述的方法的步驟。
在又一個變型中，本發明體現為一種包括計算機處理器和與該處理器耦合的存儲器的系統，其中利用一個或多個程序對存儲器進行編碼，所述程序執行在此所述的方法的步驟。
本發明還實現了一種經由建立的通信路徑從始發方向接收方傳送多媒體數據文件比如MMS的設備，所述始發方具有與其關聯的始發方伺服器。這樣的設備可以包括接收單元，用於從始發方伺服器接收數據文件的各部分，所述數據文件或者數據文件的各部分從始發方被上載到始發方伺服器；以及中繼單元，用於單獨轉發從始發方伺服器所接收的數據文件的各部分，以用於由接收方重組，其中在不等待完整數據文件的接收的情況下轉發數據文件部分。
類似地，本發明還可包括一種經由建立的通信路徑從始發方向接收方傳送多媒體數據文件比如MMS的設備，所述接收方具有與其關聯的接收方伺服器。這樣的設備可以包括接收單元，用於從始發方接收數據文件或數據文件的各部分，並且如果接收到數據文件，就把數據文件分成多個數據文件部分；以及中繼單元，用於單獨轉發從始發方所接收的數據文件部分，以用於由接收方重組，其中在不等待完整數據文件的接收的情況下轉發數據文件部分。
在又一個實施例中，本發明採取經由建立的通信路徑傳送多媒體數據文件比如MMS的系統的形式。該系統包括啟動數據文件的傳輸的始發方用戶代理；接收方用戶代理；與始發方用戶代理關聯的始發方伺服器；以及與接收方用戶代理關聯的接收方伺服器。在操作中，始發方把數據文件或數據文件部分上載到始發方伺服器，始發方伺服器把數據文件的多個部分發送給接收方伺服器，以及接收方伺服器在不等待完整數據文件的接收的情況下把已接收的數據文件的部分單獨轉發給接收方以用於重組。
在下文中將參考在附圖中所說明的示例性實施例來描述本發明，其中
圖1是示出與多媒體數據文件的傳送有關的技術的第一信令圖；圖2是示出與多媒體數據文件的傳送有關的技術的第二信令圖；圖3是示出與多媒體數據文件的傳送有關的技術的第三信令圖；圖4是根據本發明的方法實施例的過程流程圖；圖5是根據本發明的設備實施例的示意圖；圖6是與對於理解和實施本發明有用的多媒體數據文件的傳送啟動有關的實例的信令圖；圖7是與對於理解和實施本發明有用的多媒體數據文件的傳送有關的實例的信令圖；圖8是示出根據本發明的直接轉發和通知過程的第一信令圖；以及圖9是示出根據本發明的直接轉發和通知過程的第二信令圖。
具體實施例方式
在後面的描述中，為了解釋而非限制的目的，陳述了特定細節，比如特定信號格式等等，以便提供對本發明的徹底理解。對於本領域技術人員而言下述將是顯而易見的可以在背離這些特定細節的其它實施例中實行本發明。例如，本領域技術人員將會認識到，本發明可以結合多媒體數據文件類型以及其中需要更有效的數據傳送的不同於MMS的消息傳送服務來使用。
而且，本領域技術人員還將認識到，在下文所解釋的功能可以被這樣實施使用單獨的硬體電路，使用軟體功能以及程控的微處理器或通用計算機，使用專用集成電路(ASIC)，和/或使用一個或多個數位訊號處理器(DSP)。還將認識到，儘管本發明主要被描述為方法，但是它也可以體現為包括計算機處理器和與該處理器耦合的存儲器的系統，其中利用可以執行在此所公開的方法的一個或多個程序來對存儲器進行編碼。
圖4公開了用於從始發方(比如第一移動終端)到接收方(比如第二移動終端)傳送數據文件比如MMS的方法400，所述始發方具有與其關聯的始發方伺服器，所述接收方具有與其關聯的接收方伺服器。該方法開始於步驟410，在此建立從始發方經由始發方伺服器和接收方伺服器到接收方的通信路徑。在步驟420，由始發方伺服器從始發方或者由接收方伺服器從始發方伺服器接收至少部分數據文件(從始發方上載到始發方伺服器的)來繼續該方法。此後，在步驟430，由始發方伺服器或由接收方伺服器在不等待完整數據文件的接收的情況下單獨轉發數據文件的已接收部分以用於由接收方重組(例如，基於可能與每個數據文件部分關聯的序號)來繼續該方法。
圖5說明經由建立的通信路徑從始發方到接收方傳送多媒體數據文件比如MMS的設備500，所述始發方具有與其關聯的始發方伺服器。設備500包括兩個主要部件接收單元510，用於從始發方或者始發方伺服器接收至少部分數據文件，該數據文件或者數據文件部分從始發方被上載到始發方伺服器；以及中繼單元520，用於單獨轉發從始發方或始發方伺服器接收的數據文件的部分，以用於由接收方重組，其中在不等待完整數據文件的接收的情況下轉發數據文件部分。
下面提供可以與在此所述的實施例可選地結合使用的的變化的實例，或者單獨或者組合應用。儘管下面可能把網絡部件描述為移動通信裝置或移動單元，但是將認識到，上述也適用於各種各樣的計算機網絡部件，包括有線終端。
參考圖6，提供了信令圖600，其中信號在始發方MMS UA(用戶代理)610、始發方MMS中繼器/伺服器620、接收方MMS中繼器/伺服器630以及接收方MMS UA 640之間交換，以作為在實際傳送MMS之前進行的並且關於將從始發方MMS UA 610向接收方MMS UA 640傳送MMS所用的參數的協商的部分。將會注意，如果期望的話，始發方MMS伺服器620和接收方MMS伺服器630可以被組合在相同的物理網絡實體內。
經由信號6A(其可以是MMS_Comm.REQ信號)，始發方MMSUA 610向始發方MMS伺服器620發送所建議的通信參數。這些通信參數可以包括各種通信原則，這些通信原則將規定MMS或其它多媒體文件從始發方MMS UA 610被最終傳送到接收方MMS UA 640的方式。例如，所述參數可以包括MMS內容類型和大小；用於編碼多媒體文件(和/或潛在的內容)的編解碼器；MMS內容部分的數量以及可選地每個數據文件部分的大小(其可能預先不知道，這取決於期望的配置)；每個數據文件部分的序號(除非標準化)；請求數據文件的丟失的部分的過程(除非標準化)；與在數據文件的每個部分之內潛在的內容有關的信息(其例如可以由接收方MMS UA 640使用以通知始發方MMS UA 610數據文件的某些部分不需要被傳送)；單個或多個用戶數據文件傳送；ACK/NACK是否將被用來(被動地)確認數據文件部分的正確接收，等等。而且，在一些變化中，始發方MMSUA 610還可以發送通信參數的若干選項(例如固定的傳輸模板)，以使接收方MMS伺服器630和/或接收方MMS UA 640可以選擇最佳的通信參數集。
從始發方MMS伺服器620發送給接收方MMS伺服器630的信號6B(其可以是MMC_Comm.REQ信號)轉發所建議的通信參數(或者發送與通信參數或通信參數集關聯的已修改消息信號)。可選地，始發方MMS伺服器620還可以(例如在本地存儲器或資料庫中)存儲與在信號6A內所包含的通信參數有關的信息。作為選擇，信號6B可以僅僅包含對特定的預定義通信參數集的引用。
利用信號6C(其可以是MMS_Comm.REQ信號)，接收方MMS伺服器630把所建議的通信參數(或與其有關的信息)轉發給接收方MMS UA 640。接收方MMS伺服器630還可以在發送信號6C之前可選地(例如在裝入存儲器或資料庫中)存儲在信號6B內所包含的信息。如果接收方MMS伺服器630已經具有關於接收方MMS UA 640的能力的信息，則它可以可選地排除某些所建議的通信參數或者修改在信號6C內所發送的各個通信參數。
經由信號6D(其可以是隱含MM1_notification.RES指示符的MMS_Comm.RES信號)，接收方MMS UA 640(其可以可選地存儲所建議的通信參數)把結果返回給信號6C的請求。該結果可以是簡單的OK指示(意味著所建議的通信參數是可接受的)，或者作為選擇，該結果可以包括所接受或所排除的參數的列表或者已修改參數的列表。這些排除或改變可以基於在接收方MMS UA 640內存在的定義的參數或限制。如果使用參數集，則可以交換簡化的和更有效的信令。在簡檔信息被發送的情況下，該結果可以指示所選擇的簡檔。
如圖6中的虛線所示，根據期望的配置，可能不需要信號6C和6D。例如，接收方MMS伺服器630可以訪問或包括這樣的資料庫，該資料庫包含與接收方MMS UA 640的能力或多媒體文件傳送偏好有關的信息，因此避免了對信號6C和6D的需要。對於此安排，在包含數據文件部分的第一消息之前應該是MM1_notification.REQ消息和MM1_notification.RES消息。在現有的MMS規範中，這些消息被用來通知接收方存在可以檢索的MMS內容。
接收方MMS伺服器630經由信號6E把關於所建議的通信參數的響應返回給始發方MMS伺服器620。在接收方MMS伺服器630或接收方MMS UA 640已經修改(或減少)通信參數的那些情況下，接收方MMS伺服器630可以安裝變換器功能，並且仍然把未修改的通信參數返回給始發方MMS伺服器620。這可以當在所建議的通信參數與接收側所支持的通信參數之間存在不一致時進行。接收方MMS中繼器/伺服器630然後例如可以執行實際內容的編解碼器變換、除去顏色(color)比特和/或執行類似操作。
始發方MMS伺服器620然後經由信號6F把通信參數返回給始發方MMS UA 610。可選地，如果通信參數先前沒有被接收方MMS伺服器630變換，則始發方MMS伺服器620可以安裝變換器功能。
在數據文件被發送到多個接收方MMS UA的情況下，MMS_Comm.REQ信號則指示通信參數可能是固定的並且不能被改變(部分是由於這樣的事實，即數據文件必須以統一的方式被傳送，並且為多播或其它多用戶會話或服務而註冊時，接收方UA已經同意這種傳送)。另外，接收方MMS UA可以不返回MMS_Comm.RES信號(因為這種信令可能使網絡過載)。
圖7提供信令圖700，該圖說明與MMS 8的傳送有關的在始發方MMS UA 610、始發方MMS伺服器620、接收方MMS伺服器630以及接收方MMS UA 640之間的信號交換(並且可選地在參考圖6所述的協商結束之後)。
接收方MMS UA 640可以把信號7A(比如MM1_retrieve.REQ信號)發送給接收方MMS伺服器630，以啟動從MMS中繼伺服器630檢索數據文件部分(例如每當每個數據文件部分到達接收方MMS中繼伺服器630時)。經由信號7B(比如MM1_submit.REQ信號)，始發方MMS UA 610把數據文件部分上載到始發方MMS伺服器620。此後，通過信號7C(比如MM4_forward.REQ信號)，始發方MMS伺服器630直接(並且可選地一接收到它)把數據文件部分轉發給接收方MMS UA 630。接著，經由信號7D(比如MM1_retrieve.RES信號)，接收方MMS UA 630直接(並且可選地一接收到它)把數據文件部分轉發給接收方MMS UA 640。由信號7B(經由信號7E和7K)、7C(經由信號7F和7L)以及7D(經由7G和7M)所表示的信令序列可以被重複多次，直至接收方MMS UA 640接收到所有的數據文件部分。
將會注意，在信號7B和7C之前、期間或之後，可以發送信號7A。然而，數據文件部分到接收方MMS UA 640的傳送(經由信號7D)在信號7A被接收到之前將不開始。在多用戶服務的情況下，信號7A可能不被發送(並且可能使網絡過載)，以及接收方MMS伺服器630一接收到數據文件部分，就把它們傳送給接收方MMS UA 640。
每個數據文件部分包括可以用來檢測丟失的數據文件部分和/或用於重組目的的序號。如果始發方MMS伺服器620、接收方MMS伺服器630或接收方MMS UA 640檢測到丟失的數據文件部分，則這樣的部件因此通知它們在業務鏈中的對應部分(如由信號7H、7I、7J、7N、7O以及7P所示，所有這些信號由虛線表示)。為了最小化將由未正確接收的數據文件部分的重傳所產生的任何進一步延遲和業務，始發方MMS伺服器620和接收方MMS伺服器630可以高速緩存數據文件部分，以便避免這種數據文件部分經由無線網絡被再次上載。
另外或者作為選擇，為了監視NACK消息(指示存在丟失的數據文件部分)，還有可能使用ACK消息來確認相應數據文件部分的正確接收。數據文件部分被高速緩存在始發方MMS伺服器620和接收方MMS伺服器630內的這種安排在具有多個接收方MMS UA和還具有多個接收方MMS伺服器的情況中會特別有用，所以對接收方MMS UA640的傳輸故障不需要經由無線網絡的附加上載。
而且，在一些變化中，來自始發方MMS伺服器620、接收方MMS伺服器630和接收方MMS UA 640中任何一個的信號可以被最終發送給始發方MMS UA 610，指示某一數據文件部分(或者其分部)不需要被傳送。這可能是例如當通信參數包括關於不同MMS部分的內容的信息時的情況。接收方然後可以決定不是所有的內容部分都被實際需要或想要。假定例如MMS包括報尾加視頻/音頻內容。在這種情況下，接收方可以指示只想要報尾。在另一情況下，MMS可以包括slights、視頻內容加音頻內容。接收方然後可以指示僅僅想要slights和音頻內容(即不需要傳送視頻內容)。
返回到圖7的信令圖700，接收方MMS UA 640經由信號7Q向接收方MMS伺服器630確認完整數據文件部分的正確接收，該伺服器630經由信號7R把該確認轉發給始發方MMS伺服器620，該伺服器620經由信號7S進行確認，並隨後經由7T轉發給始發方MMS UA610。
可選地，接收方MMS UA 640還可以經由信號7U把讀取答覆報告發送給接收方伺服器630，該伺服器630利用信號7V把讀取答覆報告轉發給始發方MMS伺服器620，該伺服器620經由信號7W進行確認，並經由信號7X將其轉發給始發方MMS UA 610。讀取答覆報告還可包含各種信息，比如何時讀取數據文件部分，訪問數據文件部分多久，等等。
可選實施例的目的是最小化對發送方和接收方的終端影響。基本思想是，始發方MMS中繼器/伺服器(即始發方MMSC)一可以確定接收方MMS用戶代理以及因而確定接收方MMS中繼器/伺服器，就開始轉發和通知過程。在第一變型中，在始發MMSC接收到MM1_submit.REQ消息之後立即開始MMS的分析。在第二變型中，兩個新交互被引入，以從消息內容分別上載消息報頭。
在這兩種變型背後的思想是，中間節點不需要知道完全的MMS內容。中間節點僅僅需要報頭和控制信息，並且也許還是標誌，該標誌指示實際MMS內容以「流」方式被傳送。這還意味著為了MMS傳送而改變端到端的消息序列。接口(例如MM1或MM4)上的序列不必受到影響。
圖8說明了用於逐級MMS傳送的已修改信令圖的第一變型。在MM1和MM4接口上的序列被「交織」，這允許從始發方到接收方的MMS的傳送快得多。
始發方MMS用戶代理810「照常」向始發方MMSC 820發送MMS(包括報頭和控制信息)。這裡，始發方MMSC 820一接收到MMS報頭和控制信息，就開始處理並估計MMS報頭和控制信息(估計已經接收的部分不必等待MMS傳輸結束)。可選地，「報頭長度」欄位對MM1消息8A進行擴展。該欄位將允許始發方和接收方MMSC 820、830在嘗試提取和處理報頭之前，首先對已接收字節進行計數。
當始發方MMSC 820已經接收到MMS報頭和控制信息時，始發方MMSC 820立即分析報頭並確定接收方MMSC 830。始發方MMSC820使用MM4_forward.REQ消息8B來向接收方MMSC 830發送MMS報頭。在始發方與接收方MMSC 820、830之間的通信鏈路對於實際MMS內容保持開放。可選擇地，始發方MMSC 820保持整個MMS(報頭和內容)的副本以用於故障操作，直至它從接收方MMSC接收到MM4_forward.RES消息。
在該過程之前，始發方MMSC 820確定接收方MMSC 830的能力。存在若干方式來確定接收方MMSC 830所支持的能力。這裡假設，始發方MMSC 820知道接收方MMSC 830的能力。
可選地，MMS內容長度欄位對MM4消息進行擴展。這主要用於監視目的，因為在始發方和接收方MMSC 720、830之間所用的協議是可靠的。
接收方MMSC 830首先接收用於輸入MMS的報頭和控制信息(例如，在初始MMS部分中，該初始MMS部分由始發方MMSC 820通過把MMS分成單獨轉發給接收方MMSC 830的多個MMS部分中而生成)。在從始發方MMSC 820接收到整個MMS之前，它分配用於輸入MMS的文件名。文件名的URL在通知消息8C中被轉發給接收方MMS用戶代理840(考慮了用於存儲輸入MMS的標準過程)。接收方MMSC 830開始該通知過程，並將SMS與MMS的URL一起發送給接收方用戶代理840，儘管整個MMS內容在接收方MMSC 830中還不可用。
在接收方終端在線並且可用於接收輸入MMS的情況下，接收MMS用戶代理840開始檢索過程，並且使用MM1_retrieve.REQ消息8E聯繫接收方MMSC 830。接收方MMSC 830利用MM1_retrieve.REQ消息8E進行回答，儘管它還沒有完全的MMS內容(很可能接收方MMSC 830已經接收MMS內容的更多部分，因為通知過程花費一些時間)。在已經把MMS內容傳送給接收方MMS用戶代理840時，接收方MMSC 830正在從始發方MMSC 820接收MMS內容。由於MM1鏈路經常比MM4鏈路慢，因此接收方MMSC 830將具有足夠的信息來發送給接收方MMS用戶代理840。
當已經從始發方MMSC 820接收到完全MMS內容時，接收方MMSC 830利用MM4_forward.RES消息8H進行響應。
該實施方式的優點是不修改在MM1接口中的現有過程。僅僅需要基礎設施更新來改進該系統的對等發送性能。
圖9所示的第二變型主要遵循圖8的第一變型。唯一的區別是引入了轉發報頭信息的新過程。該過程被用來轉發MMS報頭和控制信息(之一或二者)(例如在初始MMS部分中，該初始MMS部分之後是包含實際MMS內容的後續MMS部分)。這允許網絡節點在處理它之前首先完全接收該傳輸。
該過程還被用來確定下一節點的能力(例如始發和接收方MMSC920、930)。在節點對出錯消息(或者根本不)進行反應的情況下，發送器可以後退到標準過程。
在圖9中描繪了第二變型的信令圖。MM1_header.[REQ|RES]消息9A、9B和MM4_header.[REQ|RES]消息9C、9D是新引入的消息，僅僅來轉發MMS報頭和控制信息。始發方MMSC 920處理該消息，並利用MM4-報頭消息建立到接收方MMSC 930的通信路徑。兩個MMSC 920、930保持處理和轉發實際MMS傳輸(可選地僅僅MMS內容)的狀態信息。
接收方MMSC 930一接收到MM4_header.REQ消息9C，就可以開始該通知過程。通知消息包含仍然為空的文件的URL。應當注意，由於MM1_notification過程的持續時間，文件可能已經包含MMS內容的部分。
當接收方MMS用戶代理940在線並且可用來接收輸入MMS時，它開始MM1檢索過程以取出內容。在最佳情形下(當接收方940也在線時)，接收方940在始發方910仍然發送時將接收MMS。
在MMS從一個伺服器被發送到一個或幾個接收方MMS UA的情形下，本發明也是有益的，因為MMS傳送的終結部分在該情況下仍然是最佳的。
本發明提供優於用於傳送多媒體數據文件的常規技術的許多優點，例如更快的傳送(接近實時)、降低的網絡和終端緩衝器的平均佔用、以及降低的處理能力要求。另外，原則上關於MMS的(最大)尺寸沒有限制。而且，由於在此所述的技術提供更有效的數據傳送，因此網絡運營商可以例如通過收取較低費用來向始發方UA提供在傳送之前細分多媒體數據文件的激勵。
儘管已經就特定實施例(包括某些系統安排和各種方法內的某些步驟順序)描述了本發明，但是本領域技術人員將認識到，本發明不限於在此所描述和所說明的特定實施例。例如，將會認識到，本發明可以被用來從第一網絡部件(比如始發方用戶代理)向第二網絡部件(比如接收方用戶代理)傳送任何類型的數據文件。還將理解，把多媒體數據文件細分成各部分可以發生在接收方MMS伺服器而不是始發方MMS伺服器中，或者甚至通過WAP網關發生(假設在數據文件部分之一中提供一個指示)。而且，可以認識到，在實行本發明時，還可能涉及在圖2和圖3中所示的各個部件。
因此，儘管已經關於本發明的優選實施例描述了本發明，但是應當理解，該公開僅僅是說明性的。所以，本發明打算僅僅由附於此的權利要求書的範圍來限定。
權利要求
1.一種從始發方向接收方傳送多媒體數據文件比如MMS的方法，所述始發方具有與其關聯的始發方伺服器，所述接收方具有與其關聯的接收方伺服器，所述方法包括以下步驟經由始發方伺服器和接收方伺服器建立從始發方到接收方的通信路徑；由接收方伺服器從始發方伺服器接收數據文件的各部分，所述數據文件或數據文件部分從始發方被上載到始發方伺服器；以及由接收方伺服器在不等待完整數據文件的接收的情況下單獨轉發從始發方伺服器所接收的數據文件部分，以用於由接收方重組。
2.權利要求1所述的方法，還包括以下步驟由接收方伺服器接收數據文件被正確地重組的確認。
3.權利要求1或2所述的方法，還包括以下步驟由接收方向接收方伺服器和/或由接收方伺服器向始發方伺服器發送一個指示數據文件部分未被接收的消息。
4.在前權利要求中任何一項所述的方法，還包括以下步驟由接收方向接收方伺服器或者由接收方伺服器向始發方伺服器發送一個指示數據文件部分已經被正確地接收的消息。
5.在前權利要求中任何一項所述的方法，還包括以下步驟由始發方伺服器和接收方伺服器中的至少一個高速緩存所接收的數據文件部分。
6.在前權利要求中任何一項所述的方法，還包括以下步驟由始發方和始發方伺服器中的至少一個把數據文件細分成有序的數據文件部分。
7.在前權利要求中任何一項所述的方法，還包括以下步驟基於由始發方伺服器和接收方伺服器中的至少一個所利用的處理能力的量，把記帳費用與數據文件的傳送相關聯。
8.在前權利要求中任何一項所述的方法，還包括以下初始步驟由接收方伺服器接收響應於來自始發方的請求而生成的來自始發方伺服器的傳送查詢，該傳送查詢包含或涉及關於數據文件的傳送的初始參數；由接收方伺服器確定是否修改初始參數；由接收方伺服器對傳送查詢發送包括或涉及最終參數的響應，所述最終參數包括初始參數的接受或已修改參數；以及由接收方伺服器接收根據最終參數所傳送的數據文件，以用於向接收方傳送。
9.權利要求8所述的方法，其中從包括以下各項的組中選擇參數數據文件內容類型、數據文件內容大小、用於編碼內容的編解碼器、數據文件的部分的數量、每個數據文件部分的大小、數據文件部分的順序編號、請求丟失的數據文件部分的過程、接收方的數量、以及所利用的確認協議。
10.權利要求8或9所述的方法，其中初始參數包含至少兩種用於把數據文件傳送給接收方的不同技術，並且響應包括所述至少兩種不同技術之一的接受或已修改參數。
11.權利要求8至10中任何一項所述的方法，其中始發方伺服器存儲該請求。
12.權利要求8至11中任何一項所述的方法，其中接收方伺服器存儲該傳送查詢。
13.權利要求8至12中任何一項所述的方法，其中始發方從至少兩個預定義的通信參數集中選擇通信參數。
14.權利要求8至13中任何一項所述的方法，還包括以下步驟由接收方伺服器把傳送查詢轉發給接收方；以及由接收方伺服器對傳送查詢接收包括最終參數的響應。
15.權利要求8至14中任何一項所述的方法，其中接收方伺服器根據預定傳送查詢標準來修改傳送查詢，並把已修改的傳送查詢轉發給接收方。
16.權利要求8至15中任何一項所述的方法，還包括以下步驟由接收方伺服器基於預定傳送標準來對傳送查詢生成響應。
17.權利要求8至16中任何一項所述的方法，還包括以下步驟把所述響應轉換成與始發方伺服器和始發方中的至少一個兼容的格式。
18.一種從始發方向接收方傳送多媒體數據文件比如MMS的方法，所述始發方具有與其關聯的始發方伺服器，所述接收方具有與其關聯的接收方伺服器，所述方法包括以下步驟經由始發方伺服器和接收方伺服器建立從始發方到接收方的通信路徑；由始發方伺服器從始發方接收數據文件或數據文件的各部分，並且如果收到數據文件，就把該數據文件分成多個數據文件部分；以及由始發方伺服器在不等待完整數據文件的接收的情況下單獨轉發從始發方接收的數據文件部分，以用於由接收方重組。
19.權利要求18所述的方法，還包括由始發方伺服器和接收方伺服器中的至少一個接收一個或多個數據文件部分，包括與該數據文件有關的報頭和控制信息中的至少一個。
20.權利要求18所述的方法，還包括由始發方伺服器從始發方接收在單個消息中的數據文件以及報頭和控制信息中的至少一個。
21.權利要求19或20所述的方法，還包括在不等待數據文件的完整接收的情況下，立即開始由始發方伺服器和接收方伺服器中的至少一個處理報頭和控制信息中的至少一個。
22.一種電腦程式產品，包括程序代碼部分，用於當電腦程式產品在一個或多個計算機或計算機系統上運行時執行在前權利要求中任何一項的步驟。
23.權利要求22所述的電腦程式產品，其中電腦程式產品被存儲在計算機可讀記錄介質上。
24.一種包括計算機處理器和與該處理器耦合的存儲器的系統，其中利用一個或多個程序對存儲器進行編碼，所述程序執行根據權利要求1至21之一所述的方法的步驟。
25.一種經由建立的通信路徑從始發方到接收方傳送多媒體數據文件比如MMS的設備，所述始發方具有與其關聯的始發方伺服器，所述設備包括接收單元，用於從始發方伺服器接收數據文件的各部分，所述數據文件或者數據文件部分從始發方被上載到始發方伺服器；以及中繼單元，用於單獨轉發從始發方伺服器接收的數據文件部分以用於由接收方重組，其中在不等待完整數據文件的接收的情況下轉發數據文件部分。
26.一種經由建立的通信路徑從始發方到接收方傳送多媒體數據文件比如MMS的設備，所述接收方具有與其關聯的接收方伺服器，所述設備包括接收單元，用於從始發方接收數據文件或數據文件的各部分，並且如果數據文件被接收，就把該數據文件分成多個數據文件部分；以及中繼單元，用於單獨轉發從始發方接收的數據文件部分以用於由接收方重組，其中在不等待完整數據文件的接收的情況下轉發數據文件部分。
27.一種經由建立的通信路徑傳送多媒體數據文件比如MMS的系統，該系統包括用於啟動數據文件的傳輸的始發方用戶代理；接收方用戶代理；與始發方用戶代理關聯的始發方伺服器；與接收方用戶代理關聯的接收方伺服器；其中始發方把數據文件或其各部分上載到始發方伺服器；其中始發方伺服器把數據文件的多個部分發送給接收方伺服器；以及其中接收方伺服器在不等待完整數據文件的接收的情況下把已接收的數據文件部分單獨轉發給接收方以用於重組。
全文摘要
提供一種從始發方向接收方傳送多媒體數據文件比如MMS的方法，所述始發方具有與其關聯的始發方伺服器，所述接收方具有與其關聯的接收方伺服器。該技術包括經由始發方伺服器和接收方伺服器建立從始發方到接收方的通信路徑。接收方伺服器接收從始發方上載到始發方伺服器的數據文件或其各部分。此後，接收方伺服器在不等待完整數據文件的接收的情況下單獨轉發從始發方伺服器接收的數據文件部分。
文檔編號H04L12/58GK101073237SQ200480044523
公開日2007年11月14日 申請日期2004年11月30日 優先權日2004年11月30日
發明者F·孔德沙伊特, R·凱勒, T·洛馬 申請人:艾利森電話股份有限公司