通信接收器的制造方法
【專利說明】通信接收器
【背景技術(shù)】
[0001] 本發(fā)明涉及多媒體媒體內(nèi)容分發(fā)領域。
[0002] 對于多媒體內(nèi)容分發(fā)，3GPP TS 26. 247規(guī)定，可以使用HTTP動態(tài)自適應流媒體 (DASH)的媒體展示描述（MPD)，其早前作為3GPP TS 26. 234包交換流媒體（PSS)業(yè)務的一 部分出現(xiàn)。
[0003] 為了通過互聯(lián)網(wǎng)分發(fā)文件，還可以使用單向傳輸文件分發(fā)（FLUTE)【RFC 3926】。 FLUTE是一種用于通過互聯(lián)網(wǎng)進行單向文件分發(fā)的協(xié)議。該規(guī)范建構(gòu)在異步分層編碼 (ALC)【RFC 3450】之上，ALC是設計用于大規(guī)模可擴展的多播分發(fā)的基本協(xié)議。
[0004] 對于服務具有相同媒體內(nèi)容的大型集合，可以利用多媒體廣播多播業(yè)務（MBMS)。 MBMS下載分發(fā)方法旨在通過MBMS將任意數(shù)目的對象分發(fā)給眾多接收器。3GPP TS 26. 346 的MBMS中定義了兩種分發(fā)方法，即下載和流媒體。
[0005] 當通過MBMS承載分發(fā)媒體內(nèi)容時，MBMS下載分發(fā)方法使用FLUTE協(xié)議【RFC 3926】。
[0006] 3GPP TS 26. 247中定義的DASH規(guī)定了使流媒體業(yè)務從標準HTTP服務器分發(fā)給 DASH客戶端的格式和方法。它涉及通過媒體呈現(xiàn)描述（MPD)來描述媒體分片和輔助元數(shù)據(jù) (均被HTTP-URL引用）。
[0007] 下載分發(fā)方法，即MBMS，允許3GPP TS 26. 247中定義的DASH分片和媒體呈現(xiàn)描述 的分發(fā)。分片URI使用FLUTE進行描述。
[0008] 網(wǎng)絡可通過MBMS用戶業(yè)務描述通告用于為DASH提供媒體分片的MBMS下載分發(fā) 方法的使用。在此事件中，MBMS用戶業(yè)務描述分段應包括媒體呈現(xiàn)描述元素。該元素包含 對3GPP TS 26.247中定義的媒體呈現(xiàn)描述元數(shù)據(jù)分段的引用。因此，用戶設備（UE)可以 預期根據(jù)3GPP TS 26. 244中規(guī)定的HTTP動態(tài)自適應流媒體的3GP文件格式對MBMS下載 分發(fā)方法提供的文件進行格式化。此外，媒體呈現(xiàn)描述分段可包含對3GPP TS 26. 247中定 義的初始化分片描述片段的引用。
[0009] 為了開始使用通過MBMS分發(fā)的DASH業(yè)務，MBMS客戶端必須執(zhí)行以下步驟：
[0010] 1.接收用戶業(yè)務包描述。
[0011] 2.將媒體呈現(xiàn)描述映射到對應的分發(fā)方法。
[0012] 3.建立MBMS用戶業(yè)務數(shù)據(jù)的接收。
[0013] 4.接收來自ALC/LCT會話的FDT實例。
[0014] 5.使用接收到的FDT實例將所選顯現(xiàn)的URL映射到傳輸對象標識符（TOI)。
[0015] 6.將接收到的對象存儲在UE緩存中，該對象可以由DASH客戶端使用GET請求進 行獲取。
[0016] 在初始化通過MBMS發(fā)送的DASH媒體內(nèi)容接收過程中，F(xiàn)DT實例的接收引入了延 遲，這對體驗質(zhì)量造成負面影響。在從MBMS會話接收所選顯現(xiàn)的任意分片（'對象'）之 前，必須首先接收FDT實例。通過ALC/LCT會話定期發(fā)送FDT實例。引入的延遲取決于發(fā) 送FDT實例的時間間隔。
[0017] 通過以所支持的一種機制運行FLUTE客戶端可為支持MBMS接收的設備通過MBMS 分發(fā)DASH媒體內(nèi)容。FLUTE客戶端支持兩種運行機制：
[0018] 1.全部下載機制：在該機制下，指示FLUTE客戶端下載會話中的所有文件（傳輸 對象），或者
[0019] 2.基于請求的機制：在該機制下，指示FLUTE客戶端應當下載哪些文件。
[0020] 然而，在DASH客戶端發(fā)送對媒體分片的請求時，該請求可能已經(jīng)通過FLUTE會話 (ALC/LCT會話）進行發(fā)送或者傳輸可能已經(jīng)結(jié)束。這樣會引起額外的延遲以使FLUTE客戶 端恢復文件。
[0021] 另一方面，全部下載機制可能并非適用于所有場景，因為FLUTE客戶端將下載所 有通過會話發(fā)送的文件，而這將導致過度的存儲使用，尤其當通過同一 MBMS會話同時發(fā)送 多個顯現(xiàn)時。

【發(fā)明內(nèi)容】

[0022] 本發(fā)明的目的在于提供用于多媒體媒體內(nèi)容分發(fā)的有效概念。
[0023] 此目的可以通過獨立權(quán)利要求的特征來實現(xiàn)。進一步的實施形式在從屬權(quán)利要 求、具體說明和附圖中顯而易見。
[0024] 根據(jù)第一方面，本發(fā)明涉及一種通信接收器，包括第一客戶端，用于根據(jù)HTTP動 態(tài)自適應流媒體協(xié)議進行接收，以及第二客戶端，用于根據(jù)單向傳輸文件分發(fā)協(xié)議進行接 收，其中所述第一客戶端用于向所述第二客戶端提供獲取模式，以及所述第二客戶端用于 根據(jù)所述獲取模式獲取，例如接收或下載或提取媒體內(nèi)容。
[0025] 在所述第一方面的第一實施形式中，所述第一客戶端用于通過控制信道將所述獲 取模式提供給所述第二客戶端205。
[0026] 在如上所述的第一方面或所述第一方面的第一實施形式的第二實施形式中，所述 第二客戶端用于根據(jù)所述獲取模式通過FLUTE會話從遠程發(fā)射器下載所述媒體內(nèi)容以接 收所述媒體內(nèi)容。
[0027] 在如上所述的第一方面或所述第一方面的前述實施形式之一的第三實施形式中， 所述第一客戶端用于從遠程發(fā)射器接收包含所述獲取模式的媒體呈現(xiàn)描述（MPD)，以及從 所述接收到的媒體呈現(xiàn)描述（MPD)中獲取所述獲取模式。
[0028] 在如上所述的第一方面的或所述第一方面的前述實施形式之一的第四實施形式 中，所述媒體內(nèi)容是根據(jù)所述單向傳輸文件分發(fā)（FLUTE)協(xié)議的傳輸對象，所述傳輸對象 由傳輸對象標識符（TOI)值標識。所述傳輸對象可以是HTTP動態(tài)自適應流媒體媒體內(nèi)容 的一個顯現(xiàn)或子顯現(xiàn)的分片。
[0029] 在如上所述的第一方面或所述第一方面的前述實施形式之一的第五實施形式中， 所述獲取模式包括所述媒體內(nèi)容的傳輸對象URL，尤其是傳輸對象集的URL的前綴。所述獲 取模式可以基于所述傳輸對象URL的前綴，例如為所述URL的路徑。
[0030] 在如上所述的第一方面或所述第一方面的前述實施形式之一的第六實施形式中， 所述獲取模式包括傳輸對象標識符值的傳輸對象標識符范圍或傳輸對象標識符值的前綴。
[0031] 在如上所述的第一方面或第一方面的前述實施形式之一的第七實施形式中，所述 獲取模式包括所述媒體內(nèi)容的URL。
[0032] 在所述第一方面的第六或第七實施形式的第八實施形式中，傳輸對象標識符值的 所述傳輸對象標識符（TOI)范圍或所述前綴，或傳輸對象URL的所述前綴表示媒體呈現(xiàn)描 述（MPD)的顯現(xiàn)的分片。所述TOI范圍可以從所述擴展的MPD中提取。
[0033] 在所述第一方面的第八實施形式的第九實施形式中，所述第二客戶端用于下載落 入所述傳輸對象標識符范圍的傳輸對象標識符（TOI)值所描述的分片集。
[0034] 在如上所述的第一方面或所述第一方面的前述實施形式之一的第十實施形式中， 所述第二客戶端用于接收DASH流媒體內(nèi)容。
[0035] 在如上所述的第一方面或所述第一方面的前述實施形式之一的第十一實施形式 中，所述第二客戶端用于下載匹配傳輸對象標識符值的所述前綴或者匹配所述第一客戶端 指示的傳輸對象URL的所述前綴的分片集。
[0036] 根據(jù)第二方面，本發(fā)明涉及一種通信發(fā)射器，包括用于根據(jù)HTTP動態(tài)自適應流 媒體協(xié)議（DASH)進行傳輸?shù)牡谝话l(fā)射器，以及用于根據(jù)單向傳輸文件分發(fā)協(xié)議（FLUTE) 進行傳輸?shù)牡诙l(fā)射器，其中所述第一發(fā)射器用于向所述第二發(fā)射器提供媒體呈現(xiàn)描述 (MPD)的分片用于傳輸，所述第二發(fā)射器用于將獲取模式分配給所述分片，以及所述發(fā)射器 用于將增強型媒體呈現(xiàn)描述（MPD) (101)發(fā)送給通信網(wǎng)絡，所述增強型媒體呈現(xiàn)描述（MPD) (101)包括所述獲取模式。
[0037] 在所述第二方面的第一實施形式中，所述第一發(fā)射器和所述第二發(fā)射器用于通過 控制信道進行通信。
[0038] 根據(jù)第三方面，本發(fā)明涉及一種用于通信發(fā)射器進行傳輸?shù)膫鬏敺椒?，所述通?發(fā)射器包括根據(jù)HTTP動態(tài)自適應流媒體（DASH)協(xié)議進行傳輸?shù)牡谝话l(fā)射器，以及用于根 據(jù)單向傳輸文件分發(fā)（FLUTE)協(xié)議進行傳輸?shù)牡诙l(fā)射器，所述方法包括所述第一發(fā)射器 向所述第二發(fā)射器提供媒體呈現(xiàn)描述（MPD)的分片，所述第二發(fā)射器將獲取模式分配給所 述分片，以及將增強型媒體呈現(xiàn)描述發(fā)送給通信網(wǎng)絡，所述增強型媒體呈現(xiàn)描述包括所述 獲取模式。
[0039] 根據(jù)第四方面，本發(fā)明涉及一種用于通信接收器進行媒體內(nèi)容接收的接收方法， 所述通信接收器包括第一客戶端，用于根據(jù)HTTP動態(tài)自適應流媒體（DASH)協(xié)議進行接收， 以及第二客戶端，用于根據(jù)單向傳輸文件分發(fā)（FLUTE)協(xié)議接收媒體內(nèi)容，其中所述方法 包括所述第一客戶端向所述第二客戶端提供獲取模式，以及所述第二客戶端根據(jù)所述獲取 模式接收媒體內(nèi)容。
[0040] 根據(jù)第五方面，本發(fā)明涉及一種用于當在計算機上執(zhí)行時執(zhí)行所述傳輸方法或所 述接收方法的程序。
[0041] 本發(fā)明可以在硬件和/或軟件中實施。
【附圖說明】
[0042] 圖1所示為DASH數(shù)據(jù)模型；
[0043] 圖2所示為接收器架構(gòu)；
[0044] 圖3所示為發(fā)射器架構(gòu)。
【具體實施方式】
[0045] 圖1所示為媒體呈現(xiàn)描述101，其基于實施規(guī)范3GPP TS 26. 247的DASH數(shù)據(jù)模 型。
[0046] 媒體呈現(xiàn)描述101包括一系列基于時間的周期103、119,這些周期構(gòu)成了媒體呈 現(xiàn)描述。周期1〇3、119通常表示媒體內(nèi)容周期，在這個周期內(nèi)存在一組一致性的媒體內(nèi)容 編碼版本，即一組可用比特率、語言、標題、字幕等在這個周期內(nèi)不會改變。
[0047] 在周期103、119內(nèi)，材料被編排為適配組104、111。適配組104、111表示一組一個 或多個媒體內(nèi)容成分的可互換編碼版本。例如，主視頻成分可能有一個適配組104、111，同 時主音頻成分也有一個單獨的適配組。如果存在其它材料，例如標題或音頻描述，那么這些 材料可能每個都有一個單獨的適配組104、111。材料還可能以復用的形式來提供，在這種情 況下，復用的可互用版本可以描述為單一的適配組，例如一個同時包含某個周期的主音頻 和主視頻的適配組。每個被復用的成分可能通過一個媒體內(nèi)容成分描述來單獨描述。
[0048] 適配組104、111包括一組顯現(xiàn)105、109。一個顯現(xiàn)105、109描述一個可交付的一 個或多個媒體內(nèi)容成分的編碼版本。一個顯現(xiàn)105、109包含一個或多個媒體流，例如在復 用中，每個媒體流對應一個媒體內(nèi)容成分。適配組中任何一個顯現(xiàn)105、109足以顯示所包 含的媒體內(nèi)容成分。通常來說，為了適應網(wǎng)絡條件或其它因素，客戶端可在一個周期內(nèi)從一 個顯現(xiàn)切換到另一個顯現(xiàn)。客戶端也可以忽略那些不合適的或者那些依賴于其所不支持的 編解碼或顯示技術(shù)的顯現(xiàn)。
[0049] 在顯現(xiàn)105、109內(nèi)，媒體