專利名稱：一種動態(tài)內(nèi)容發(fā)送的處理方法及系統(tǒng)的制作方法
技術領域：
本發(fā)明涉及通信領域，更具體的說，是涉及基于組播式Flute會話的一種周期性動態(tài)發(fā)送的處理方法及系統(tǒng)。
背景技術：
動態(tài)內(nèi)容發(fā)送(DCD，Dynamic Content Delivery)是基于服務端/客戶端結構，由網(wǎng)絡DCD服務端根據(jù)一定的本地策略從內(nèi)容源獲取內(nèi)容后，通過特定的觸發(fā)機制向移動終端發(fā)送內(nèi)容的技術，(可參見《移動增值數(shù)據(jù)業(yè)務總體技術要求》(0MA-AD-D⑶-V1_0)。Flute 協(xié)議是一種適合組播環(huán)境的應用層單向傳輸協(xié)議(參見多媒體通信技術標準RFC3926)。 Flute協(xié)議中采用文件發(fā)送表(FDT，F(xiàn)ile Delivery Table)對協(xié)議中發(fā)送的文件對象進行索引和描述，每個文件對象由傳輸對象標識(Τ0Ι,Transport Objectldentity)唯一進行標識和索引，并且，文件對象可被分隔為由源塊號(SBN，Source Block Number)標識的多個 Flute協(xié)議數(shù)據(jù)包。在進行動態(tài)內(nèi)容的發(fā)送時可分為拉(Pull)和推送(Push)兩種方式，在推送方式中，又可分為單播(Unicast)推送和帶寬利用率較高的組播推送(Multicast)兩種方式。現(xiàn)有技術中通常采用組播式Flute協(xié)議實現(xiàn)D⑶內(nèi)容的發(fā)送。由于，基于IP環(huán)境的組播式Flute協(xié)議實現(xiàn)中，一個應用層Flute會話對應一個用戶數(shù)據(jù)包協(xié)議(UDP，User Datagram Protocol)端口，即源IP地址、目的Multicast IP 地址、源UDP發(fā)送端口、目的UDP接收端口這四個參數(shù)對應于一個組播式Flute會話，因此， 在基于組播式Flute會話的D⑶發(fā)送方案中，采用依據(jù)UDP端口號來區(qū)分不同的D⑶頻道， 即一個應用層Flute會話對應一個D⑶頻道。但是，采用上述現(xiàn)有技術中的方案時，隨著DCD客戶端向DCD服務端訂購DCD頻道數(shù)量的增大，DCD客戶端本地需要啟動的本地Socket (套接字，應用層通過傳輸層進行數(shù)據(jù)通信時通信兩方的一種約定)資源相應增多。同時，基于組播式Flute動態(tài)內(nèi)容發(fā)送的環(huán)境中，在沒有動態(tài)內(nèi)容發(fā)送時，DCD客戶端也需要一直偵聽UDP端口，因此，采用現(xiàn)有技術的方案會造成底層組播承載資源和上層的Socket資源浪費，增加系統(tǒng)的功耗，降低系統(tǒng)對動態(tài)內(nèi)容發(fā)送的利用率。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明提供了一種動態(tài)內(nèi)容發(fā)送的處理方法及系統(tǒng)，以克服現(xiàn)有技術中基于組播式Flute動態(tài)內(nèi)容發(fā)送的環(huán)境中在沒有動態(tài)內(nèi)容發(fā)送時，D⑶客戶端仍然對UDP 端口進行偵聽所造成的底層組播承載資源和上層的Socket資源浪費，以及增加系統(tǒng)功耗， 降低系統(tǒng)對動態(tài)內(nèi)容發(fā)送的利用率的問題。為實現(xiàn)上述目的，本發(fā)明提供如下技術方案一種動態(tài)內(nèi)容發(fā)送的處理方法，包括歸類具有相同發(fā)送周期的動態(tài)內(nèi)容發(fā)送D⑶頻道；
復用歸類后的所述D⑶頻道于同一個組播式Flute會話UDP用戶數(shù)據(jù)包協(xié)議發(fā)送
端□；當位于動態(tài)內(nèi)容連續(xù)發(fā)送時間段內(nèi)時，從所述Flute UDP發(fā)送端口上依次發(fā)送歸類后的所述D⑶頻道的D⑶動態(tài)內(nèi)容；當位于靜態(tài)連續(xù)時間段內(nèi)時，停止在所述Flute UDP發(fā)送端口上發(fā)送所述D⑶頻道的D⑶動態(tài)內(nèi)容。優(yōu)選的，所述DCD動態(tài)內(nèi)容為一個傳輸對象標識的文件對象，且一個所述傳輸對象標識對應一個所述D⑶頻道的D⑶頻道標識。優(yōu)選的，所述DCD動態(tài)內(nèi)容對應相應的動態(tài)內(nèi)容生成時間戳信息。一種動態(tài)內(nèi)容發(fā)送的處理方法，包括依據(jù)預先獲取的D⑶接收處理輔助信息開啟所訂購D⑶頻道復用的Flute UDP接收端口 ；接收組播式Flute會話的文件發(fā)送表FDT ；當所述訂購的D⑶頻道的標識與所述FDT中的傳輸對象標識TOI對應的D⑶頻道標識相匹配時，則獲取匹配的所述訂購DCD頻道的DCD新動態(tài)內(nèi)容的生成時間點；當所述新動態(tài)內(nèi)容的生成時間點晚于當前DCD客戶端中存儲的原動態(tài)內(nèi)容生成時間戳時，或者當前DCD客戶端中沒有存儲DCD動態(tài)內(nèi)容及動態(tài)內(nèi)容生成時間戳時，則依據(jù)所述匹配的訂購DCD頻道，接收更新DCD動態(tài)內(nèi)容Flute數(shù)據(jù)包；當接收到第一個所述更新DCD動態(tài)內(nèi)容時，更新接收到的第一個DCD動態(tài)內(nèi)容接收時間點，并啟動DCD動態(tài)內(nèi)容接收超時計時；更新存儲于當前DCD客戶端存儲的DCD動態(tài)內(nèi)容，以及更新DCD動態(tài)內(nèi)容對應的動態(tài)內(nèi)容生成時間戳作為當前動態(tài)內(nèi)容生成時間戳；當接收更新啟動的所述DCD動態(tài)內(nèi)容接收超時時長到達當前接收超時時長時，則關閉Flute UDP接收端口，同時保持當前接收超時時長不變；當接收更新啟動的所述DCD動態(tài)內(nèi)容接收超時時長未到達當前接收超時時長，且接收到所有訂購的D⑶頻道的更新D⑶動態(tài)內(nèi)容時，關閉所述Flute UDP接收端口，并修正當前接收超時時長為此時所述DCD動態(tài)內(nèi)容接收超時計時的值；依據(jù)所述D⑶動態(tài)內(nèi)容當前接收超時時長計算下次Flute UDP接收端口的開啟時間點。優(yōu)選的，在開啟所訂購D⑶頻道復用的Flute UDP接收端口之前，包括通過訂購D⑶頻道，獲取所述訂購D⑶頻道的D⑶接收處理輔助信息；所述D⑶接收處理輔助信息包括周期信息、所訂購DCD頻道標識信息、參考超時時長信息和接入承載
fn息ο優(yōu)選的，當所述訂購的DCD頻道的標識與所述FDT中的傳輸對象標識TOI對應的 D⑶頻道標識不匹配時，返回執(zhí)行接收組播式Flute會話的文件發(fā)送表FDT這一步驟。優(yōu)選的，當所述新動態(tài)內(nèi)容的生成時間點不晚于當前DCD客戶端中存儲的原動態(tài)內(nèi)容生成時間戳時，返回執(zhí)行接收組播式Flute會話的文件發(fā)送表FDT這一步驟。優(yōu)選的，所述修正的DCD動態(tài)內(nèi)容接收超時時長為上述執(zhí)行過程中，最后接收到的DCD動態(tài)內(nèi)容的接收時間點減去第一個接收到的DCD動態(tài)內(nèi)容的接收時間點。
5
優(yōu)選的，獲得的下次開啟時間點為上述執(zhí)行過程中，接收到第一個DCD動態(tài)內(nèi)容的時間點加上一個發(fā)送周期，再減去兩個動態(tài)內(nèi)容接收超時時長。一種動態(tài)內(nèi)容發(fā)送的處理系統(tǒng)，包括DCD服務端，用于對不同的DCD業(yè)務應用依據(jù)周期性發(fā)送的時間間隔進行分類，使每個D⑶業(yè)務對應一個D⑶頻道，并將具有相同發(fā)送周期時間間隔的D⑶頻道在同一個組播式Flute UDP會話中進行混合發(fā)送；D⑶客戶端，用于接收D⑶服務端進行混合發(fā)送的D⑶頻道及相關信息，并在每個發(fā)送周期的靜態(tài)連續(xù)時段，關閉相應的Flute UDP接收端口。經(jīng)由上述的技術方案可知，與現(xiàn)有技術相比，本發(fā)明公開了一種動態(tài)內(nèi)容發(fā)送的處理方法及系統(tǒng)，基于周期性動態(tài)內(nèi)容發(fā)送的特征，通過將具有同樣動態(tài)內(nèi)容發(fā)送周期需求的D⑶頻道動態(tài)內(nèi)容在同一個UDP端口(或同一個Flute會話)上混合發(fā)送，實現(xiàn)了一個組播式Flute會話UDP端口上的D⑶頻道復用；同時，實現(xiàn)了 D⑶客戶端基于周期時間的合理UDP端口接收進程的啟動和釋放。并且使DCD客戶端只有在DCD服務端側有組播式動態(tài)內(nèi)容發(fā)送時才需啟動UDP端口接收進程并進行偵聽，在其余時間則關閉UDP端口接收進程， 能夠降低對底層組播承載資源和上層的Socket資源浪費，減少系統(tǒng)的功耗，以及增加系統(tǒng)對動態(tài)內(nèi)容發(fā)送的利用率。


為了更清楚地說明本發(fā)明實施例或現(xiàn)有技術中的技術方案，下面將對實施例或現(xiàn)有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本發(fā)明的實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)提供的附圖獲得其他的附圖。圖1為本發(fā)明實施例一公開的一種動態(tài)內(nèi)容發(fā)送的處理方法流程圖；圖2為本發(fā)明實施例一公開的一種動態(tài)內(nèi)容發(fā)送的處理方法的具體示例圖；圖3為本發(fā)明實施例二公開的一種動態(tài)內(nèi)容發(fā)送的處理方法流程圖；圖4為本發(fā)明實施例公開的一種動態(tài)內(nèi)容發(fā)送的處理系統(tǒng)流程圖。
具體實施例方式為了引用和清楚起見，下文中使用的技術名詞的說明、簡寫或縮寫總結如下DCD Dynamic Content Delivery，動態(tài)內(nèi)容發(fā)送；Flute 是一種適合組播環(huán)境的應用層單向傳輸協(xié)議(參見多媒體通信技術標準 RFC3926)；OMA-AD-DOT-VIJ)移動增值動態(tài)內(nèi)容發(fā)送數(shù)據(jù)業(yè)務總體技術要求；FDT =File Delivery Table，文件發(fā)送表；TOI transport Object Identity，傳輸對象標識；SBN =Source Block Number，源塊號標識；UDP =User Datagram Protocol，用戶數(shù)據(jù)包協(xié)議；Flute UDP 為基于Flute協(xié)議的UDP發(fā)送端口或UDP接收端口 ；頻道動態(tài)內(nèi)容發(fā)送業(yè)務下發(fā)的組織形式，是內(nèi)容發(fā)送和計費的最小單元。
下面將結合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明一部分實施例，而不是全部的實施例。基于本發(fā)明中的實施例，本領域普通技術人員在沒有做出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。在動態(tài)內(nèi)容發(fā)送應用業(yè)務中，周期性動態(tài)內(nèi)容發(fā)送是指對每個DCD頻道，DCD服務端以固定的時間間隔周期性的發(fā)送對應該D⑶頻道的動態(tài)內(nèi)容。這類發(fā)送方式具有兩個顯著特征其一，不同的應用需求特征決定不同的發(fā)送周期要求，同時很多同類應用具有同一或類似的發(fā)送周期需求。例如，軟件包的更新以幾個月為發(fā)送周期；廣告信息則以幾天為一個發(fā)送周期；天氣預報的更新則以一天為一個發(fā)送周期；財經(jīng)信息則以半小時為一個發(fā)送周期。同時，隨著動態(tài)發(fā)送業(yè)務的擴展，很多軟件包更新可依據(jù)相同的發(fā)送周期發(fā)送，很多廣告信息也可依據(jù)相同的發(fā)送周期發(fā)送。其二，在一個發(fā)送周期內(nèi)，動態(tài)內(nèi)容的發(fā)送時長遠遠小于發(fā)送周期時間間隔。本發(fā)明基于上述周期性動態(tài)內(nèi)容發(fā)送的特征，提出了基于組播式Flute會話的一種周期性動態(tài)內(nèi)容發(fā)送的處理方法及系統(tǒng)，通過將具有同樣動態(tài)內(nèi)容發(fā)送周期需求的DCD 頻道動態(tài)內(nèi)容在同一個UDP端口(或同一個Flute會話)上混合發(fā)送，實現(xiàn)了一個組播式 Flute會話UDP端口上的D⑶頻道復用；同時，實現(xiàn)了 D⑶客戶端基于周期時間的合理UDP 端口接收進程的啟動和釋放。并且使DCD客戶端只有在DCD服務端側有組播式動態(tài)內(nèi)容發(fā)送時才需啟動UDP端口接收進程并進行偵聽，在其余時間則關閉UDP端口接收進程，能夠降低對底層組播承載資源和上層的Socket資源浪費，減少系統(tǒng)的功耗，以及增加系統(tǒng)對動態(tài)內(nèi)容發(fā)送的利用率。并且能夠進一步確定組播承載資源的釋放及建立時間點。其中，通過在Flute協(xié)議的原有FDT中引入D⑶頻道標識信息及動態(tài)內(nèi)容生成時間戳信息，實現(xiàn)同一 Flute UDP 端口上的不同DCD頻道區(qū)分以及DCD客戶端對動態(tài)內(nèi)容的更新判斷。具體執(zhí)行方案將通過以下實施例進行詳細說明。實施例一請參閱附圖1，為本發(fā)明實施例一公開的一種動態(tài)內(nèi)容發(fā)送的處理方法流程圖，在本實施例中主要描述了 DCD服務端在一個發(fā)送周期內(nèi)發(fā)送復用同一個Flute UDP的具有相同發(fā)送周期的多個DCD頻道動態(tài)內(nèi)容的示例，主要包括以下步驟步驟S101，D⑶服務端將具有相同發(fā)送周期T的D⑶頻道進行歸類。在執(zhí)行步驟SlO 1，本發(fā)明所公開的本實施例在D⑶服務端側，對不同的D⑶業(yè)務應用依據(jù)周期性發(fā)送的時間間隔進行分類，且每個DCD業(yè)務對應一個DCD頻道，即將具有相同發(fā)送周期T的D⑶頻道進行歸類。步驟S102，將歸類后的所述D⑶頻道復用于同一個Flute UDP發(fā)送端口上。需要說明的是，為了區(qū)分復用在同一Flute UDP發(fā)送端口上的不同D⑶頻道的D⑶ 動態(tài)內(nèi)容，在Flute協(xié)議的原有FDT中引入D⑶頻道標識信息。在組播式Flute會話中， FDT中的一個以TOI標識的文件對象為一個D⑶動態(tài)內(nèi)容，并且，一個TOI同時唯一對應一個D⑶頻道標識，以此表明其對應的文件對象所屬的D⑶頻道，即該TOI所屬的D⑶頻道。 在本發(fā)明公開的該實施例中DCD服務端在其發(fā)送的FDT中加入了 TOI所對應的DCD頻道信肩、ο
步驟S103，在動態(tài)內(nèi)容連續(xù)發(fā)送時間段內(nèi)，在所述Flute UDP發(fā)送端口上依次發(fā)送歸類后的所述DCD頻道的DCD動態(tài)內(nèi)容。在執(zhí)行步驟S102和步驟S103時，將具有相同發(fā)送周期時間間隔的D⑶頻道在同一個組播式Flute UDP會話中進行混合發(fā)送，即復用一個UDP端口發(fā)送具有相同發(fā)送周期的D⑶頻道動態(tài)內(nèi)容。在D⑶服務端在Flute UDP發(fā)送端口上依次發(fā)送D⑶頻道的D⑶動態(tài)內(nèi)容時，采用Flute數(shù)據(jù)包的方式在這個發(fā)送周期的起始點連續(xù)發(fā)送。需要說明的是，在Flute協(xié)議的原有FDT中還引入動態(tài)內(nèi)容生成時間戳信息，所謂動態(tài)內(nèi)容生成時間戳信息為當前DCD服務端側DCD頻道動態(tài)內(nèi)容的生成時間點。由于，在 DCD服務端根據(jù)發(fā)送周期發(fā)送DCD動態(tài)內(nèi)容時，該DCD動態(tài)內(nèi)容可能是剛更新過的動態(tài)內(nèi)容，也可能是已經(jīng)發(fā)送過的還尚未更新的動態(tài)內(nèi)容。因此，對應每個TOI，D⑶服務端在FDT 中加入相對應的動態(tài)內(nèi)容生成時間戳信息，即DCD服務端在FDT中加入了以TOI標識的文件對象的動態(tài)內(nèi)容生成時間點信息，使發(fā)送的DCD頻道攜帶有其動態(tài)內(nèi)容生成時間戳。步驟S104，在靜態(tài)連續(xù)時間段內(nèi)，停止在所述Flute UDP發(fā)送端口上發(fā)送所述D⑶ 頻道的D⑶動態(tài)內(nèi)容。在上述本發(fā)明公開的實施例中，描述的是在DCD服務端側，采用對不同的DCD業(yè)務應用依據(jù)周期性發(fā)送的時間間隔進行分類，使具有相同發(fā)送周期時間間隔的DCD頻道在同一個組播式Flute UDP會話中進行混合發(fā)送，并且，在動態(tài)內(nèi)容連續(xù)發(fā)送時間段內(nèi)進行發(fā)送，在靜態(tài)連續(xù)時間段內(nèi)停止發(fā)送。其中，動態(tài)內(nèi)容連續(xù)發(fā)送時間段為從一個發(fā)送周期的起始點開始至發(fā)送所有DCD頻道的DCD動態(tài)內(nèi)容的連續(xù)時間段；靜態(tài)連續(xù)時間段為停止發(fā)送DCD動態(tài)內(nèi)容的連續(xù)時間段。需要說明的是D⑶服務端連續(xù)發(fā)送復用同一 UDP端口的所有D⑶頻道的D⑶動態(tài)內(nèi)容時，其具有從發(fā)送周期起始點開始的發(fā)送所有DCD動態(tài)內(nèi)容的連續(xù)時長遠遠小于靜態(tài)連續(xù)剩余時段的特點，即動態(tài)內(nèi)容連續(xù)發(fā)送時間段遠遠小于靜態(tài)連續(xù)時間段。另外，對應于每個發(fā)送周期的靜態(tài)連續(xù)時段，接收DCD服務端所發(fā)送DCD動態(tài)內(nèi)容的DCD客戶端關閉相應的UDP端口接收進程。請參閱附圖2，對上述本發(fā)明所公開的執(zhí)行過程進行舉例說明如圖2所示，D⑶頻道A、D⑶頻道B、D⑶頻道C具有相同的發(fā)送周期T，因此復用于同一個Flute UDP上進行混合發(fā)送。在從TO開始至T2結束的一個發(fā)送周期，D⑶服務端對這三個頻道的DCD動態(tài)內(nèi)容以Flute數(shù)據(jù)包的方式在這個發(fā)送周期的起始點連續(xù)發(fā)送。 TO至Tl時段為該Flute UDP會話上連續(xù)發(fā)送D⑶動態(tài)內(nèi)容的時段(圖2中用D標示)，Tl 至T2為發(fā)送周期的靜態(tài)連續(xù)剩余時段(圖2中用E標示)，靜態(tài)連續(xù)剩余時段內(nèi)，沒有任何 D⑶動態(tài)內(nèi)容發(fā)送。從T2時間點開始，又開始一個類似的新的發(fā)送周期循環(huán)。依據(jù)上述本發(fā)明所公開的實施例中的說明，在該示例中，TOI與DCD頻道的對應關系由FDT中引入的D⑶頻道標識指示。在TO至Tl的動態(tài)內(nèi)容連續(xù)發(fā)送時段內(nèi)，TOI為1的文件對象屬于D⑶頻道A，該文件對象包括兩個SNB為1和2的Flute數(shù)據(jù)包；TOI為2的文件對象屬于D⑶頻道B，該文件對象只有一個SNB為1的Flute數(shù)據(jù)包；TOI為3的文件對象屬于D⑶頻道C，該文件對象包括兩個SNB為1和2的兩個Flute數(shù)據(jù)包。需要說明的是，在上述本發(fā)明實施例公開的動態(tài)內(nèi)容發(fā)送的處理方法的基礎上， D⑶服務端通過D⑶訂購過程(D⑶訂購過程可參見0MA-AD-DOT-V1_0)向D⑶客戶端提供D⑶接收處理輔助信息，所述D⑶接收處理輔助信息包括周期信息、所訂購D⑶頻道標識信息、參考超時時長信息和接入承載信息。其中，一個發(fā)送周期表示一個固定的時間間隔，每經(jīng)過這個時間間隔，即一個發(fā)送周期，D⑶服務器就通過源UDP發(fā)送端口(Flute UDP發(fā)送端口)向組播地址的目的UDP接收端口(D⑶客戶端開啟的Flute UDP接收端口)，發(fā)送復用該Flute UDP地址上的所有D⑶ 頻道動態(tài)內(nèi)容；采用D⑶頻道標識區(qū)分一個Flute UDP發(fā)送端口上的多個D⑶頻道，而且， 一個發(fā)送周期可對應多個不同的D⑶頻道標識，即按照發(fā)送周期是否相同對D⑶頻道分類； 同時，一個發(fā)送周期也對應一個接入承載信息，即具有相同發(fā)送周期的不同DCD頻道復用同一個Flute UDP發(fā)送端口承載進行動態(tài)內(nèi)容發(fā)送；接入承載信息則包括源IP地址、目的組播(Multicast) IP地址、源UDP發(fā)送端口和目的UDP接收端口這四個參數(shù)；一個參考超時時長對應于一個發(fā)送周期，參考超時時長是DCD服務端側計算的一個發(fā)送周期內(nèi)，基于從開始發(fā)送第一個D⑶頻道動態(tài)內(nèi)容到完成復用同一個Flute UDP端口的所有D⑶頻道動態(tài)內(nèi)容發(fā)送的時長選擇的一個等量級時長，即基于動態(tài)內(nèi)容連續(xù)發(fā)送時間段長度選擇的一個等量級時長。該參考超時時長選擇的原則是遠小于靜態(tài)連續(xù)剩余時段的時長；與動態(tài)內(nèi)容連續(xù)發(fā)送時段時長處于一個量級；大于服務端計算的連續(xù)發(fā)送時段時長。基于該原則，實施例中可將參考超時時長設置為服務器端計算的連續(xù)發(fā)送時長的兩倍。實施例二請參閱附圖3，為本發(fā)明實施例二公開的一種動態(tài)內(nèi)容發(fā)送的處理方法流程圖，本實施例二主要描述D⑶客戶端接收所訂購D⑶頻道的D⑶動態(tài)內(nèi)容的一個處理循環(huán)過程， 主要包括以下步驟步驟S201，D⑶客戶端通過D⑶訂購過程，獲取訂購D⑶頻道的D⑶接收處理輔助信息，并依據(jù)所述DCD接收處理輔助信息中的接入承載信息進入DCD動態(tài)內(nèi)容的接收處理過程中。在執(zhí)行步驟S201時，客戶端通過D⑶訂購過程(D⑶訂購過程參見 0MA-AD-Dra-Vl_0)獲取所訂購D⑶頻道的D⑶接收處理輔助信息(該D⑶接收處理輔助信息為DCD服務端通過DCD訂購過程向DCD客戶端提供的)，并且，可以隨時進行所訂購DCD 頻道的DCD動態(tài)內(nèi)容的接收。在所進入的DCD客戶端的DCD動態(tài)內(nèi)容接收處理過程中包括加入/退出組播、開啟/關閉UDP接收和基于Flute協(xié)議的D⑶動態(tài)內(nèi)容接收處理。其中，D⑶客戶端根據(jù)接收的所述接入承載信息，可隨時加入或退出組播(加入及退出組播過程可參見 3GPP TS 26. 346)。需要說明的是，在D⑶客戶端獲取訂購D⑶頻道的D⑶接收處理輔助信息中包括 周期信息、所訂購DCD頻道標識信息、參考超時時長信息和接入承載信息。其中，接入承載信息則包括源IP地址、目的組播IP地址、源UDP發(fā)送端口和目的UDP接收端口這四個參數(shù)。步驟S202，D⑶客戶端開啟所訂購D⑶頻道復用的Flute UDP接收端口。所述 Flute UDP接收端口為訂購過程中獲取的所述DCD接收處理輔助信息中的目的UDP接收端步驟S203，DCD客戶端接收組播式Flute會話的FDT。
在步驟S203中，在組播式Flute會話中，通過FDT對Flute協(xié)議中發(fā)送的文件對象進行索引和描述，每個文件對象由TOI唯一進行標識和索引，并且，一個TOI同時唯一對應一個DCD頻道標識，以此表明其對應的文件對象所屬的DCD頻道，即該TOI所屬的DCD頻道。此外，同一文件對象可被分隔為由同一頻道信息標識的多個有不同源塊號標識(SBN) 的Flute協(xié)議數(shù)據(jù)包。步驟S204，D⑶客戶端基于所述FDT中的D⑶頻道標識信息，對所述訂購D⑶頻道進行匹配，即判斷所述訂購的D⑶頻道的標識是否有與所述FDT中Flute文件對象TOI對應的D⑶頻道標識相匹配，如果沒有，則返回執(zhí)行步驟203 ；如果有，則轉(zhuǎn)而執(zhí)行步驟205。
在步驟S204中，D⑶客戶端將FDT中Flute文件對象TOI對應的D⑶頻道標識與訂購過程獲取的訂購D⑶頻道的標識信息對比，以便于可以找出所訂購D⑶頻道標識對應的Flute文件對象TOI。步驟S205，D⑶客戶端獲取匹配的所述訂購D⑶頻道的D⑶動態(tài)內(nèi)容的生成時間點，即所述訂購DCD頻道的DCD動態(tài)內(nèi)容生成時間戳(新動態(tài)內(nèi)容生成時間戳)，并判斷其是否晚于對應的當前DCD客戶端中存儲的DCD動態(tài)內(nèi)容對應的動態(tài)內(nèi)容生成時間戳(原動態(tài)內(nèi)容生成時間戳)，如果是，或者當前DCD客戶端中沒有存儲DCD動態(tài)內(nèi)容及動態(tài)內(nèi)容生成時間戳，則轉(zhuǎn)而執(zhí)行步驟S206 ；如果否，則返回執(zhí)行步驟S203。在執(zhí)行步驟S205時，依據(jù)執(zhí)行步驟S204獲得的Flute文件對象TOI匹配的所述訂購的DCD頻道的動態(tài)內(nèi)容生成時間戳，與該TOI所屬DCD頻道的當前客戶端存儲的動態(tài)內(nèi)容對應的動態(tài)內(nèi)容生成時間戳進行比較。若前者晚于后者，說明該Flute文件對象為更新的DCD動態(tài)內(nèi)容，或者當前的DCD客戶端首次接收動態(tài)內(nèi)容，即當前DCD客戶端中沒有存儲的動態(tài)內(nèi)容及動態(tài)內(nèi)容生成時間戳，則轉(zhuǎn)而執(zhí)行更新的步驟；否則相反的，說明該Flute 文件對象不是更新的DCD動態(tài)內(nèi)容，返回重新執(zhí)行接收組播式Flute會話的FDT的步驟。步驟206，D⑶客戶端與Flute文件對象TOI匹配的所述訂購D⑶頻道，接收更新的DCD動態(tài)內(nèi)容Flute數(shù)據(jù)包，在DCD客戶端接收到第一個更新DCD動態(tài)內(nèi)容時啟動DCD 動態(tài)內(nèi)容接收超時計時，并更新接收到的第一個DCD動態(tài)內(nèi)容接收時間點。同時，更新存儲于當前DCD客戶端存儲的DCD動態(tài)內(nèi)容，以及更新DCD動態(tài)內(nèi)容對應的動態(tài)內(nèi)容生成時間戳作為當前動態(tài)內(nèi)容生成時間戳。在執(zhí)行步驟S206中，主要是依據(jù)執(zhí)行步驟S204中找出的更新D⑶動態(tài)內(nèi)容對應的Flute文件對象TOI，接收更新D⑶動態(tài)內(nèi)容Flute數(shù)據(jù)包。需要說明的是，當DCD客戶端首次接收DCD動態(tài)內(nèi)容時，動態(tài)內(nèi)容當前接收超時時長為訂購過程接收到的參考超時時長。所述參考超時時長為DCD接收處理輔助信息中的一部分，該DCD接收處理輔助信息為DCD服務端通過DCD訂購過程向DCD客戶端提供的。具體的，該參考超時時長為D⑶服務端側計算的一個發(fā)送周期內(nèi)，從開始發(fā)送第一個D⑶頻道動態(tài)內(nèi)容到完成復用同一個Flute UDP端口的所有DCD頻道動態(tài)內(nèi)容發(fā)送的時長的兩倍。步驟S207，判斷所述DCD客戶端接收更新啟動的所述DCD動態(tài)內(nèi)容接收超時是否到達當前接收超時時長，如果是，則執(zhí)行步驟S208，同時保持本次的當前接收超時時長保持不變，使其作為下次的當前接收超時時長；如果否，則執(zhí)行步驟S209。步驟S208，DCD客戶端關閉Flute UDP接收端口，轉(zhuǎn)入執(zhí)行步驟211。在步驟S208中，當所述DCD動態(tài)內(nèi)容接收超時等于當前接收超時時長，則關閉Flute UDP 接收端口。步驟S209，D⑶客戶端偵聽接收所訂購的所有更新的D⑶動態(tài)內(nèi)容，并判斷D⑶客戶端是否接收到所有訂購的DCD頻道的更新DCD動態(tài)內(nèi)容，如果是，則執(zhí)行步驟S210，如果否，則返回執(zhí)行步驟S207。在執(zhí)行步驟S209時，當DCD動態(tài)內(nèi)容接收超時時長未達到當前接收超時時長，DCD 客戶端一直偵聽接收所訂購的所有DCD頻道更新的DCD動態(tài)內(nèi)容。步驟S210，D⑶客戶端關閉所述Flute UDP接收端口，并修正當前接收超時時長。在執(zhí)行步驟S210時所進行的修正，即修正當前接收超時時長等于本次處理循環(huán)接收到所有訂購DCD頻道的更新DCD內(nèi)容的時刻，所述DCD動態(tài)內(nèi)容接收超時計時值。即該次處理循環(huán)中最后接收到的DCD動態(tài)內(nèi)容的接收時間點減去第一個接收到的DCD動態(tài)內(nèi)容的接收時間點。步驟S211，D⑶客戶端計算下次Flute UDP接收端口的開啟時間點。在步驟S211中所獲得的下次開啟時間點為本次處理循環(huán)接收到第一個DCD動態(tài)內(nèi)容的時間點加上一個發(fā)送周期再減去2個當前動態(tài)內(nèi)容接收超時時長。上述執(zhí)行步驟S202至步驟S211的過程為D⑶客戶端接收所訂購D⑶頻道的D⑶ 動態(tài)內(nèi)容的一個處理循環(huán)過程。在通過執(zhí)行步驟S211得到了下次Flute UDP接收的開啟時間點，并且在下次開啟Flute UDP接收端口的開啟時間點到達時，開始下一個處理循環(huán)。需要說明的是，在執(zhí)行上述本發(fā)明實施例公開的每個處理循環(huán)中(DCD客戶端每接收D⑶服務器一個發(fā)送周期的D⑶動態(tài)內(nèi)容的接收處理過程稱為一個處理循環(huán))，D⑶客戶端需要計算其Flute UDP接收端口的下次關閉時間點和下次開啟時間點。為實現(xiàn)DCD客戶端對Flute UDP接收端口的開啟/關閉時間點計算，在本發(fā)明所公開的實施例中采用DCD 當前動態(tài)內(nèi)容接收超時時長作為計算時間點的依據(jù)?？梢岳卯斍皠討B(tài)內(nèi)容接收超時時長來衡量一個處理循環(huán)中，DCD客戶端連續(xù)偵聽該UDP端口以接收復用該端口的所有DCD頻道動態(tài)內(nèi)容的最大時長。在DCD客戶端首次進行接收DCD動態(tài)內(nèi)容時，DCD當前動態(tài)內(nèi)容接收超時時長的初始值設置為訂購過程DCD客戶端接收到的參考超時時長。并且，當DCD客戶端在一個處理循環(huán)中接收到復用于Flute UDP端口上的所有訂購DCD頻道動態(tài)內(nèi)容時，對動態(tài)內(nèi)容接收超時時長進行修正，即修正當前接收超時時長為最新的接收所有DCD動態(tài)內(nèi)容的時長， 即該次處理循環(huán)中最后接收到的DCD動態(tài)內(nèi)容的接收時間點減去第一個接收到的DCD動態(tài)內(nèi)容的接收時間點。另外，在本發(fā)明上述實施例公開每次處理循環(huán)中，對Flute UDP接收端口的下次關閉時間點和下次開啟時間點進行設置。具體的設置方法如下所述其中，對Flute UDP接收端口的下次關閉時間點進行設置的方法為其一，在本次處理循環(huán)接收到第一個D⑶動態(tài)內(nèi)容的時間點開始計時，到一個當前動態(tài)內(nèi)容接收超時時長結束，如果未能接收到所有復用該端口的DCD頻道動態(tài)內(nèi)容，則下次關閉時間點為本次處理循環(huán)接收到第一個DCD動態(tài)內(nèi)容的時間點加上一個當前動態(tài)內(nèi)容接收超時時長。其二，在本次處理循環(huán)接收到第一個D⑶動態(tài)內(nèi)容的時間點開始計時，到一個動態(tài)內(nèi)容接收超時時長結束之前，接收到了所有復用該端口的DCD頻道動態(tài)內(nèi)容，則下次關時間點。其中，對Flute UDP接收端口的下次開啟時間點進行設置的方法為本次處理循環(huán)接收到第一個DCD動態(tài)內(nèi)容的時間點加上一個發(fā)送周期再減去2個動態(tài)內(nèi)容接收超時時長。通過上述的設置開啟及關閉時間，可以保證下一個D⑶服務器動態(tài)內(nèi)容發(fā)送周期開始前，D⑶客戶端以一定時間余量提前開啟Flute UDP接收，并保證這個時間余量遠小于靜態(tài)連續(xù)剩余時段；同時使DCD客戶端關閉Flute UDP接收的時長接近靜態(tài)連續(xù)剩余時段， 即每個發(fā)送周期的靜態(tài)連續(xù)時段。并且，在D⑶客戶端的處理循環(huán)過程中，D⑶客戶端可根據(jù)FluteUDP接收的關閉時間點信息及開啟時間點信息確定相應的組播退出和加入時間點，組播退出時，通過釋放相應的組播承載資源，節(jié)省了組播承載資源，提高了利用率。需要說明的是，在本發(fā)明實施例中組播退出和加入分兩種情形。第一種情形是D⑶ 客戶端所訂購的D⑶頻道都復用于同一個Flute UDP，這時的組播加入同F(xiàn)lute UDP接收的開啟時間點，組播的退出時間點同F(xiàn)luteUDP接收的關閉時間點。第二種情形是DCD客戶端所訂購的D⑶頻道復用在多個Flute UDP上，這時只有所有Flute UDP接收均關閉后D⑶客戶端才能退出組播，退出組播后，當其中的任一個Flute UDP接收的開啟時間點到達時D⑶ 客戶端加入組播。上述本發(fā)明公開的實施例中詳細描述了一種動態(tài)內(nèi)容發(fā)送的處理方法，對于本發(fā)明的方法可采用多種形式的系統(tǒng)實現(xiàn)，因此本發(fā)明還公開了一種動態(tài)內(nèi)容發(fā)送的處理系統(tǒng)，下面給出具體的實施例進行詳細說明。請參閱附圖4，為本發(fā)明實施例公開的一種動態(tài)內(nèi)容發(fā)送的處理系統(tǒng)結構示意圖。 主要包括D⑶服務端401和D⑶客戶端402。所述DCD服務端401，用于對不同的DCD業(yè)務應用依據(jù)周期性發(fā)送的時間間隔進行分類，使每個DCD業(yè)務對應一個DCD頻道，并將具有相同發(fā)送周期時間間隔的DCD頻道在同一個組播式Flute UDP會話中進行混合發(fā)送。所述D⑶客戶端402，用于接收D⑶服務端401進行混合發(fā)送的D⑶頻道及相關信息，并在每個發(fā)送周期的靜態(tài)連續(xù)時段，關閉相應的FluteUDP接收端口。上述D⑶服務端401和D⑶客戶端402的具體執(zhí)行過程分別對應于上述本發(fā)明公開的實施例一和實施例二中的內(nèi)容，這里不再贅述。綜上所述通過本發(fā)明上述實施例公開的方法及系統(tǒng)，基于相同的發(fā)送周期特性對多個DCD 頻道在同一 Flute UDP會話上復用，使多個具有發(fā)送周期的D⑶頻道的動態(tài)內(nèi)容在同一 Flute UDP會話上混合傳輸，且D⑶動態(tài)內(nèi)容在發(fā)送周期的起始點開始連續(xù)發(fā)送。從而在實現(xiàn)Flute UDP會話多個D⑶頻道復用的同時，使一個發(fā)送周期內(nèi)形成明顯的D⑶動態(tài)內(nèi)容發(fā)送連續(xù)時段與靜態(tài)連續(xù)剩余時段。通過對已有FDT的改進及DCD訂購時段DCD服務器發(fā)送給DCD客戶端的DCD接收處理輔助信息，實現(xiàn)了 DCD客戶端DCD動態(tài)內(nèi)容發(fā)送的有效接收及靜態(tài)連續(xù)剩余時段的接收資源釋放，達到降低對底層組播承載資源和上層的Socket 資源浪費，減少系統(tǒng)的功耗，以及增加系統(tǒng)對動態(tài)內(nèi)容發(fā)送的利用率的目的。本說明書中各個實施例采用遞進的方式描述，每個實施例重點說明的都是與其他
12實施例的不同之處，各個實施例之間相同相似部分互相參見即可。對于實施例公開的裝置而言，由于其與實施例公開的方法相對應，所以描述的比較簡單，相關之處參見方法部分說明即可。結合本文中所公開的實施例描述的方法或算法的步驟可以直接用硬件、處理器執(zhí)行的軟件模塊，或者二者的結合來實施。軟件模塊可以置于隨機存儲器(RAM)、內(nèi)存、只讀存儲器(ROM)、電可編程ROM、電可擦除可編程ROM、寄存器、硬盤、可移動磁盤、CD-ROM、或技術領域內(nèi)所公知的任意其它形式的存儲介質(zhì)中。對所公開的實施例的上述說明，使本領域?qū)I(yè)技術人員能夠?qū)崿F(xiàn)或使用本發(fā)明。 對這些實施例的多種修改對本領域的專業(yè)技術人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本發(fā)明的精神或范圍的情況下，在其它實施例中實現(xiàn)。因此，本發(fā)明將不會被限制于本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的范圍。
權利要求
1.一種動態(tài)內(nèi)容發(fā)送的處理方法，其特征在于，包括 歸類具有相同發(fā)送周期的動態(tài)內(nèi)容發(fā)送D⑶頻道；復用歸類后的所述D⑶頻道于同一個組播式Flute會話UDP用戶數(shù)據(jù)包協(xié)議發(fā)送端Π ；當位于動態(tài)內(nèi)容連續(xù)發(fā)送時間段內(nèi)時，從所述Flute UDP發(fā)送端口上依次發(fā)送歸類后的所述DCD頻道的DCD動態(tài)內(nèi)容；當位于靜態(tài)連續(xù)時間段內(nèi)時，停止在所述Flute UDP發(fā)送端口上發(fā)送所述DCD頻道的 D⑶動態(tài)內(nèi)容。
2.根據(jù)權利要求1所述的方法，其特征在于，所述DCD動態(tài)內(nèi)容為一個傳輸對象標識的文件對象，且一個所述傳輸對象標識對應一個所述D⑶頻道的D⑶頻道標識。
3.根據(jù)權利要求1所述的方法，其特征在于，所述DCD動態(tài)內(nèi)容對應相應的動態(tài)內(nèi)容生成時間戳信息。
4.一種動態(tài)內(nèi)容發(fā)送的處理方法，其特征在于，包括依據(jù)預先獲取的D⑶接收處理輔助信息開啟所訂購D⑶頻道復用的Flute UDP接收端Π ；接收組播式Flute會話的文件發(fā)送表FDT ；當所述訂購的DCD頻道的標識與所述FDT中的傳輸對象標識TOI對應的DCD頻道標識相匹配時，則獲取匹配的所述訂購DCD頻道的DCD新動態(tài)內(nèi)容的生成時間點；當所述新動態(tài)內(nèi)容的生成時間點晚于當前DCD客戶端中存儲的原動態(tài)內(nèi)容生成時間戳時，或者當前DCD客戶端中沒有存儲DCD動態(tài)內(nèi)容及動態(tài)內(nèi)容生成時間戳時，則依據(jù)所述匹配的訂購D⑶頻道，接收更新D⑶動態(tài)內(nèi)容Flute數(shù)據(jù)包；當接收到第一個所述更新DCD動態(tài)內(nèi)容時，更新接收到的第一個DCD動態(tài)內(nèi)容接收時間點，并啟動DCD動態(tài)內(nèi)容接收超時計時；更新存儲于當前DCD客戶端存儲的DCD動態(tài)內(nèi)容，以及更新DCD動態(tài)內(nèi)容對應的動態(tài)內(nèi)容生成時間戳作為當前動態(tài)內(nèi)容生成時間戳；當接收更新啟動的所述DCD動態(tài)內(nèi)容接收超時時長到達當前接收超時時長時，則關閉 Flute UDP接收端口，同時保持當前接收超時時長不變；當接收更新啟動的所述DCD動態(tài)內(nèi)容接收超時時長未到達當前接收超時時長，且接收到所有訂購的D⑶頻道的更新D⑶動態(tài)內(nèi)容時，關閉所述Flute UDP接收端口，并修正當前接收超時時長為此時所述DCD動態(tài)內(nèi)容接收超時計時的值；依據(jù)所述DCD動態(tài)內(nèi)容當前接收超時時長計算下次Flute UDP接收端口的開啟時間點ο
5.根據(jù)權利要求4所述的方法，其特征在于，在開啟所訂購DCD頻道復用的FluteUDP 接收端口之前，包括通過訂購DCD頻道，獲取所述訂購DCD頻道的DCD接收處理輔助信息；所述DCD接收處理輔助信息包括周期信息、所訂購DCD頻道標識信息、參考超時時長信息和接入承載信肩、ο
6.根據(jù)權利要求4所述的方法，其特征在于，當所述訂購的DCD頻道的標識與所述FDT 中的傳輸對象標識TOI對應的DCD頻道標識不匹配時，返回執(zhí)行接收組播式Flute會話的文件發(fā)送表FDT這一步驟。
7.根據(jù)權利要求4所述的方法，其特征在于，當所述新動態(tài)內(nèi)容的生成時間點不晚于當前DCD客戶端中存儲的原動態(tài)內(nèi)容生成時間戳時，返回執(zhí)行接收組播式Flute會話的文件發(fā)送表FDT這一步驟。
8.根據(jù)權利要求4所述的方法，其特征在于，所述修正的DCD動態(tài)內(nèi)容接收超時時長為上述執(zhí)行過程中，最后接收到的DCD動態(tài)內(nèi)容的接收時間點減去第一個接收到的DCD動態(tài)內(nèi)容的接收時間點。
9.根據(jù)權利要求4所述的方法，其特征在于，獲得的下次開啟時間點為上述執(zhí)行過程中，接收到第一個DCD動態(tài)內(nèi)容的時間點加上一個發(fā)送周期，再減去兩個動態(tài)內(nèi)容接收超時時長。
10.一種動態(tài)內(nèi)容發(fā)送的處理系統(tǒng)，其特征在于，包括DCD服務端，用于對不同的DCD業(yè)務應用依據(jù)周期性發(fā)送的時間間隔進行分類，使每個 D⑶業(yè)務對應一個D⑶頻道，并將具有相同發(fā)送周期時間間隔的D⑶頻道在同一個組播式 Flute UDP會話中進行混合發(fā)送；D⑶客戶端，用于接收D⑶服務端進行混合發(fā)送的D⑶頻道及相關信息，并在每個發(fā)送周期的靜態(tài)連續(xù)時段，關閉相應的Flute UDP接收端口。
全文摘要
本發(fā)明公開了一種動態(tài)內(nèi)容發(fā)送的處理方法及系統(tǒng)，基于周期性動態(tài)內(nèi)容發(fā)送的特征，通過將具有同樣動態(tài)內(nèi)容發(fā)送周期需求的DCD頻道動態(tài)內(nèi)容在同一個UDP端口(或同一個Flute會話)上混合發(fā)送，實現(xiàn)了一個組播式Flute會話UDP端口上的DCD頻道復用；同時，實現(xiàn)了DCD客戶端基于周期時間的合理UDP端口接收進程的啟動和釋放。并且使DCD客戶端只有在DCD服務端側有組播式動態(tài)內(nèi)容發(fā)送時才需啟動UDP端口接收進程并進行偵聽，在其余時間則關閉UDP端口接收進程，能夠降低對底層組播承載資源和上層的Socket資源浪費，減少系統(tǒng)的功耗，以及增加系統(tǒng)對動態(tài)內(nèi)容發(fā)送的利用率。
文檔編號H04L29/06GK102546196SQ20101060608
公開日2012年7月4日 申請日期2010年12月24日 優(yōu)先權日2010年12月24日
發(fā)明者莫建林 申請人:聯(lián)芯科技有限公司