TWI559754B - 帶寬控制方法及其裝置 - Google Patents

Description

帶寬控制方法及其裝置

本發明係一般關於視訊流送內容分配，尤指控制視訊流送內容所用之帶寬。

本節旨在對讀者介紹諸技藝面向，與本發明諸要旨有關，說明和/或請求如下。此項討論相信有助於向讀者提供背景資訊，以便更加明瞭本發明諸要旨。因此，須知此等陳述要以此觀點來閱讀，而非引進先前技術。

媒體傳遞流送解決方案主要基於協定，諸如IETF RFC 2326所界定即時流送協定(RTSP)、微軟公司的微軟媒體伺服器(MMS)專屬協定，或Adobe系統公司的即時傳訊協定(RTMP)專屬協定。

根據HTTP協定的流送技術已脫穎而出，得以跨越網際網路傳遞內容。此等技術使委託機裝置得以接收視訊，呈「小連小節」(small successive small segments)的形式，稱為語塊，為數秒長。各節係透過HTTP協定要求，可以不同的變體存在，容許委託機裝置隨時選擇匹配網路之適當位元率，及其本身侷限物。不同位元率相當於所傳遞內容之不同品質水準。一旦委託機裝置測量之網路帶寬減少，即要求語塊對網路帶寬要件較少限制性。當委託機裝置測量之網路帶寬增加，會要求語塊對網路帶寬要件更具限制性。

可用語塊一般是列在流送伺服器所產生和提供之節目表。節目表可指向其他節目表，諸如每種格式有一節目表。節目表記載語塊內容，諸如寫解碼器或所需帶寬，加以下載，以及要求之方式。節目表格式可為文件〈HTTP活流送草案，pantos,http活流送，06〉所載，以寫解碼器資訊延伸，說明各種SVC層。

有各種HTTP流送可用。蘋果HTTP活流送(HLS)做為草案RFC公告，主要用在蘋果裝置。微軟平滑流送是微軟 銀光平台之一部份，其說明書可公開取得。阿鐸比(Adobe)開放源媒體架構(OSMF)接近微軟解決方案。3GPP發表封包交換流送(PSS)系統用之規格；有一MPEG工作小組也跨越HTTP創作近似動作適應性流送(DASH)之定義。在此等解決方案中使用HTTP協定之益處是，有能力無縫跨過NAT和防火牆。此等HTTP流送科技提供一種方式，藉連續且完美升等或降等視訊品質，補正有關可用帶寬之錯誤網路行為，以匹配帶寬侷限物。

一般而言，HTTP流送技術是根據同樣概念。在節目表檔案格式，提供說明內容選項(位元率、形像維度、幅率…)之元資料，內容在節段內可用表示法之組織，所支援寫解碼器，以及內容保護科技等方面有所變化。

當委託機裝置想播放一些視聽內容時，首先必須得到說明如何可得此特別內容之檔案。

此係透過HTTP藉從URL取得某些「檔案」為之。此檔案基本上表列內容之可用表示法(就位元率和其他性質而言)，而且對每一項，URL致能於對各時片(time slice)加載內容節段。例如對應需視訊內容，提供電影的完整說明，而對現場傳播內容，描述只涵蓋短期間，時間過去時，需要定期再加載，才能找到新項目。

委託機裝置視其從網路環境具有的資格和智識，選用某表示法(典型上基於其位元率)，而加載內容之第一節段。緩衝少數節段，得以對抗網路阻礙。然後，逐一從各接收節段播放內容。同時，委託機裝置測量接收率，可決定往較高或較低位元率。在如此情況時，只從另一表示法要求次一節段。每一HTTP流送系統是可讓委託機保持連續播放，同時從某位元率之節段前往另一位元率之「次一」節段。

此方式在網路上的通訊量以接收內容之位元率引進變異時，委託機可藉選用其位元率得以維持委託機緩衝器充填至安全位準之節段加以反應。誠然，委託機常試圖到達最高可 能之位元率，以提供更佳觀視品質，並停留在此一水準，不會因遲接收資料妨礙描繪，造成巨塊或圖像凍結。

