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

【技術(shù)領(lǐng)域】
[0002] 所述實施例一般涉及系統(tǒng)和方法，并且更具體地說，涉及用于實現(xiàn)在P2P直播流 傳送網(wǎng)絡(luò)與接入網(wǎng)絡(luò)之間優(yōu)化的負(fù)載傳輸?shù)臋C制和技術(shù)。

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


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

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

【專利附圖】

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

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