涉及到一個或多個用戶裝置的內(nèi)容流播的設備和方法
【技術領域】
[0001] 本發(fā)明設及該樣的設備和方法，其設及例如在使用自適應HTTP流播技術時到一 個或多個用戶裝置的內(nèi)容流播。
【背景技術】
[0002] 自適應HTTP流播(AHS)技術正變得越來越普遍用于提供視頻服務。自適應HTTP 流播技術既支持視頻點播也支持視頻直播。單播傳送典型地默認用作傳輸承載。然而，媒 體段也可W廣播到小區(qū)中的多個接收器，例如使用長期演進（LTE)標準中的廣播機制。圖 1示出典型網(wǎng)絡，其中來自web服務器13的內(nèi)容或媒體被流播到多個用戶設備裝置11。內(nèi) 容在無線電網(wǎng)絡控制器17的控制下經(jīng)由與用戶設備裝置11關聯(lián)的小區(qū)10流播。web服務 器13典型地經(jīng)由電信網(wǎng)絡的一個或多個節(jié)點（例如網(wǎng)關GPRS支持節(jié)點（GGSN) 15)將內(nèi)容 流播到無線電網(wǎng)絡控制器。
[0003] 自適應HTTP流播是使用現(xiàn)有文件格式的傳輸技術，例如國際組織標準化基媒體 文件格式（ISOBMFF)或活動圖像專家組MPEG2-TS標準。支持不同的音頻和視頻編解碼器， 例如H. 264、MPEG4、高級音頻編碼（AAC)、mp3編解碼器。
[0004] 存在許多不同的自適應HTTP流播技術方案，例如Apple?的HTTP實時流播（化S)、 來自Microsoft?的平滑流播（ISM)、通過HTTP的3GP動態(tài)自適應流播（3GP-DA甜)、通 過HTTP的MPEG動態(tài)自適應流播（MPEG-DA甜)、開放IPTV論壇的0ITVHTTP自適應流播 (0ITV-HAS)、Adobe?的動態(tài)流播和更多。存在MPEGDA甜技術方案將變成自適應HTTP流播 的主要標準該一可能性。
[0005] 自適應HTTP流播技術依靠客戶端來選擇媒體質(zhì)量。服務器或內(nèi)容提供商使用"清 單文件"來描述可用于流播特定內(nèi)容或媒體的不同質(zhì)量表示(媒體比特率）中的全部，W及 如何可W從服務器訪問該些不同質(zhì)量表示。清單文件在流播會話開始時至少被提取一次并 且可更新。在Apple?的化S技術的情況下，清單格式化為采用m3u8格式的播放列表文件。 在3GP/MPEGDA甜的情況下，清單是叫作媒體呈現(xiàn)描述（MPD)的XML結(jié)構(gòu)。
[0006] 自適應HTTP流播技術中的大部分需要客戶端連續(xù)從服務器提取媒體段。在典型 的媒體段中包含一定量的媒體時間(例如媒體數(shù)據(jù)的lOsec)。用于下載不同質(zhì)量表示的段 的地址或U化的創(chuàng)建在清單文件中描述。
[0007] 圖2描繪用戶設備裝置11可如何使用自適應HTTP流播技術從服務器節(jié)點13提 取段的基本原理。在步驟201和203中，用戶設備裝置11從服務器節(jié)點13提取清單文件。 用戶設備裝置11處理清單文件，并且在步驟205中W特定質(zhì)量水平(例如，W最低質(zhì)量水平 開始)提取第一段。使用HTTPGET(獲取)消息來提取段。用戶設備11在接收媒體段時(例 如在步驟207中下載第一段時)連續(xù)測量鏈路位速率。使用關于鏈路位速率的該信息，用戶 設備11能夠選擇不同的表示或質(zhì)量水平，并且將"來自中等質(zhì)量的HTTPGET段#2"消息發(fā) 送到服務器節(jié)點13 (在步驟209中示出）。在接收請求時，服務器節(jié)點13W中間質(zhì)量水平 流播段(步驟211)。用戶設備11可在任何時間變成另一個質(zhì)量表示。例如，MPEG-DA甜定 義新的索引框，其允許用戶設備裝置甚至在段下載的中途也高效切換質(zhì)量。
[0008] 從上文可W看到在自適應HTTP流播中，視頻用多個離散比特率編碼并且每個比 特率流分解成多個段或"塊"（例如1-10秒的段)。來自一個比特率流的第i個塊在視頻時 間線中與來自另一個比特率流的第i個塊對齊使得例如視頻播放器等用戶設備裝置(或客 戶端裝置）可W在每個塊邊界處平滑切換到不同的比特率。
[0009] 由例如NetFlix?等應用推動且使用的DA甜"按需"簡檔遵循不同的方案。按需簡 檔與HTTP漸進流播非常接近，所不同的是客戶端在回放期間改變質(zhì)量。
[0010] 在DA甜"按需"簡檔的情況下，客戶端使用HTTP的開放范圍字節(jié)范圍請求來請求 視頻內(nèi)容。客戶端保持接收在相同HTTP管道上的視頻內(nèi)容。僅在質(zhì)量切換的情況下，客戶 端終止TCP連接并且為下一個范圍請求打開新的TCP連接。
[0011] MPEG2-TS或ISOBMFF可用作媒體段的文件格式。MPEG2-TS通常從TV廣播環(huán)境獲 悉。例如化S等其他技術使用MPEG2-TS。Microsoft的平滑流播技術使用分段MP4文件， 其定義為ISOBMFF的部分。MPEG-DA甜允許ISOBMFF和MPEG2-TS兩者都作為媒體段。定 義另外的ISOBMFF結(jié)構(gòu)來增加DA甜的魯椿性和特征豐富性。3GP-DA甜是MPEG-DA甜的簡 檔。主要差異是僅允許ISOBMFF。0IPFHAS(HTTP自適應流播）也是MPEG-DA甜的簡檔， 其對媒體段既支持ISOBMFF也支持MPEG2-TS文件格式。
[001引如上文提到的，例如DA甜或化S等自適應HTTP流播基于由用戶設備裝置做出的 比特率決定。用戶設備裝置測量它自己的鏈路比特率并且就它對于下載內(nèi)容將優(yōu)選的比特 率做出決定，典型地選擇它預測可用帶寬可W迎合的最高可用內(nèi)容比特率。
[0013] 當多個用戶設備裝置在相同網(wǎng)絡上使用自適應HTTP流播服務時，帶寬通常在用 戶設備裝置之間不公正分配，該可W導致不公正。
[0014] 例如，當多個用戶設備裝置在相同網(wǎng)絡上使用自適應HTTP流播服務時，它們?nèi)?在可用帶寬(鏈路吞吐量）上完成。如果用戶設備裝置足夠有幸獲得大份額的鏈路帶寬，該 用戶設備裝置將繼續(xù)經(jīng)歷快速段下載并且因此繼續(xù)請求具有較大段的較高簡檔。然而，僅 管理來獲得較小比例的鏈路吞吐量的用戶設備裝置經(jīng)歷較慢段下載并且然后被迫請求具 有較小段的較低速率簡檔。
[0015] 該樣的后果是自適應HTP流播技術本質(zhì)上不公正。已經(jīng)足夠有幸得到大塊鏈路吞 吐量的客戶端或用戶設備裝置未對其放手，從而不幸的用戶設備裝置趨于對整個服務會話 都保持不幸。該問題在移動/無線電網(wǎng)絡(例如在圖1中示出的）中特別真實，其中一個或 多個小區(qū)可能變擁擠。對于服務提供商，該是棘手的場景，因為在整個會話期間使最終用戶 中的一些接收差質(zhì)量下載導致該樣的最終用戶可停止使用該服務器提供商的高風險。如果 所有最終用戶接收相同質(zhì)量，情況將好得多，即使該質(zhì)量對于最終用戶中的一些將處于比 正常略微低些的質(zhì)量也如此。
[0016] 存在用于解決自適應HTTP流播中的不公正問題的許多機制，例如采用各種網(wǎng)絡 技術方案的形式，其中在網(wǎng)絡中引入網(wǎng)絡列隊調(diào)度器或其他控制節(jié)點。該樣的機制使用列 隊機制并且調(diào)度可用帶寬如何在最終用戶之間共享來解決問題。然而，該樣的系統(tǒng)具有需 要修改網(wǎng)絡該一劣勢，其對于不在網(wǎng)絡控制中的服務提供商可能是個障礙。
【發(fā)明內(nèi)容】
[0017] 本發(fā)明的目的是提供用于消除或減少上文提到的劣勢中的一個或多個的方法和 設備。
[0018] 根據(jù)本發(fā)明的第一方面，提供有用于在電信網(wǎng)絡中將內(nèi)容流播到一個或多個用戶 設備裝置的方法，其中內(nèi)容可用于W多個不同質(zhì)量表示中的一個流播。方法包括從用戶設 備裝置接收請求的步驟，其中該請求是W第一質(zhì)量表示交付內(nèi)容段。確定用戶設備裝置是 否連接到電信網(wǎng)絡中的小區(qū)，在該電信網(wǎng)絡中小區(qū)的擁擠水平在闊值水平之上。如果是該 樣的話，執(zhí)行公正函數(shù)來確定內(nèi)容段是應W請求的第一質(zhì)量表示還是W第二質(zhì)量表示流播 到用戶設備裝置。內(nèi)容段基于執(zhí)行公正函數(shù)的結(jié)果W第一質(zhì)量表示或第二質(zhì)量表示流播到 用戶設備裝置。
[0019] 通過確定請求是否來自定位在擁擠小區(qū)中的用戶設備裝置，方法能夠在將內(nèi)容流 播到用戶設備裝置之前執(zhí)行另外的檢查，該另外檢查是公正函數(shù)。該具有更公正地將內(nèi)容 流播到擁擠小區(qū)內(nèi)的用戶設備裝置的優(yōu)勢。
[0020] 根據(jù)本發(fā)明的另一個方面，提供有用于在電信網(wǎng)絡中將內(nèi)容流播到一個或多個用 戶設備裝置的設備，其中該內(nèi)容可用于W多個不同質(zhì)量表示中的一個流播。設備包括接收 單元，其配置成從用戶設備裝置接收請求，其中該請求是W第一質(zhì)量表示交付內(nèi)容段。