移動云加速器中的優(yōu)化引擎及相關(guān)方法
【專利摘要】一種在裝置中實施的優(yōu)化引擎或方法配置成控制將內(nèi)容從內(nèi)容源提供商傳送到電信網(wǎng)絡(luò)中的內(nèi)容用戶（UE），通過從多個可能情景中選擇用于將內(nèi)容傳遞給內(nèi)容用戶的情景?？紤]觀眾放棄率、一天中的時間、與可能情景中的每個情景相關(guān)聯(lián)的UE電池能量消耗、與可能情景中的每個情景相關(guān)聯(lián)的網(wǎng)絡(luò)信令的量、內(nèi)容提供商的偏好、內(nèi)容用戶的偏好、將要被傳遞的內(nèi)容的類型以及當(dāng)前網(wǎng)絡(luò)負(fù)載中的一個或多個來選擇情景。
【專利說明】移動云加速器中的優(yōu)化引擎及相關(guān)方法
[0001]相關(guān)申請
本申請涉及并且要求來自2011年7月14日提交的名稱為“MCA Optimization Engineand Related Methods”的美國臨時專利申請(序列號61/507761)的優(yōu)先權(quán)。
【技術(shù)領(lǐng)域】
[0002]本發(fā)明的實施例包括控制從內(nèi)容提供商到電信網(wǎng)絡(luò)中用戶設(shè)備(UE)的內(nèi)容傳遞的裝置、方法以及軟件，以便通過考慮各種因素(例如，在傳輸全部內(nèi)容之前用戶放棄使用內(nèi)容、與一天中的時間有關(guān)的網(wǎng)絡(luò)利用、與傳遞內(nèi)容的方式有關(guān)的網(wǎng)絡(luò)信令、網(wǎng)絡(luò)負(fù)載、內(nèi)容提供商偏好、用戶的體驗質(zhì)量(QoE)、用戶偏好、UE的能量消耗，等等)來實現(xiàn)多維優(yōu)化。
【背景技術(shù)】
[0003]移動以及固定用戶設(shè)備(UE)能夠播出來自電信網(wǎng)絡(luò)中的各種源的媒體內(nèi)容。一般名為移動云加速器(MCA)的多種硬件和軟件在使得比當(dāng)源服務(wù)器直接供應(yīng)UE時更迅速、有效以及無縫地將內(nèi)容傳遞給用戶成為可能中共同起作用。例如，如圖1中圖示的，UE 10(可以是移動終端或固定終端)經(jīng)由MCA 30接收來自內(nèi)容提供商20的多媒體輸入。在MCA30內(nèi)，到UE 10的內(nèi) 容的實際傳遞可以由移動網(wǎng)絡(luò)運營商(MNO)控制并且可能經(jīng)歷各種機制，例如無線電優(yōu)先化、使用Akamai類型內(nèi)容傳遞網(wǎng)絡(luò)(CDN)的代理高速緩存、透明互聯(lián)網(wǎng)高速緩沖存儲器(TIC)，等等。
[0004]然而，常規(guī)的內(nèi)容傳遞系統(tǒng)和方法未能解決若干方面，例如，通過考慮將被傳遞的內(nèi)容的類型或用戶放棄率以及網(wǎng)絡(luò)信令負(fù)載來優(yōu)化資源(例如，帶寬、UE的電池)使用。
[0005]因此，將期望提供實現(xiàn)從內(nèi)容提供商到用戶的內(nèi)容傳遞中資源的多維優(yōu)化的更有效率的裝置、方法以及器件。

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

