P2p流傳送支持的製作方法

2023-10-07 00:01:29 2

P2p流傳送支持的製作方法
【專利摘要】本發明涉及優化在P2P直播流傳送網絡(12)與接入網絡(30)之間的負載傳輸的方法和布置。方法包括以下步驟，比如：接入網絡中的對等體(16)選擇要使用的信道。將包括選擇的信道的信息的請求(57)從接入網絡發送到流傳送網絡。連接P2P直播流傳送網絡和接入網絡的變換器節點(40)檢測接入網絡中使用選擇的信道的對等體(16-19)數量已達到預確定的閾值(T)。作為從流傳送網絡中的對等體(13-15)來的選擇的信道的部分的組塊(chunk)在變換器節點(40)中從P2P格式變換成多播格式。
【專利說明】[0001] P2P流傳送支持

【技術領域】
[0002] 所述實施例一般涉及系統和方法，並且更具體地說，涉及用於實現在P2P直播流 傳送網絡與接入網絡之間優化的負載傳輸的機制和技術。

【背景技術】
[0003] 公司在迅速添加動態、豐富和交互式能力以改進用戶體驗，增長在線觀眾及推動 頁面觀看和事務。隨著網站向完全豐富、動態的在線信道體驗發展，企業面臨新的巨大挑 戰。今天的消費者已變得預期高度交互式在線體驗。例如，在觀看電影時，他們要求順暢、 無瑕疵的體驗。在國際申請W02010/005349中，公開了一種方法用於通過檢索來自外部域 的要求的內容，並且將其變換成可經IPTV機頂盒接入的格式，由IPTV機頂盒接入來自IPTV 服務提供商的域外的外部域的內容。
[0004] P2P流傳送應用以與其它P2P文件共享客戶端幾乎相同的方式工作，除了用戶下 載流而不是下載文件。這些流然後與其它用戶實時轉換。
[0005] 圖1公開作為對等直播流傳送應用的Peer2View (P2View)。圖1示出包括P2View 對等體13-15的網際網路網絡12。附圖也公開原始伺服器10、內容分布網絡⑶N 11和P2P 客戶端16。附圖示出由HTTP組塊1-6形成的HTTP流的輸送。組塊從原始伺服器或內容 分布網絡⑶N中的伺服器輸送，S卩，要流傳送的文件已被拆分成組塊，並且從原始伺服器或 CDN網絡中的伺服器流傳送。如果許多客戶端同時要求來自伺服器的流，則它可造成系統 過載。由於此原因，伺服器已被分解成更小的對等體（網際網路中的Peer2View對等體)，而不 是具有一個伺服器(原始伺服器或⑶N伺服器)，並且組塊現在也是每個對等體13-15的一 部分。P2P客戶端16在尋找例如組塊4時，它將判定哪個組塊源在延遲方面最近或最短， 並且從那裡獲取組塊4。基本原理的示例如下所述。P2P客戶端16進入系統時，客戶端開 始尋求現有視頻流信道。客戶端由此聯繫信道列表伺服器(未在圖中)，並且伺服器返回信 道的列表。客戶端選擇所需信道，並且聯繫網際網路網絡中的跟蹤器(未在圖中）。跟蹤器知 道已經接收感興趣信道的所有對等體13-15。跟蹤器也知道⑶N伺服器11和原始伺服器 10。P2P客戶端例如通過將BART方法用於可用帶寬估計，在所有回覆的對等體之間執行測 量以查看哪個對等體是尋求需要的組塊的最適當對等體，並且然後提出組塊請求。
[0006] 上述技術存在問題。第一個問題是P2P流生成許多業務。根據P2P原理，如果組 塊被接收，則組塊的接收者要反過來共享組塊。與P2P有關的問題是當存在"無限"量的對 等體接收和共享時，運營商將難以標定網絡容量。第二問題是此大量業務在網絡上的影響 對於盡力而為型業務類形成了爭用。第三問題是額外成本，如用於移動接入(空中接口）的 增大成本、聚合和骨幹網絡中的傳輸成本及用於網際網路對等操作的增大成本。


【發明內容】

[0007] 實施例的目的是克服現有技術的上面提及的限制。實施例集中於通過經變換器節 點將接入網絡中的多播伺服器與P2P直播流傳送網絡放置在一起來以非P2P方式發送P2P 直播流傳送。如果接入網絡中的對等體正在使用/查看相同信道，並且如果對等體的數量 高於閾值，則將為組塊傳輸使用多播，而不是使用P2P。
[0008] 本發明的目的是優化負載傳輸。
[0009] -個示範實施例中的解決方案是優化在P2P直播流傳送網絡與接入網絡之間負 載傳輸的方法。方法包括以下步驟： -接入網絡中的對等體選擇要使用的信道。
[0010] -將包括選擇的信道的信息的請求從接入網絡發送到流傳送網絡。
[0011] -連接P2P直播流傳送網絡和接入網絡的變換器節點檢測到接入網絡中使用選擇 的信道的對等體數量已達到預確定的閾值。
[0012] -組塊（chunk)是來自流傳送網絡中的對等體（13-15)的選擇的信道的部分，在變 換器節點中變換成多播格式。
[0013] 另一示範實施例的解決方案是配置成優化負載傳輸的電信網絡的網絡節點。網絡 節點包括： -用於監聽從接入網絡中對等體傳送到P2P直播流傳送網絡的信令的部件； -用於檢測對應於接入網絡中使用選擇的信道的對等體數量的閾值的到達的部件； -用於將從P2P直播流傳送網絡中的對等體收到的塊組變換成多播格式的部件。
[0014] 在又一示範實施例中的解決方案是一種在電信網絡中配置成接收多播流傳送的 終端節點。節點包括： -用於提取從多播伺服器收到的承載信息的部件。
[0015] -用於接收啟動多播流傳送的接收的轉換消息的部件。
[0016] -用於打開多播套接字（socket)的部件。
[0017] -用於停止P2P流傳送客戶端的部件。
[0018] 實施例的一些優點如下所述： 解決方案進行增強多媒體廣播和多播服務eMBMS的可能利用，以便輸送在長期演進 LTE中通過網際網路經P2P分布的直播流。
[0019] 解決方案使能/允許去除網絡中消耗許多帶寬的P2P業務，並且使用作為輸送1-n 流的優選方式的多播來輸送流。
[0020] 現在將結合附圖，通過優選實施例更詳細地描述本發明。