在住家網路，有複數委託機裝置可能同時進行HTTP流送。若局部網路或在寬帶網路上可用之帶寬，不足以支援全部通訊量時，委託機裝置即競相獲取共享可用帶寬。HTTP流送演算法在各裝置內單獨運轉，無法提供最適共享帶寬。可能發生以下情形。帶寬共享不公平，一視訊串流使用一定不變的高位元率，另一停留在低位元率。或是發生振盪，各裝置交替使用高、低位元率。有時裝置會同時對網路狀況過度反應，判決不友好，造成對各裝置選用很低位元率，而大為浪費帶寬。甚至發生有足夠帶寬可用時，以HTTP協定為基礎之TCP機制，對各串流會遭遇封包接收之內蘊競爭，如此會產生不是穩定不公平情況，便是永久振盪的同樣結果。此種行為會直接衝擊到末端使用者的體驗品質，因為所顯示的視訊品質連結到所用位元率。

本發明嘗試先前技術中涉及適應流送不穩定之至少某些問題，提供控制各適應流送內容所用帶寬。

本發明係關於一種裝置，包括第一界面，對第一網路，包括適應流送伺服器；第二界面，對第二網路，包括至少一適應流送委託機裝置；串流識別器，以檢測至少一適應流送委託機裝置所要求之至少一流送內容，此至少一流送內容係有一種以上之資料率；帶寬管理器，可從一種以上之資料率選用一種資料率；排程器，在第二界面把至少一流送內容，以一種資料率，即超出該所選用資料率但低於該流送內容可用之任何較高資料率，傳輸到至少一委託機裝置。

按照具體例，第一界面有最大帶寬接收，並選用資料率，使至少一流送內容所需帶寬，低於最大帶寬接收。

按照具體例，帶寬管理器適於優先傳輸至少一流送內容，到至少一委託機裝置。

按照具體例，裝置係住家閘口。

本發明另一目的為在一種裝置內進行之一種方法，此裝置包括第一界面，對第一網路，包括適應流送伺服器；第二界面，對第二網路，包括至少一適應流送委託機裝置。此方法包括步驟為，檢測至少一適應流送委託機裝置所要求之至少一流送內容，此至少一流送內容係有一種以上之資料率；從一種以上資料率選用一種資料率；在第二界面把至少一流送內容，以一種資料率，即超出該所選用資料率但低於該流送內容可用之任何較高資料率，傳輸到至少一委託機裝置。

本發明另一目的為電腦程式製品，包括電腦程式碼指令，當程式在電腦上執行時，可以執行本發明方法步驟。「電腦程式製品」意指電腦程式支援，不但由含有程式的儲存空間，諸如電腦記憶器，而且有訊號，諸如電氣或光學訊號，所組成。

本發明係在位於適應流送伺服器和適應流送委託機裝置間的裝置位階，進行通訊量造型。帶寬管理得以在許多可能共現服務和各服務所感受QoE之間有最佳權衡。本發明通訊量造型的效果，有益於各HTTP適應流送委託機之行為。此舉會抑制或限制若干串流間之競爭。若無通訊量造型，帶寬份量是由TCP協定性質，以及委託機演算法如何對其「測量」之帶寬反應，來決定；實務上，如此會導致不穩定和/或不公平情況。有了通訊量造型，各串流限制在其可能之變異範圍內。若串流可進到高位元率，例如是因為另一串流暫時在低通訊量，則由於高位元率所請求節段費多時才到，會遭遇到進來的帶寬下降。然後為了補正，適應委託機將不得不進到很低位元率補正。故位元率會有大幅度變異，以致體驗品質劣。把所感受帶寬限制到接近平均目標之數值，委託機就永遠不會跑太高，會在目標數值附近更加穩定。

本發明亦可以控制之比例分配帶寬，例如使用不同位元率之不同視訊格式，不需由閘口提供之中央仲裁，委託機可 傾向以相似位元率分享帶寬。

通訊量之分類包含視聽串流和其他種資料流動間之優先法則。如此得以例如保護OTT視訊觀賞，不受資料檔案下載的干擾。

家庭閘口是進行帶寬管理的好地方，因為有能力獲得網路和裝置拘限物之適當知識，而且可看到全部通訊量，因此，應能識別屬於AV服務之串流，並採取行動。

範圍與所揭示具體例相稱之某些要旨，規範如下。須知此等要旨之呈現，純為提供讀者簡單摘述本發明可採取之某些形式，而此等要旨無意限制本發明範圍。誠然，本發明可涵蓋以下未規定之各種要旨。

茲參見附圖所示非限制性具體例說明，即可更為明瞭本發明。