[0006]本發(fā)明的一個目標(biāo)是提供具有至少一個處理器并且配置成選擇將用于從源代理到移動網(wǎng)絡(luò)中的UE的內(nèi)容傳遞的情景的裝置，同時考慮用戶丟出率、移動網(wǎng)絡(luò)效率、終端效率、終端用戶要求以及內(nèi)容提供商要求中的一個或多個。根據(jù)內(nèi)容的性質(zhì)來確定將要用于內(nèi)容傳遞的情景的參數(shù)，并且情景可包括到UE的內(nèi)容傳遞期間將要使用的機制，例如(但不限于)視頻定速(pacing)、內(nèi)容推遲(deferral)、去除優(yōu)先化(de-prioritization)以及TCP加速。實施例引起以下中的至少一個:用于UE的電池的能量消耗中的減少、當(dāng)傳遞由于用戶放棄而未正使用的內(nèi)容時網(wǎng)絡(luò)帶寬的浪費中的減少、以及避免偶爾或由于一天中的時間引起的負(fù)載聞時的網(wǎng)絡(luò)過載。
[0007]另一個目標(biāo)是提供在控制從源代理向移動網(wǎng)絡(luò)中的UE的內(nèi)容傳遞中采用的方法，所述方法執(zhí)行確定多媒體內(nèi)容被傳遞的方式，同時考慮用戶丟出率、移動網(wǎng)絡(luò)效率、終端效率、終端用戶要求以及內(nèi)容提供商要求中的一個或多個。所述方法可包括輸出按照根據(jù)內(nèi)容性質(zhì)的不同情景將被用于內(nèi)容傳遞的參數(shù)，以及選擇相對在將內(nèi)容傳遞給UE中將要使用的機制，例如(但不限于)視頻定速、內(nèi)容推遲、去除優(yōu)先化以及TCP加速。
[0008]換句話說，本發(fā)明概念的實施例實現(xiàn)向UE的內(nèi)容傳遞服務(wù)的多維優(yōu)化。實施例中的一個或多個有利地提供網(wǎng)絡(luò)中減少的業(yè)務(wù)負(fù)載，以及UE更優(yōu)的使用，例如，通過節(jié)約其功率。
[0009]按照示范性實施例，一種裝置配置成控制將內(nèi)容從內(nèi)容源提供商傳遞到電信網(wǎng)絡(luò)中的內(nèi)容用戶(UE)。所述裝置包括處理單元，所述處理單元配置成根據(jù)包括觀眾放棄率的一個或多個因素來從多個可能情景中選擇用于將內(nèi)容傳遞給內(nèi)容用戶的情景，并且按照選擇的情景來傳遞內(nèi)容 。
[0010]按照另一個示范性實施例，一種用于控制從內(nèi)容源提供商到電信網(wǎng)絡(luò)中的內(nèi)容用戶(UE)的內(nèi)容傳遞的方法包括:(A)接收并存儲將要從內(nèi)容源提供商被傳遞給內(nèi)容用戶的內(nèi)容；(B)從多個可能情景中選擇用于將內(nèi)容傳遞給內(nèi)容用戶的情景，所述情景根據(jù)包括觀眾放棄率的一個或多個因素來選擇，以及(C)按照所選擇的情景來將內(nèi)容傳遞給內(nèi)容用戶。
[0011]按照又一示范性實施例，計算機可讀媒體存儲可執(zhí)行代碼，當(dāng)在處理器上被執(zhí)行時，所述可執(zhí)行代碼使得處理器執(zhí)行用于控制從內(nèi)容源提供商到電信網(wǎng)絡(luò)中的內(nèi)容用戶(UE )的內(nèi)容傳遞的方法。所述方法包括(A )從多個可能情景中選擇用于將內(nèi)容傳遞給內(nèi)容用戶的情景，所述情景根據(jù)包括觀眾放棄率的一個或多個因素來選擇，以及(B)按照選擇的情景來將內(nèi)容傳遞給內(nèi)容用戶。
[0012]控制從內(nèi)容提供商到電信網(wǎng)絡(luò)中的用戶設(shè)備(UE )的內(nèi)容傳遞的裝置、方法及軟件實現(xiàn)多維優(yōu)化并且提供以下中的優(yōu)勢:節(jié)約網(wǎng)絡(luò)資源(例如，由傳輸隨后被用戶放棄的內(nèi)容而浪費的帶寬)、避免網(wǎng)絡(luò)過載、節(jié)約電池能量，以及最終提供更好體驗給各個用戶和橫跨電信網(wǎng)絡(luò)的全體。
【專利附圖】