【專利附圖】

【附圖說明】
[0021] 圖1屬於現有技術，並且公開示出將由HTTP組塊形成的HTTP流從P2P直播流傳 送網絡輸送到P2P客戶端的示意框圖。
[0022] 圖2屬於現有技術，並且公開使用增強多媒體廣播和多播服務eMBMS接口的eMBMS 功能的示意框圖。
[0023] 圖3屬於現有技術，並且公開示出多媒體廣播和多播服務會話開始、準備和通知 的信令序列圖。
[0024] 圖4公開集中於通過經變換器節點將接入網絡中的多播伺服器與P2P直播流傳送 網絡放置在一起來以非P2P方式發送P2P直播流傳送的解決方案概述的示意框圖。
[0025] 圖5在信令序列圖中公開通過使用多播以非P2P方式發送P2P直播流傳送的方 法。
[0026] 圖6公開變換器節點的示意框圖。
[0027] 圖7公開客戶端的示意框圖。

【具體實施方式】
[0028] 在下面的說明中，為了解釋而不是限制，陳述了特定的細節，如特定的電路、電路 組件、技術等，以便提供所述實施例的詳盡理解。然而，對於本領域的技術人員將顯而易見 的是，所述示例可在脫離這些特定細節的其它實施例中實踐。在其它情況下，省略了熟知的 方法、裝置和電路的詳細描述以免不必要的細節混淆所述實施例的描述。
[0029] 雖然P2P在網際網路內工作良好，但在其中多播將是優選的運營商的接入網絡內， 它不符合需要。圖2屬於現有技術，並且公開也稱為多播伺服器20的增強多播廣播媒體服 務器eMBMS 20。附圖示出使用eMBMS接口的eMBMS功能。多媒體廣播和多播服務MBMS是 經蜂窩網絡提供的廣播服務。增強MBMS (eMBMS)用於稱呼在包括E-UTRAN (LTE)和UTRAN 接入的演進分組系統中的MBMS服務。eMBMS包括廣播多播服務中心BMSC 21。BMSC是用 於3G網絡中多播的3GPP指定的解決方案。BMSC負責觸發運營商的網絡30內的多播。流 將來自內容源22, S卩，例如來自網際網路伺服器。BMSC處理MBMS會話，並且負責將用戶平面 媒體輸送到MBMS-GW 23。MBMS-GW提供用於將MBMS分組發送/廣播到傳送服務的每個eNB 25的功能性。MME 24將MBMS承載的會話控制提供到E-UTRAN接入。流將被饋送到BMSC 中，BMSC將流以多播方式轉發到運營商的網絡30。例如參閱文檔3GPP TS 25. 346或參考 設計EAB-11:045744 Uen以了解更詳細的描述。圖3屬於現有技術，並且公開eMBMS會話 建立的概述。附圖公開UE 16、包括eNB 25的eMBMS 20、MBMS-GW 23及BMSC 21。在接收 觸發信號79時，BMSC將會話開始請求信號80A發送到MBMS-GW。MBMS-GW將會話開始請求 信號80A經MME 24 (未在圖3中）轉發到eNB 25。eNB、MME和MBMS-GW通過會話開始響應 消息80B響應BMSC。所述信令序列稱為MBMS會話開始80。需要正好在MBMS傳送前的時 間為MBMS廣播預留接入網絡中的資源。假設以此類方式設置eNB中配置的許可控制限制 81A，從而能夠準時開始MBMS會話，並且為傳送分配81B資源。此信令在圖中稱為81 :MBMB 傳送準備。客戶端UE將獲得包括用戶設備應偵聽的到多播套接字的方向的通知82A。消息 82A和82B將確保用戶設備知道在哪個套接字上偵聽，S卩，消息象隱式聯結一樣工作。此信 令在圖中稱為82 :MBMS通知。多播通知提供有關哪些信道可用的信息。UE獲得該信息時， 它打開套接字。換而言之，伺服器通知有信道打開，並且一旦數據開始進入，UE便打開套接 字。例如參閱文檔3GPP TS 25. 346或參考設計EAB-11:045744 Uen以了解會話建立的更 詳細描述。現在將討論的實施例適用於MBMS和eMBMS以便覆蓋3G和LTE兩種情況。
[0030] 圖4公開下面將更詳細討論的實施例的解決方案概述。解決方案概述示出在因特 網12中的P2View對等體13-15。附圖還公開在接入網絡30中的P2P客戶端16-19。原始 伺服器10和內容分布網絡⑶N中的伺服器11在圖4中示出。伺服器10-11和對等體13-15 在此示例中擁有由HTTP組塊1-6組成的HTTP流。在此示例中，四個P2P客戶端16-19中 的三個客戶端17-19在查看相同直播流信道，並且擁有組塊1、2、3。在此示例中已分別從原 始伺服器10、⑶N伺服器11和對等體15獲取每個組塊1、2、3。組塊的獲取已根據現有技 術進行。根據實施例，網際網路12和接入網絡30經變換器節點（移動雲加速器對等）MCAP2P 40和增強多播廣播媒體伺服器eMBMS 30聯結在一起。上面已解釋eMBMS，並且下面將進一 步討論變換器節點。
[0031] 圖5在第一實施例中公開通過使用多播以非P2P方式發送P2View流傳送的方法。 圖5公開P2P客戶端16、信道列表伺服器71、eMBMS 20、變換器節點MCAP2P 40、跟蹤器70 和網際網路中的對等體15。信道列表伺服器71包括客戶端可能想使用的可用直播流信道的 列表。跟蹤器70選擇從中下載數據組塊的對等體集。跟蹤器充當P2P網絡中對等體之間 的網關。在基於跟蹤器體系結構的P2P系統中，在客戶端請求內容時，它聯繫跟蹤器以便獲 得具有期望的數據組塊的對等體的地址。跟蹤器通過地址的列表回復具有數據的對等體。 現在將解釋如果接入網絡中的對等體在查看相同信道，並且如果對等體的數量高於閾值， 則使用多播而不是P2P進行組塊傳輸的方法。在此示例中的前提條件是接入網絡中的P2P 客戶端17-19在查看相同直播流(參見圖4)。根據第一實施例的方法包括以下步驟： -在變換器節點40中設置50用於查看相同信道的對等體的數量的閾值。在此示例中， 閾值已設置成"四"。如所述的，三個P2P客戶端17-19已經在查看相同直播流。
[0032] -在此段落中討論的信令是現有技術的一部分。P2P客戶端16進入系統，並且聯 結51 P2View網絡，以及客戶端開始尋求52現有視頻流信道。客戶端由此聯繫信道列表服 務器71，並且伺服器返回53信道的列表。客戶端選擇期望的信道，期望的信道是與客戶端 17-19在查看的相同信道。客戶端16聯繫55網際網路網絡中的跟蹤器70。跟蹤器知道因特 網中擁有作為請求的信道的一部分的要求的組塊的所有對等體13-15,並且也知道CDN服 務器11和原始伺服器10。跟蹤器將跟蹤器響應56發送回客戶端16。響應包括已經觀看 信道的對等體的列表(通常是IP位址)。P2P客戶端例如通過將BART方法用於可用帶寬估 計，在所有回覆的對等體之間執行測量以查看哪個對等體是尋求需要的組塊的最適當對等 體。在此示例中，尋求組塊的最適當對等體是在網際網路中的P2View對等體之間，但也可考 慮伺服器10或11。客戶端通過將組塊列表請求57發送到網際網路中擁有與選擇的直播流有 關的組塊的對等體15,從該對等體尋求組塊的列表。請求包括信道信息。
[0033] -根據第一實施例，在變換器節點40中監聽58有關信道信息的組塊列表請求57。
[0034] -比較59使用相同信道的對等體(現在包括新對等體16)的數量和閾值。數量為 四，並且發現已達到閾值"四"。
[0035] -在變換器節點40中啟動61從P2P到多播的模式轉換(在查看相同信道的所有對 等體16-19中)。
[0036] -將模式轉換消息從變換器節點40中的媒體變換器42(參見圖6)發送63到eMBMS 20。媒體轉換消息對應於更早在圖3中公開的觸發消息79。
[0037] -eMBMS如更早在圖3中解釋的開始MBMS會話80。
[0038] -eMBMS如更早在圖3中解釋的執行MBMS傳送準備81。
[0039] -eMBMS如在圖3中解釋的執行MBMS通知82。這產生如更早在圖3中解釋的通過 信令82A和82B，從eMBMS到客戶端的信令。這通過圖5中的承載信息消息83公開。為簡 明起見，圖5中只提及一個客戶端，但使用信道將信令發送到所有客戶端16-19。承載信息 由客戶端從消息83提取。此信息由客戶端用於知道要聯結什麼多播承載。
[0040] -轉換消息62從變換器節點40中的P2P到多播轉換器43 (參見圖6)發送到客 戶端16,並且在接收消息時，打開64 MBMS套接字，並且在客戶端16中停止65 P2P流客戶 端。
[0041] -變換器節點40激活60組塊從P2P格式到多播MBMS格式的變換。通過MBMS下 載從P2P格式變換到例如DASH或HLS的多播格式屬於現有技術。
[0042] -MBMS數據廣播經BMSC 21從變換器節點40中的43饋送66到客戶端16。
[0043] -組塊在客戶端16中從MBMS套接字饋送68到視頻客戶端。
[0044] 圖6公開變換器節點40 (在此實施例中也稱為移動雲加速器對等MCAP2P 40)的 示意框圖。圖6公開MCAP2P體系結構。變換器節點包括媒體變換器42、P2P到多播轉換器 43和監聽單元44。MCAP2P模塊還包括虛擬化層41，取決於終端使用的協議，在該層上可能 部署和例示不同P2P協議。虛擬化層41允許共享的硬體資源和要由硬體資源運行的不同 應用48a-c。P2PView、Bittorent和P2PLive例如表示能夠放置在虛擬化層頂上並且由硬 件運行的伺服器軟體。在此示例中，P2View應用48a已放置在虛擬化層頂上，並且MCAP2P 在此示例中充當標準P2View客戶端。媒體變換器42將HTTP組塊從P2View格式變換成多 播格式。轉換器43啟動eMBMS以準備和通知用戶設備接收多播流傳送。監聽單元44包括 能夠從傳遞的消息提取信息的深度分組檢查模塊。監聽單元在此示例中包括資料庫45,數 據庫中存儲用於使用/查看相同信道的多個客戶端的閾值T。圖6還公開經接口附連到變 換器中轉換器43和監聽單元44的客戶端16。用戶設備還經BMSC 21附連到媒體變換器 42。跟蹤器70經接口附連到監聽單元44。網際網路12經接口附連到變換器節點40、到跟蹤 器70和客戶端16。在到達閾值T後，將觸發從監聽單元44發送到轉換器43,轉換器43將 模式轉換消息62 (參見圖5)發送到客戶端16以便轉換模式。從擁有網際網路中要求的組塊 的P2View對等體13-15將組塊接收到Peer2View應用48a。將屬於選擇的信道的組塊從 網際網路發送到P2View應用48a。將P2View格式的收到的組塊轉發到媒體變換器42,並且 變換成多媒體廣播和多播服務MBMS格式，並且以多播格式發送到eMBMS 20中的MBMS 21。 然後，將組塊從eMBMS中的BMSC以多播方式流傳送到客戶端16。
[0045] 圖7公開客戶端的示意框圖。附圖公開用戶設備體系結構。圖中示出包括MCAP2P 模塊91的Peer2View (P2P流傳送）客戶端90。MCAP2P模塊將接收在圖5中解釋的轉換 消息62。視頻渲染應用92將從P2View系統93或在已到達閾值後經MCAP2P 40從多播系 統接收來自直播流源94的組塊。eMBMS客戶端96經eMBMS 20接收MBMS通知82 (參見圖 5)，由此將提取TGMI。在來自MCAP2P 40的模式轉換消息62 (參見圖5)後，將打開eMBMS 客戶端中的MBMS套接字，並且將停止客戶端90。如果到達閾值，將從打開的MBMS套接字接 收組塊並且在客戶端中將其轉發到視頻渲染應用92。
[0046] 圖中以示意圖方式示出了能夠用於將本發明付諸實踐的系統和節點。列舉的項在 圖中示為單獨的要素。但是，在本發明的實際實現中，它們可能是諸如數字計算機的其它電 子裝置的不可分開的組件。因此，上述動作可以用軟體形式實現，而軟體可實施在包括程序 存儲媒體的製品中。程序存儲媒體包括在載波、計算機盤(磁性或光學(例如，CD或DVD或 兩者)）、非易失性存儲器、磁帶、系統存儲器或計算機硬驅動器中的一個或多個中實施的數 據信號。
[0047] 本發明的系統和方法例如可在第三代合作夥伴項目（3GPP)、歐洲電信標準協會 (ETSI)、美國國家標準協會（ANSI)、長期演進（LTE)或其它標準電信網絡體系結構中的任 何一個上實現。其它示例是電氣和電子工程師協會（IEEE)或網際網路工程任務組（IETF)。
[0048] 為了解釋而不是限制，本說明書陳述了特定的細節，如特定的組件、電子電路、技 術等，以便提供本發明的理解。但本領域的技術人員將理解，本發明可在脫離這些特定細節 的其它實施例中實踐。在其它實例中，省略了熟知方法、裝置和技術等的詳細說明以免不必 要的細節混淆本說明。在一個或多個附圖中顯示了單獨的功能塊。本領域的技術人員將理 解，可使用離散組件或多功能硬體實施功能。處理功能可使用編程的微處理器或通用計算 機實現。本發明不限於以上所述和附圖所示的實施例，而是可在隨附權利要求的範圍內進 行修改。
【權利要求】
1. 一種用於優化在P2P直播流傳送網絡（12)與接入網絡（30)之間的負載傳輸的方 法，所述方法包括： -由所述接入網絡中的對等體（16)選擇要使用的直播信道； -將包括所選擇的信道的信息的請求（57)從所述接入網絡發送到所述流傳送網絡；其 特徵在於： -在連接所述P2P直播流傳送網絡和所述接入網絡的變換器節點（40)中檢測所述接入 網絡中使用所述選擇的信道的對等體（16-19)數量已達到預確定的閾值（T); -在所述變換器節點（40)中將作為從所述流傳送網絡中的對等體（13-15)來的所述選 擇的信道的部分的組塊從P2P格式變換到多播格式。
2. 如權利要求1所述的優化負載傳輸的方法，還包括： -通過將模式轉換消息（63)從所述變換器節點（40)發送到多播伺服器（20)來啟動模 式轉換。
3. 如權利要求1或2的任一項所述的優化負載傳輸的方法，還包括： -由所述變換器節點￠2)啟動（40)檢測的對等體以從P2P模式轉換到多播模式。
4. 如權利要求3所述的優化負載傳輸的方法，還包括： -將變換的組塊從所述變換器節點（40)轉發到所述多播伺服器（20); -以多播方式將變換的組塊從所述多播伺服器（20)轉發￠6)到所述檢測的對等體 (16-19)。
5. 如權利要求3-4的任一項所述的優化負載傳輸的方法，還包括： -在所述檢測的對等體（16-19)中從接收自所述多播伺服器（20)的承載信息消息 (83)提取承載信息； -將來自所述變換器節點（40)的轉換消息￠2)接收至所述檢測的對等體； -在所述檢測的對等體中打開多播套接字； -在所述檢測的對等體中停止P2P流客戶端。
6. 如權利要求5所述的優化負載傳輸的方法，還包括： -將接收至檢測的對等體的信道流從所述套接字饋送到視頻客戶端。
7. 如前述權利要求中的任一項所述的優化負載傳輸的方法，還包括： -監聽（58)所述變換器節點（40)中的所述請求（57)。
8. 如權利要求7所述的優化負載傳輸的方法，由此通過使用深度分組檢查來在所述變 換器節點（40)中監聽（58)所述請求（57)。
9. 一種包括電腦程式代碼的電腦程式產品，其中所述電腦程式包括所述計算機 程序代碼在處理器中執行時適用於執行權利要求1-8的一項或更多項的方法的代碼。
10. -種配置成優化負載傳輸的電信網絡的網絡節點（40)，所述節點包括： -用於監聽從接入網絡（30)中的對等體（16-19)傳送到P2P直播流傳送網絡（12)的 信令的部件（44); -用於檢測對應於所述接入網絡（30)中使用選擇的信道的對等體數量的閾值的到達 的部件（44,45); -用於將在所述P2P直播流傳送網絡（12)中從對等體（13-15)收到的組塊從P2P格式 變換到多播格式的部件（42)。
11. 如權利要求10所述的網絡節點（40)，所述節點還包括： -用於通過將模式轉換消息￠3)發送到多播伺服器（20)來啟動模式轉換的部件 (42)。
12. 如權利要求11所述的網絡節點（40)，所述節點還包括： -用於將轉換消息62發送到所述接入網絡（30)中檢測到的對等體（16-19)以影響所 述對等體從P2P模式轉換到多播模式的部件（43)。
13. 如權利要求12所述的網絡節點（40)，所述節點還包括： -用於將變換的組塊轉發到所述多播伺服器（20)的部件（43)。
14. 如權利要求10-13任一項所述的網絡節點（40)，所述節點還包括： -用於存儲所述閾值（T)的部件（45)。
15. 如權利要求10-14任一項所述的網絡節點（40)，所述節點還包括： -虛擬化層，其取決於附連的終端使用的協議部署和例示不同協議。
16. -種電信網絡的終端節點（16)，所述節點包括： -用於提取從多播伺服器（20)收到的承載信息的部件； -用於接收啟動多播流傳送的接收的轉換消息（62)的部件； -用於打開多播套接字的部件； -用於停止P2P流傳送客戶端（90)的部件。
17. 如權利要求16所述的電信網絡的終端節點（16)，所述節點還包括： -用於播出收到的多播流傳送媒體的部件。
【文檔編號】H04L29/08GK104106252SQ201280069870
【公開日】2014年10月15日 申請日期:2012年6月8日 優先權日:2012年2月16日
【發明者】A.達莫拉 申請人:瑞典愛立信有限公司