在第1圖中展示方塊純為功能性實體，不一定相當於實際分開之實體。即可以硬體或軟體形式開發，或以一個或數個積體電路實施。

須知本發明附圖和說明經簡化，以示相關元件，供更清楚明瞭本發明，而為扼要起見，省略典型數位多媒體內容輸送方法和系統所見之許多其他元件。然而，因為此等元件為技術上所公知，該元件在此即不予詳論。本文所揭示係針對技術專家已公知之所有此類變化和修飾。

第1圖展示系統具體例。包括二委託機裝置4,5，以及透過網際網路2連接之流送伺服器3。委託機裝置位於經閘口1連接至網際網路之局部網路6內。局部網路最好是住家網路。應委託機要求，伺服器使用HTTP協定，越過TCP/IP連接，流送語塊至委託機。

第2圖表示委託機裝置4具體例。委託機裝置(以下亦稱適應流送委託機裝置)，包括對局部網路6之第一界面44。委託機包括通訊模組43，後者包括協定堆疊，與伺服器 3通訊。具體而言，通訊模組包括技術上公知之TCP/IP堆疊。當然，可有任何其他型式之網路和/或通訊模組，致使委託機能與伺服器通訊。包括適應流送模組45。是HTTP流送委託機從伺服器接收HTTP流送內容。以更佳匹配網路局限物及其本身局限物之位元率，連續選擇語塊。

委託機包括放影機46，適於解碼和描繪內容。委託機也包括處理器41，以執行委託機內儲存之應用和程式。包括緩衝器42，諸如記憶器，以緩衝從伺服器接收之語塊，然後傳輸至放影機46。具體而言，記憶器係無常性記憶器。當然，委託機包括非無常性記憶器(圖上未示)，以儲存在委託機上運轉之應用和程式。委託機裝置可為可攜式媒體裝置或膝上型。

另外，委託機裝置不包括放影機，而包括連接至放影機之界面。則委託機裝置為視訊解碼器，諸如機上盒。

第3圖展示閘口具體例。係數位式訂戶線閘口，透過DSL科技提供網際網路寬帶存取住家網路。當然，閘口可為任何型寬帶閘口，諸如纜線、纖維或無線。包括LAN界面14、寬帶界面13，和通訊模組17，後者包括協定堆疊，透過界面通訊。通訊模組包括網際網路協定堆疊，稱為IP堆疊。

閘口包括第一記憶器16.1和第二記憶器16.2。第一記憶器16.1適於儲存摘自節目表檔案之資訊。第二記憶器16.2適於緩衝收發於界面之封包。

閘口亦包括通訊量造型模組19，其內包括帶寬管理器11、串流識別器模組15、排程器12和分類器18，詳後。

閘口包括內部滙流排10，連接諸模組。亦包括處理機構、路引和橋接機構(圖上未示)，以及技術專家公知進行類型住家閘口功能之所有機構。

第4圖進一步展示閘口。串流識別器模組15適於分析在閘口接收之串流。每次委託機裝置發生服務請求，即識別此項請求，藉截取從伺服器送回委託機之節目表以收集服務資 訊。截取並分析注定給各局部裝置之節目表檔案。分析節目表檔案，允許摘取資訊，諸如伺服器公告，並與節段URL關聯之位元率。為截取節目表，串流識別器明白可用之流送技術，以及關聯之協定。對於各協定，知道傳送節目表的封包型式。具體而言，明白蘋果HTTP活流送、微軟平滑流送，以及阿鐸比開放源媒體架構技術。當然，可構成明白其他流送技術。

串流識別器亦識別何時不再在閘口接收串流。例如，當一段時期不接到串流時，串流識別器即認為審理完成，並取消對委託機裝置之分佈。

串流識別器15所得資訊，傳輸至帶寬管理器11。

帶寬管理器決定服務是否允許，並給服務分配目標位元率，同時改變可能業已運轉中的其他服務之目標。帶寬管理器構成知道帶寬界面上可用之最大帶寬值。基於此值，帶寬管理器即決定在串流當中的帶寬分佈。構成第二記憶器，故對所檢測之各串流，在第二記憶器內產生特殊佇列(queue)，對各佇列設定目標傳輸位元率。易言之，節目表為各串流提供HTTP流送可用之位元率。由寬帶管理器決定各串流精確之目標位元率。決定各串流之目標位元率後，帶寬管理器構成排程器12。