【附圖說明】
[0013]合并到說明書中并且構(gòu)成說明書的一部分的附圖圖示了一個或多個實施例并且與描述一起解釋這些實施例。在附圖中:
圖1是常規(guī)內(nèi)容傳遞系統(tǒng)的示意圖；
圖2是圖示與不同無線電狀態(tài)相關(guān)聯(lián)的功率電平的圖；
圖3是圖示按照示范性實施例的數(shù)據(jù)傳輸特性相對功率消耗和不同無線電狀態(tài)之間的轉(zhuǎn)換的圖；
圖4是圖示按照示范性實施例的相對于觀看時間的放棄率的圖；
圖5是圖示按照示范性實施例的一天期間的網(wǎng)絡(luò)使用的圖；
圖6是按照示范性實施例的多媒體內(nèi)容傳遞系統(tǒng)；
圖7是按照示范性實施例的輸入到優(yōu)化引擎的因素的圖形圖示；
圖8是按照示范性實施例的建立用于不同情景的參數(shù)表；
圖9是按照示范性實施例的優(yōu)化引擎的示意圖；
圖10是圖示傳遞視頻內(nèi)容的不同方式的圖；
圖11是按照示范性實施例的視頻定速示例；
圖12A和12B用圖圖示按照示范性實施例的使用UE電池的不同的可能策略；圖13圖示按照示范性實施例的根據(jù)對視頻進(jìn)行定速的方式的用戶放棄的效果；
圖14是按照示范性實施例的內(nèi)容推遲示例；
圖15是按照示范性實施例的去除優(yōu)先化示例；
圖16是按照示范性實施例的裝置的示意圖；
圖17是按照示范性實施例的方法的流程圖；以及 圖18是按照另一個示范性實施例的方法的流程圖。
【具體實施方式】
[0014]示范性實施例的以下描述參考附圖。不同附圖中的相同附圖標(biāo)記標(biāo)識相同或類似要素。以下詳細(xì)描述并不限制本發(fā)明。替代地，由附加的權(quán)利要求書來限定本發(fā)明的范圍。為了簡潔起見，關(guān)于內(nèi)容傳遞系統(tǒng)(例如，滿足當(dāng)前3GPP文件中描述的特性的系統(tǒng))的術(shù)語和結(jié)構(gòu)來討論以下實施例。然而，接著將要討論的實施例不限于這些系統(tǒng)，而是可以適用于其它現(xiàn)有的內(nèi)容傳遞系統(tǒng)，例如但不限于WIFI系統(tǒng)。
[0015]說明書各處對“一個實施例”或“一實施例”的提及意指結(jié)合實施例描述的特定特征、結(jié)構(gòu)或特性被包括在本發(fā)明的至少一個實施例中。因此，說明書各處多個地方中短語“在一個實施例中”或“在一實施例中”的出現(xiàn)不一定全部指的是相同實施例。此外，在一個或多個實施例中，可以按適當(dāng)?shù)姆绞絹斫M合特定的特征、結(jié)構(gòu)或特性。
[0016]連接到電信網(wǎng)絡(luò)的用戶設(shè)備可以在不同的相應(yīng)狀態(tài)中以不同的預(yù)定數(shù)據(jù)速率來接收數(shù)據(jù)(內(nèi)容)。由用戶設(shè) 備使用的功率并不與接收數(shù)據(jù)速率成比例，盡管更高的數(shù)據(jù)速率與更高功率相關(guān)聯(lián)。比例性的缺乏使得能量消耗取決于用于傳遞內(nèi)容所使用的情景。情景是一個或多個時間時期的序列，在每個時間時期期間用可能的數(shù)據(jù)速率中的相同數(shù)據(jù)速率來傳遞內(nèi)容。
[0017]為了說明而非限制的目的，UE可以在4個WCDMA無線電狀態(tài)中的一個中(如描述的，例如，在由 Harri Holma, Antti Toskala 的 “WCDMA for UMTS: HSPA Evolution and LTE，，的2011版中):高狀態(tài)(當(dāng)使用專用信道DCH時)、低狀態(tài)(當(dāng)使用前向接入信道FACH時)、備用狀態(tài)(當(dāng)只有尋呼信道PCH可以被使用來接入UTRAN注冊區(qū)域URA時)以及空閑狀態(tài)(當(dāng)UE未連接到網(wǎng)絡(luò)時)。如圖2中圖示的，在“高”狀態(tài)中，使用的電流是250mA，在“低”狀態(tài)中，使用的電流是120mA，而在“備用”和“空閑”狀態(tài)中，使用的電流實際上是零。因此，在不同狀態(tài)中，從UE電池要求不同量的功率。
[0018]如在圖3的X軸上圖示的，不僅僅數(shù)據(jù)速率和功率不同用于不同狀態(tài)，而且等待時間、信令以及其它資源使用也可以不同用于不同狀態(tài)。根據(jù)數(shù)據(jù)傳輸活動是否被維持(例如，當(dāng)UE在更高功率狀態(tài)中時，在沒有活動逝去的情況下，在預(yù)定時間間隔之后到更低狀態(tài)的轉(zhuǎn)換)以及根據(jù)正在進(jìn)行的應(yīng)用會話，狀態(tài)之間的轉(zhuǎn)換(同樣在圖3中圖示的)發(fā)生。在圖3的y軸上,表示用于不同狀態(tài)的相對功率消耗(I對應(yīng)于最大值)。
[0019]在更一般的方法中，實施例相對于無線電狀態(tài)操作，所述無線電狀態(tài)包括第一狀態(tài)和第二狀態(tài)，在第一狀態(tài)期間內(nèi)容用戶以第一數(shù)據(jù)速率接收內(nèi)容并且使用第一電池功率，在第二狀態(tài)期間內(nèi)容用戶以第二數(shù)據(jù)速率接收內(nèi)容并且使用第二電池功率，第一數(shù)據(jù)速率比第二數(shù)據(jù)速率大，第一電池功率比第二電池功率大。
[0020]研究已經(jīng)顯示用戶在部分觀看之后頻繁地放棄數(shù)據(jù)傳輸。例如，當(dāng)視頻被流傳送時(例如，來自例如YouTube的服務(wù))，用戶經(jīng)常只觀看視頻剪輯的最初幾秒直到他們決定他們不打算繼續(xù)觀看。圖4是圖示放棄率(y軸上)和觀看時間(X軸上)之間的相關(guān)性的圖。
19.4%的基準(zhǔn)初始放棄率幾乎是先前報告的行業(yè)數(shù)字的兩倍。此外，觀眾放棄率沿著相對可預(yù)測的軌跡增加:在播出的30秒33.4%放棄；在60秒44.1%放棄；在90秒52.5% ；以及在120秒58.5%。急促以最高速度傳遞整個內(nèi)容(例如，視頻剪輯)產(chǎn)生系統(tǒng)中帶寬的浪費以及用戶設(shè)備處能量消耗的浪費。
[0021]同樣眾所周知的是移動網(wǎng)絡(luò)在24小時時期(天)上不平均地被利用。在高峰時間期間，大約一天中的17:00-22:00之間，網(wǎng)絡(luò)被最多地利用。相反，在非高峰時間期間，大約一天中的01:00-06:00之間，網(wǎng)絡(luò)被最少地利用。圖5圖示了根據(jù)一天期間的小時(在X軸上)的網(wǎng)絡(luò)利用(在y軸上的任意單元中示出)。如果將被傳遞的內(nèi)容是例如可以被延遲的傳遞(例如，軟件更新)，則使傳遞推遲到非高峰時間將是有用的。
[0022]按照圖6中圖示的示范性實施例，系統(tǒng)100配置成經(jīng)由媒體內(nèi)容加速器(MCA) 130將多媒體內(nèi)容從內(nèi)容服務(wù)應(yīng)用(CSA) 120提供給UE 110?？梢允怯布蛙浖慕M合并且可以駐留在多個節(jié)點上的MCA 130 (MCA包括至少兩個節(jié)點，DPI節(jié)點和高速緩沖存儲器服務(wù)器)配置成優(yōu)化CSA 120和UE 110之間的內(nèi)容傳遞，例如，通過使用代理(例如，Akamai CDN)和透明互聯(lián)網(wǎng)高速緩沖存儲器(TIC)。MCA 130配置成通過按照優(yōu)先級分配資源、按照根據(jù)內(nèi)容性質(zhì)的不同情景輸出將被用于每個內(nèi)容傳遞的參數(shù)、和/或使用機制(例如但不限于，視頻定速、內(nèi)容推遲、去除優(yōu)先化以及TCP加速)來控制到多個用戶的內(nèi)容傳遞。
[0023]MCA 130包括優(yōu)化引擎132 (即，具有至少一個處理器的處理單元)，所述優(yōu)化引擎132使得可能實現(xiàn) (除了 CDN和優(yōu)先化的常規(guī)MCA功能性之外)另外的特征，例如，內(nèi)容傳遞推遲134、視頻定速136、移動使用增強138，等等。使用可以被認(rèn)為是所有者信息的與請求的內(nèi)容傳遞的特性(例如，播出速率)、網(wǎng)絡(luò)的當(dāng)前狀態(tài)以及UE的容量有關(guān)的信息由優(yōu)化引擎132提供這些另外的功能。另外的功能構(gòu)成所有者的總成本(TCO)費用。
[0024]可以由優(yōu)化引擎132 (如圖7中圖示的)接收作為輸入的信息(因素)可以屬于不同種類。圖7未圖示全部因素并且圖示的因素中沒有一個是必需的輸入；實際上，任何一個輸入以及輸入的任何組合可以被用于不同實施例。為了圖示而非限制的目的，種類可以是可以由移動網(wǎng)絡(luò)運營商(MNO)提供的到優(yōu)化引擎132的輸入:一天網(wǎng)絡(luò)利用的時間210、網(wǎng)絡(luò)帶寬負(fù)載212以及網(wǎng)絡(luò)信令負(fù)載214。與用戶的體驗有關(guān)的另一個種類可包括用戶體驗質(zhì)量(QoE)216，并且與用戶的行為有關(guān)的另一個種類可包括觀眾放棄218。UE要求種類可包括UE電池220的使用和容量。CSA要求222可以是指示關(guān)于推遲是否可容許的用戶偏好的因素(和種類)。
[0025]這些因素被輸入到優(yōu)化引擎并且由優(yōu)化引擎132輸出特征化情景的對應(yīng)參數(shù)值。換句話說，優(yōu)化引擎132從所有可能情景中選擇或確定情景。選擇的情景的類型同樣取決于將被提供給UE的媒體內(nèi)容的類型。例如，確定參數(shù)的不同集合用于軟件更新下載情景、視頻流傳送情景、社交網(wǎng)絡(luò)更新情景、豐富媒體上載情景或廣告?zhèn)鬟f情景。可以將軟件更新推遲至非高峰時間，因此情景包括初始的無傳輸時期。視頻流傳送必須被定速，例如已經(jīng)被傳遞給內(nèi)容用戶的內(nèi)容的量超過播出的內(nèi)容的量以便當(dāng)在UE觀看時，避免由于將要被播放的數(shù)據(jù)的缺乏而引起的視頻剪輯的靜止。
優(yōu)化意指尋找如圖8中圖示的與適當(dāng)情景相對應(yīng)的參數(shù)值的集合。因此，參數(shù)包括網(wǎng)絡(luò)要求、終端要求、用戶要求以及內(nèi)容提供商要求。用于每個參數(shù)的優(yōu)化目標(biāo)不同:網(wǎng)絡(luò)負(fù)載、網(wǎng)絡(luò)信令以及終端電池消耗是分別最小化過程的主題，而用戶的QoE是最大化過程的主題。一些因素具有作用就像限制的固定值，例如，觀眾放棄率、基于編碼率的內(nèi)容的播出速率以及一天利用的網(wǎng)絡(luò)時間。當(dāng)實現(xiàn)一個優(yōu)化目標(biāo)影響實現(xiàn)另一個優(yōu)化目標(biāo)時，可以分配不同的權(quán)重給多維優(yōu)化功能內(nèi)的不同優(yōu)化目標(biāo)。備選地，可以按預(yù)定順序來執(zhí)行優(yōu)化。
[0026]除了建立與當(dāng)前情景相對應(yīng)的參數(shù)用于特定UE之外，優(yōu)化引擎還可選擇相對于傳遞內(nèi)容可使用的各種機制。圖9圖示優(yōu)化引擎300的操作。機制310包括(不限于)視頻定速、內(nèi)容推遲、去除優(yōu)先化以及TCP加速。對于預(yù)定情景320的集合中的一個，優(yōu)化引擎300接收各種因素的當(dāng)前值的信息作為輸入，確定參數(shù)的集合，并且可以選擇可用機制310中的一個。
[0027]在一個實施例中，當(dāng)內(nèi)容的類型是視頻流傳送時，優(yōu)化引擎可選擇使用視頻定速。在這個情況下，在優(yōu)化期間給以下3個維度重要的權(quán)重:UE電池消耗、觀眾放棄、網(wǎng)絡(luò)信令負(fù)載。另一個隱含的維度是體驗質(zhì)量(QoE)，執(zhí)行內(nèi)容傳遞使得滿足在UE的緩沖器中具有足夠的視頻數(shù)據(jù)的要求以確保不出現(xiàn)緩沖器未充分運行情況。
[0028]圖10是圖示傳遞視頻內(nèi)容的兩種不同方式的圖:在高速率突發(fā)410中，以及在恒定低速率420，傳遞速率大于視頻播出速率400。左邊的J軸表示觀眾放棄的概率以及還有傳輸或使用率水平。右邊的I軸表示無線電狀態(tài)能量水平(其與傳輸速率成比例)并且底部的X軸是期間內(nèi)容被傳遞或播出的時間。優(yōu)化引擎標(biāo)識傳遞內(nèi)容的最優(yōu)方式，其將同時實現(xiàn):通過將內(nèi)容傳遞在時間中分散來最小化如果觀眾放棄視頻項目而被浪費的資源(數(shù)據(jù)傳輸容量、電池能量)、最小化電池能量消耗、避免過度負(fù)載信令負(fù)載(產(chǎn)生無線電狀態(tài)轉(zhuǎn)換必需的最低數(shù)量)同時維護觀眾的QoE 。
[0029]圖11是按照示范性實施例的視頻定速裝置:
1.不管移動網(wǎng)絡(luò)或UE的特性，視頻內(nèi)容從內(nèi)容提供商500被流傳送到鏡像(高速緩沖存儲器或代理)位置510 ；
2.視頻內(nèi)容由TIC代理；
3.確定在UE的視頻播出速率；
4.優(yōu)化引擎選擇并確定情景的參數(shù)，考慮(I)觀眾放棄、(2)信令負(fù)載以及(3)電池效率。優(yōu)化引擎可以選擇視頻定速機制或不同策略，例如(a)在低能量水平(FACH)發(fā)送視頻以及(b)在高(DCH)模式和空閑模式之間變化；
5.按照選擇的情景以定速的方式將視頻內(nèi)容傳遞給UE520。
[0030]從使用UE的電池效率的觀點來看，一個次優(yōu)的策略是在高無線電狀態(tài)(DCH)中在周期的突發(fā)610中傳遞視頻內(nèi)容，如在圖12A中圖示的，其中矩形600表示視頻的播出。這個策略是次優(yōu)的因為存在以下的高概率:浪費的帶寬(如果觀眾放棄視頻內(nèi)容)、至少在突發(fā)期間的高電池消耗、以及由于許多狀態(tài)轉(zhuǎn)換而引起的高信令負(fù)載。另一個更好的測量是在低無線電狀態(tài)(FACH)中在圖12B中圖示的長時間時期620上傳遞視頻。當(dāng)使用這個后面的測量時，浪費帶寬的概率減小、電池消耗更低并且因為出現(xiàn)很少的狀態(tài)轉(zhuǎn)換，所以信令負(fù)載低。圖12A和12B中的線605表示放棄率。在圖12B中，將內(nèi)容傳遞給UE的速率超過播出速率。
[0031]然而，如果低速率比播出速率低，則定速模式(B卩，包括除了低速率時期之外的至少一個高速率時期的序列)是必需的。UE的無線電狀態(tài)的每個改變由UE和網(wǎng)絡(luò)之間的信令伴隨。因此，最優(yōu)的定速模式將具有無線電狀態(tài)的盡可能少的變化。
[0032]從QoE的角度來看，用戶將不愿體驗如果存在緩沖器未充分運行(即，沒有足夠的數(shù)據(jù)被提供給視頻應(yīng)用播出緩 沖器)可以出現(xiàn)的靜止圖像或空白屏幕。優(yōu)化引擎通過確保用將不允許緩沖器未充分運行情況的傳輸速率來提供視頻以解決這個方面。這通過在視頻應(yīng)用播出緩沖器中維持超前當(dāng)前播出點的最小量數(shù)據(jù)來實現(xiàn)。通常，如圖12B中圖示的，選擇的傳輸速率比視頻播出速率大。如果視頻傳輸速率比播出速率低，則可以在內(nèi)容傳遞時期的開始在更高狀態(tài)中以更高速率來填充播出緩沖器。
[0033]雖然必須在播出緩沖器中維持超前當(dāng)前播出點的最小量數(shù)據(jù)，考慮到高放棄率，期望這個量是最小的以便避免浪費帶寬以及電池功率用于傳輸不打算使用的數(shù)據(jù)。例如，如圖13的上部分中圖示的，如果在觀眾放棄觀看的時刻700已經(jīng)傳遞全部視頻，則被用于在時刻700之后將已經(jīng)被播出的視頻的傳遞的帶寬710已經(jīng)被浪費。然而，如在圖13的下部分中圖示的，如果視頻傳遞最低程度地超前播出點，并且在觀眾放棄觀看的時刻700之后視頻中的大部分將已經(jīng)被傳遞，則節(jié)約了將已經(jīng)用于繼續(xù)視頻傳遞的帶寬720。
[0034]對優(yōu)化引擎可用的另一個機制是內(nèi)容推遲。在圖14中圖示了內(nèi)容推遲機制的操作:
1.MNO 800將網(wǎng)絡(luò)負(fù)載分布(profile)提供給MCA優(yōu)化引擎800 ；
2.內(nèi)容提供商(CSA)820將推遲規(guī)則提供給MCA優(yōu)化引擎810 ；
3.CSA 820發(fā)送龐大的內(nèi)容(例如，軟件更新下載)給MCA ；
4.MCA優(yōu)化引擎810基于業(yè)務(wù)分布決定將到UE 830的龐大內(nèi)容的傳遞推遲直到后面的時間(例如，非高峰時間)；
5.當(dāng)被調(diào)度時(例如，在非高峰時間)，內(nèi)容被傳遞給UE830。
[0035]對于優(yōu)化引擎可用的另一個機制是去除優(yōu)先化。在圖15中圖示了去除優(yōu)先化機制的操作:
1.MNO 900使用P2P接口 Rx 905來監(jiān)管到UE 910的內(nèi)容傳遞；
2.MCA優(yōu)化引擎920標(biāo)識內(nèi)容是龐大的并且基于政策做出Rx請求以去除優(yōu)先化；
3.RX 905將龐大的會話放置在低優(yōu)先級上；
4.使用低優(yōu)先級載體將龐大的內(nèi)容傳遞給UE910。
[0036]按照另一個示范性實施例，當(dāng)提及MCA引擎時(B卩，確定多媒體內(nèi)容從源代理被傳遞給移動網(wǎng)絡(luò)中的UE的方式，同時考慮用戶丟出率、移動網(wǎng)絡(luò)效率、終端效率、終端用戶要求以及內(nèi)容提供商要求中的一個或多個)，能夠執(zhí)行上面描述的功能性的裝置1000可包括輸入/輸入接口 1010以及處理器1020，如圖16中圖示的。控制器1000還可以包括存儲軟件的計算機可讀存儲媒體1030，當(dāng)由處理器執(zhí)行時，所述軟件確定處理器提供上面描述的功能性。
[0037]圖17中圖示了在控制從源代理向移動網(wǎng)絡(luò)中的UE的內(nèi)容傳遞中采用的方法1100的流程圖。方法1100包括在SlllO確定多媒體內(nèi)容被傳遞的方式，同時考慮用戶丟出率、移動網(wǎng)絡(luò)效率、終端效率、終端用戶要求以及內(nèi)容提供商要求中的一個或多個。方法1100還包括在S1120按照根據(jù)內(nèi)容性質(zhì)的不同情景來輸出將要被用于內(nèi)容傳遞的參數(shù)。所述方法還可包括在S1130選擇相對在將內(nèi)容傳遞給UE中將要使用的機制，例如(但不限于)視頻定速、內(nèi)容推遲、去除優(yōu)先化以及TCP加速。
[0038]圖18中圖示了用于控制從內(nèi)容源提供商到電信網(wǎng)絡(luò)中的內(nèi)容用戶(UE)的內(nèi)容傳遞的方法1200的流程圖。方法1200包括在S1210接收并存儲將要從內(nèi)容源提供商被傳遞給內(nèi)容用戶的內(nèi)容。此外，方法1200包括在S1220從多個可能情景中選擇用于將內(nèi)容傳遞給內(nèi)容用戶的情景，該情景根據(jù)包括觀眾放棄率的一個或多個因素來選擇。方法1200還包括在S1230按照選擇的情景來將內(nèi)容傳遞給內(nèi)容用戶。
[0039]公開的示范性實施例包括MCA優(yōu)化引擎(即，控制器)、方法以及軟件，用于確定多媒體內(nèi)容從源代理被傳遞給移動網(wǎng)絡(luò)中的UE的方式，同時考慮用戶丟出率、移動網(wǎng)絡(luò)效率、終端效率、終端用戶要求以及內(nèi)容提供商要求中的一個或多個。應(yīng)該理解這個描述不意在限制本發(fā)明。相反，示范性實施例意在覆蓋被包括在本發(fā)明的精神和范圍中的備選、修改以及等同物。此外，在示范性實施例的詳細(xì)描述中，闡述了許多具體細(xì)節(jié)以便提供本發(fā)明概念的全面理解。然而，本領(lǐng)域技術(shù)人員將理解在沒有這樣的具體細(xì)節(jié)的情況下也可以實踐各種實施例。
[0040]示范性實施例可以采取完全硬件實施例或組合硬件和軟件方面的實施例的形式。此外，示范性實施例可以采取被存儲在具有在媒體中實施的計算機可讀指令的計算機可讀存儲媒體上的計算機程序產(chǎn)品的形式?？梢岳萌魏芜m當(dāng)?shù)挠嬎銠C可讀媒體，包括硬盤、CD-ROM、數(shù)字多功能盤(DVD )、光存儲器件、或磁存儲器件(例如軟盤或磁帶)。計算機可讀媒體的其它非限制性示例包括閃速類型的存儲器或其它已知存儲器。
[0041]雖然在以特定組合的實施例中描述提出的示范性實施例的特征和要素，但是在沒有實施例的其它特征和要素的情況下，或者在與或不與本文公開的其它特征和要素的各種組合中，可以單獨使用 每個特征或要素。可以在有形地實施在計算機可讀存儲媒體中用于由特別編程的計算機或處理器執(zhí)行的計算機程序、軟件或固件中實現(xiàn)本申請中提供的方法或流程圖。
【權(quán)利要求】
1.一種配置成控制將內(nèi)容從內(nèi)容源提供商傳遞到電信網(wǎng)絡(luò)中的內(nèi)容用戶(UE)的裝置(130、510、1000)，包括: 處理單元(132、300、810、920、1020)，配置成根據(jù)包括觀眾放棄率的一個或多個因素，從多個可能情景中選擇用于將所述內(nèi)容傳遞給所述內(nèi)容用戶的情景，并且按照選擇的情景來傳遞所述內(nèi)容。
2.如權(quán)利要求1所述的裝置，還包括: 數(shù)據(jù)存儲單元，配置成存儲從所述內(nèi)容源提供商接收的將按照所述選擇的情景被傳遞給所述內(nèi)容用戶的所述內(nèi)容。
3.如權(quán)利要求1所述的裝置，其中所述一個或多個因素還包括以下中的至少一個:(A) —天中的時間、(B)與所述可能情景中的每個情景相關(guān)聯(lián)的UE的電池能量消耗、(C)與所述可能情景中的每個情景相關(guān)聯(lián)的網(wǎng)絡(luò)信令的量、(D)所述內(nèi)容提供商的偏好、(E)所述內(nèi)容用戶的偏好、(F)將被傳遞的所述內(nèi)容的類型，以及(G)當(dāng)前網(wǎng)絡(luò)負(fù)載。
4.如權(quán)利要求1所述的裝置，其中 內(nèi)容的所述類型是包括軟件更新、視頻或音頻流傳送、社交網(wǎng)絡(luò)更新、豐富媒體上載以及廣告?zhèn)鬟f的多個類型中的一個，并且 所述多個可能情景 中的一些包括使用一個或多個機制，例如視頻定速、內(nèi)容推遲、去除優(yōu)先化以及TCP加速。
5.如權(quán)利要求4所述的裝置，其中所述處理單元還配置成如果內(nèi)容的所述類型是視頻或音頻流傳送，則選擇使用視頻定速的情景，并且所述情景將是例如當(dāng)傳遞所述內(nèi)容時，已經(jīng)被傳遞給所述內(nèi)容用戶的所述內(nèi)容的量超過已經(jīng)由所述內(nèi)容用戶播出的所述內(nèi)容的量。
6.如權(quán)利要求5所述的裝置，其中 無線電狀態(tài)包括第一狀態(tài)和第二狀態(tài)，在所述第一狀態(tài)期間所述內(nèi)容用戶以第一數(shù)據(jù)速率接收所述內(nèi)容并且使用第一電池功率，在所述第二狀態(tài)期間所述內(nèi)容用戶以第二數(shù)據(jù)速率接收所述內(nèi)容并且使用第二電池功率，所述第一數(shù)據(jù)速率比所述第二數(shù)據(jù)速率大，所述第一電池功率比所述第二電池功率大，并且 所述處理單元還配置成使用所述第一狀態(tài)和所述第二狀態(tài)來傳遞所述內(nèi)容以便最小化能量消耗。
7.如權(quán)利要求4所述的裝置，其中所述處理單元配置成如果所述選擇的情景包括所述內(nèi)容推遲，則延遲傳遞所述內(nèi)容。
8.如權(quán)利要求7所述的裝置，其中所述處理單元配置成按照預(yù)定集合或規(guī)則來選擇包括所述內(nèi)容推遲的情景。
9.如權(quán)利要求7所述的裝置，其中所述處理單元配置成選擇包括所述內(nèi)容推遲的情景，如果滿足以下條件中的至少一個的話: 所述內(nèi)容的大小超過預(yù)定大小閾值， 包括移動小區(qū)負(fù)載的當(dāng)前網(wǎng)絡(luò)負(fù)載超過預(yù)定網(wǎng)絡(luò)負(fù)載閾值，以及 當(dāng)前時間與網(wǎng)絡(luò)使用高時一天中的時期相對應(yīng)。
10.如權(quán)利要求7所述的裝置，其中所述處理單元還配置成接收網(wǎng)絡(luò)負(fù)載分布，并且如果所述網(wǎng)絡(luò)分布指示當(dāng)前網(wǎng)絡(luò)負(fù)載高并且預(yù)期減少，則選擇包括所述內(nèi)容推遲的情景。
11.如權(quán)利要求4所述的裝置，其中如果所述選擇的情景包括所述去除優(yōu)先化，則分配低優(yōu)先級給傳遞所述內(nèi)容。
12.如權(quán)利要求11所述的裝置，其中所述處理單元配置成如果所述內(nèi)容的大小超過預(yù)定大小閾值，則選擇包括所述去除優(yōu)先化的情景。
13.一種用于控制從內(nèi)容源提供商到電信網(wǎng)絡(luò)中的內(nèi)容用戶(UE)的內(nèi)容傳遞的方法(1200)，包括: 接收并存儲(1210)將要從所述內(nèi)容源提供商傳遞給所述內(nèi)容用戶的內(nèi)容； 從多個可能情景中選擇(1220)用于將所述內(nèi)容傳遞給所述內(nèi)容用戶的情景，所述情景根據(jù)包括觀眾放棄率的一個或多個因素來選擇；以及 按照選擇的情景將所述內(nèi)容傳遞(1230)給所述內(nèi)容用戶。
14.如權(quán)利要求13所述的方法，其中所述一個或多個因素還包括以下中的至少一個:(A) —天中的時間、(B)與所述可能情景中的每個情景相關(guān)聯(lián)的UE的電池能量消耗、(C)與所述可能情景中的每個情景相關(guān)聯(lián)的網(wǎng)絡(luò)信令的量、(D)所述內(nèi)容提供商的偏好、(E)所述內(nèi)容用戶的偏好、(F)將被傳遞的所述內(nèi)容的類型，以及(G)當(dāng)前網(wǎng)絡(luò)負(fù)載。
15.如權(quán)利要求13所述的方法，其中 內(nèi)容的所述類型是包括軟件更新、視頻或音頻流傳送、社交網(wǎng)絡(luò)更新、豐富媒體上載以及廣告?zhèn)鬟f的多個類型中的一個，并且 所述多個可能情景中的 一些包括使用一個或多個機制，例如視頻定速、內(nèi)容推遲、去除優(yōu)先化以及TCP加速。
16.如權(quán)利要求15所述的方法，其中 如果內(nèi)容的所述類型是視頻或音頻流傳送，則所述選擇的情景包括視頻定速，并且當(dāng)傳遞所述內(nèi)容時，已經(jīng)被傳遞給所述內(nèi)容用戶的所述內(nèi)容的量超過已經(jīng)由所述內(nèi)容用戶播出的所述內(nèi)容的量， 無線電狀態(tài)包括第一狀態(tài)和第二狀態(tài)，在所述第一狀態(tài)期間所述內(nèi)容用戶以第一數(shù)據(jù)速率接收所述內(nèi)容并且使用第一電池功率，在所述第二狀態(tài)期間所述內(nèi)容用戶以第二數(shù)據(jù)速率接收所述內(nèi)容并且使用第二電池功率，所述第一數(shù)據(jù)速率比所述第二數(shù)據(jù)速率大，所述第一電池功率比所述第二電池功率大，并且 所述內(nèi)容的所述傳遞包括使用所述第一狀態(tài)和所述第二狀態(tài)以便最小化能量消耗。
17.如權(quán)利要求15所述的方法，其中 如果滿足以下條件中的至少一個，則所述情景包括所述內(nèi)容推遲: 所述內(nèi)容的大小超過預(yù)定大小閾值， 當(dāng)前網(wǎng)絡(luò)負(fù)載超過預(yù)定網(wǎng)絡(luò)負(fù)載閾值，以及 當(dāng)前時間與網(wǎng)絡(luò)使用高時一天中的時期相對應(yīng)，以及 網(wǎng)絡(luò)分布指示當(dāng)前網(wǎng)絡(luò)負(fù)載高并且預(yù)期減少，以及 當(dāng)所述選擇的情景包括內(nèi)容推遲時，延遲所述傳遞。
18.如權(quán)利要求15所述的方法，其中如果所述選擇的情景包括所述去除優(yōu)先化，則分配低優(yōu)先級給傳遞所述內(nèi)容。
19.如權(quán)利要求18所述的方法，其中如果所述內(nèi)容的大小超過預(yù)定大小閾值，則所述情景包括所述去除優(yōu)先化。
20.一種計算機可讀媒體(1030)，存儲可執(zhí)行代碼，所述代碼在處理器上被執(zhí)行時，使得所述處理器執(zhí)行用于控制從內(nèi)容源提供商到電信網(wǎng)絡(luò)中的內(nèi)容用戶(UE)的內(nèi)容傳遞的方法(1200)，所述方法(1200)包括； 從多個可能情 景中選擇(1220)用于傳遞所述內(nèi)容的情景，所述情景根據(jù)包括觀眾放棄率的一個或多個因素來選擇；以及 按照選擇的情景將所述內(nèi)容傳遞(1230)給所述內(nèi)容用戶。
【文檔編號】H04L29/08GK104025553SQ201180072313
【公開日】2014年9月3日 申請日期:2011年11月2日 優(yōu)先權(quán)日:2011年7月14日
【發(fā)明者】A.達(dá)莫拉, K.斯范布羅, P.維爾拉斯 申請人:瑞典愛立信有限公司