排程器12適於管理封包在局部網路之傳輸。易言之，各串流指定一獨立佇列，確實分配一準確帶寬。封包發送不比此目標位元率快。同時，帶寬獲得「保證」；只要佇列有封包發送，且未達目標位元率，封包在其他通訊量上佔有優先權。

帶寬管理器關於在流送審理當中帶寬分配之決定，視許多參數，以及使用者或服務提供者偏好而定。如此導致帶寬管理器強制之仲裁計劃集合(例如公平分享，其中全部審理取得與其格式成比例之帶寬)，並利用內容、網路、委託機裝置等特徵饋送。帶寬管理器首先有賴http適應串流之內質彈 性，連同知道可用到可能位元率步驟之能力。

帶寬分佈進行如下。根據委託機裝置型式。例如電視機用的串流，優先序位高於可攜式媒體播放器用之串流。另外，帶寬分佈可根據委託機裝置在住家網路上之位置。位於客廳的委託機裝置可比位於臥室的委託機裝置，有更高優先權。此項分佈對固定裝置，諸如電視機、機上盒較佳。帶寬分佈亦可基於裝置類型與其在住家網路內位置之組合。另外，分佈是在裝置當中公平設定。

閘口最好包括使用者界面，致能調節串流間之優先權。 使用者界面內之條目有例如裝置型式、其位置及其優先權。

以計算帶寬分配給委託機為例，其可能演算法如下：令BW為總共可用帶寬。

對於各委託機c：

˙令份量[c]為要給予c的帶寬百分比。份量[c]係由上述管理政策，使用者優先等決定。

˙令目標[c]指希望c選擇的內容位元率。

˙目標[c]係以c的流送內容最高值啟用，再計算如下。

˙令百分比[c]指委託機使用多少帶寬的暫時計算值。

最後百分比[]表係按照下述演算法，進行計算：若SUM(目標[])>BW：

˙選擇(百分比[c]/份量[c])最大比率之委託機c，忽視已在其最低位元率之委託機。

˙目標[c]：=對c之次一較低位元率

˙百分比[c]：=目標[c]/BW

如今分配「未用的」帶寬給委託機：未用：=BW-SUM(目標[])

對於各委託機c：

˙目標[c]：=目標[c]+(未用^＊份量[c]) 故各委託機有其通訊量造型於一數值，大於想用的內容位元率。此為委託機成功保持要求所需內容位元率之狀況，因HTTP適應委託機一般不會成功使用具有帶寬之100%。

分類器18適於識別在閘口接收之串流，並路引其至第二記憶器內之適當佇列。核對為裝置之一所接收每一封包，以分類器模組識別其屬於視聽串流或某些其他通訊量之一。基於此分類，封包即置於不同佇列，供發送至LAN。各佇列內之封包，利用排程器，按照選擇之造型側描輸送。順向以符目標位元率。

一旦為各委託機選好目標位元率，閘口應用通訊量造型，所以委託機裝置感受的網路帶寬，引導其採取所需位元率。如此可防止裝置由於可能使用其相信可試圖較高位元率請求之全部帶寬，而在接收時看到速度暴衝。同時，各委託機獲保證有使用其本身帶寬份量之優先權。如此即避免看到位元率下降之委託機偷窺，並為其補正。

茲舉實施例以具體例裝置說明如何進行通訊量造型。

在第一實施例中，委託機裝置可用串流為1mbps、2mbps和3mbps。可用帶寬平均2.5mbps。閘口則選擇2mbps。然後，委託機在最多2mbps接收流送內容，不會在3mbps進行請求內容。此舉防止委託機裝置使用超過2mbps。

在第二實施例中，第一委託機裝置可用的第一串流在1mbps、2mbps和3mbps，而第二委託機裝置可用的第二串流在2mbps、3mbps和5mbps。可用帶寬為5.5mbps。優先權放在第一委託機裝置。第一委託機裝置在最多3mbps接收流送內容，而第二委託機裝置在最多2mbps接收流送內容。如此可防止第二委託機使用超過2mbps。稍後，第一委託機不再接收第一串流。由於更多帶寬可用，第二委託機裝置在最多5mbps接收流送內容。

另一實施例是，要求SD串流和HD串流時，分配到分別與其最大位元率呈比例之帶寬，例如20%給SD串流，80 %給HD串流。

佇列用的目標位元率最好置於超過串流目標位元率之一些百分比，以確保委託機穩定其所選擇串流之目標變數。

在具體例中，帶寬管理器決定在串流間之帶寬分佈，根據寬帶界面上可用之最大帶寬。另外，帶寬管理器可將寬帶界面上可用之最大帶寬，改為考慮局部網路上可用之最大帶寬。然後，根據局部網路上可用的最大帶寬值，決定串流間之帶寬分佈。若瓶頸是在局部網路，而非帶寬網路，即會發生此事。

在具體例中，通訊量造型是在閘口進行。另外，亦可在位於局部網路內之路引器進行，並連接至閘口。

說明書、申請專利範圍和附圖內揭示之參考資料，可單獨或以任何妥當之組合方式提供，其特點可視妥當情形，在硬體、軟體，或二者組合內實施。

參考資料提到之「具體例」字樣，係可在本發明至少一實施方式中包含就具體例所述特點、結構或特徵。說明書內多處出現的「在一具體例」辭句，不一定全指同一具體例，也非分開或選項具體例，必要時彼此為其他具體例所專屬。

申請專利範圍內出現的參照號碼，只供說明，而無對申請專利範圍有限制意思。

1‧‧‧閘口

2‧‧‧網際網路

3‧‧‧伺服器

4‧‧‧委託機裝置

5‧‧‧委託機裝置

6‧‧‧局部網路

10‧‧‧滙流排

11‧‧‧帶寬管理器

12‧‧‧排程器

13‧‧‧寬帶界面

14‧‧‧LAN界面

15‧‧‧串流識別器

16.1‧‧‧第一記憶器

16.2‧‧‧第二記憶器

17‧‧‧通訊模組

18‧‧‧分類器

19‧‧‧通訊量造型

41‧‧‧處理器

42‧‧‧緩衝器

43‧‧‧通訊模組

44‧‧‧第一界面

45‧‧‧適應流送模組

46‧‧‧放影機

47‧‧‧記憶器

48‧‧‧滙流排

第1圖為系統具體例之方塊圖；第2圖為委託機裝置具體例之方塊圖；第3圖為閘口裝置具體例之方塊圖；第4圖為閘口裝置具體例之另一方塊圖。

11‧‧‧帶寬管理器

12‧‧‧排程器

15‧‧‧串流識別器

18‧‧‧分類器

Claims (6)

1. 一種帶寬控制裝置，該裝置包括：第一界面，對第一網路，該第一網路包括適應流送伺服器；第二界面，對第二網路，該第二網路包括至少一適應流送委託機裝置；串流識別器，以檢測該至少一適應流送委託機裝置對該適應流送伺服器所要求之至少一流送內容，該至少一流送內容係在該適應流送伺服器有一種以上之資料率可用；帶寬管理器，可從一種以上之資料率選用一局部資料率；排程器，以超過該局部資料率的第一資料率，從該適應流送伺服器接收該至少一流送內容時，把該至少一流送內容在該第二界面，以超過該局部資料率但低於該第一資料率之第二資料率，傳輸至該至少一委託機裝置者。
2. 如申請專利範圍第1項之裝置，其中該第一界面具有最大帶寬接收，該帶寬管理器係適於選用該局部資料率，故該至少一流送內容所需帶寬，係低於該最大帶寬接收者。
3. 如申請專利範圍第1或2項任一項之裝置，其中該帶寬管理器係適於使該至少一流送內容優先傳輸至該至少一委託機裝置者。
4. 如申請專利範圍第1項之裝置，其中該裝置係住家閘口者。
5. 一種帶寬控制裝置進行之方法，該裝置包括第一界面，對第一網路，該第一網路包括適應流送伺服器；第二界面，對第二網路，該第二網路包括至少一適應流送委託機裝置；該方法包括步驟為：檢測由該至少一適應流送委託機裝置對該適應流送伺服器所請求至少一流送內容，該至少一流送內容係在該適應流送伺服器有一種以上資料率可用； 從該一種以上資料率當中選用局部資料率；以超過該局部資料率的第一資料率，從該適應流送伺服器接收該至少一流送內容時，以超過該局部資料率但低於該第一資料率之第二資料率，在該第二界面把該至少一流送內容，傳輸至該至少一委託機裝置者。
6. 一種電腦程式製品，其特徵為，包括程式碼指令，當該程式在電腦上執行時，可供執行申請專利範圍第5項之方法步驟者。