專利名稱：對無線通信網(wǎng)絡的質(zhì)量體驗(qoe)度量的制作方法
技術領域：
本揭示一般涉及通信網(wǎng)絡，且詳細來說但非排外地，涉及評估終端用戶在一移動無線和/或固線通信環(huán)境中的體驗或質(zhì)量體驗(QoE)的技術。
背景技術：
隨著媒體壓縮及無線網(wǎng)絡基礎結構的改進，媒體流成為終端用戶、內(nèi)容提供者、無線操作者及其它實體的有前途的技術領域。盡管將有更多可用于無線技術的帶寬，諸如2.5G或3G，且盡管某些先進壓縮技術可使非常低位率流成為可能，但對于無線環(huán)境仍存在固有問題。
遇到所述問題的無線流應用的領域包括實時媒體應用(包括音頻和視頻流)、實時音頻應用(諸如現(xiàn)場音樂或體育廣播)、離線媒體應用和離線音頻應用。不同于有線網(wǎng)絡，無線網(wǎng)絡受高有效數(shù)據(jù)包丟失率和間歇數(shù)據(jù)包延遲影響?？捎芍T如網(wǎng)絡阻塞、位錯誤率、或除諸如衰減(其為無線網(wǎng)絡的固有特征)的效應外，在用戶設備處的數(shù)據(jù)溢流的因素而導致數(shù)據(jù)包丟失和延遲。
除了數(shù)據(jù)包丟失外，還存在對終端用戶所接收的媒體產(chǎn)生不利影響的其它因素。任一這些因素對用戶體驗的影響可極大地取決于通信信道條件、用戶設備特征、環(huán)境條件、通信期間出現(xiàn)的有意或無意事件、或其它影響而變化。
所有上述和其它因素最終對終端用戶在媒體傳遞和消耗的情況下的一移動無線通信環(huán)境中的質(zhì)量體驗(QoE)產(chǎn)生不利影響，其中流僅是媒體傳遞的一個實例。這些相同或其它因素還可對終端用戶在一固線通信環(huán)境中的QoE產(chǎn)生影響。

發(fā)明內(nèi)容
一方面提供一種可用于無線通信環(huán)境中的方法。所述方法包括定義指示影響無線通信環(huán)境中的質(zhì)量的一特征的至少一個質(zhì)量體驗(QoE)度量。在客戶端與服務器之間執(zhí)行一協(xié)商，以確定在所述客戶端與所述服務器之間的會話期間使用至少一個QoE度量中的哪個，且所述QoE度量表示為一個接受的QoE度量。在所述會話期間收集一個或多個接受的QoE度量的數(shù)據(jù)，且所述度量數(shù)據(jù)在所述客戶端與所述服務器之間傳送。


參考下圖而描述非限制性和非詳盡的實施例，其中在各種視圖中，除非另有指定，否則相同的參考數(shù)字指相同的部件。
圖1是說明QoE架構組件和其根據(jù)一個實施例的操作的功能方框圖。
圖2說明了QoE協(xié)商的第一實施例。
圖3說明了QoE協(xié)商的第二實施例。
圖4是一更詳細展示的用于圖1的QoE架構的QoE模塊的實施例的方框圖。
具體實施例方式
在以下描述中，給定許多特定細節(jié)以提供對實施例的徹底理解。然而所屬領域的相關技術人員將認識到，本發(fā)明可脫離一個或多個特定細節(jié)或使用其它方法、組件、材料等實施。在其它實例中，未展示或詳細描述眾所周知的結構、材料或操作以避免使本發(fā)明的方面模糊不清。
整個此說明書的參考“一個實施例”指結合實施例而描述的特定特點、結構或特征包括在至少一個實施例中。因此，短語“在一實施例中”在整個此說明書中的出現(xiàn)不必都指相同的實施例。此外，在一個或多個實施例中，可以任何適當?shù)姆绞浇M合所述特定特點、結構或特征。
除非本文另有規(guī)定，整個此說明書和隨后的申請專利范圍，詞語“包含(comprise)”和其變化，諸如“包含(comprises)”和“包含(comprising)”可理解為一開放的包括意義，即“包括，但不限于”。
本文提供的標題僅出于便利目的，且不解釋申請專利發(fā)明的范疇或涵義。
作為一概述，QoE架構的一個實施例提供一種技術以監(jiān)控并解決在網(wǎng)絡組件之間的通信期間可能出現(xiàn)的QoE問題。舉例而言，當將媒體從服務器傳送到客戶端時，可能存在可在一服務器與一客戶端(例如終端用戶設備)之間的通信期間出現(xiàn)的QoE問題。一個實施例的QoE架構的組件包括起始和終止過程，其分別定義一個會話的開始和結束；一協(xié)商過程，其中服務器和客戶端協(xié)商在會話期間使用哪個度量；一個或多個度量，其被定義和實施(例如度量值的收集/測量)；度量值的會話期間的傳輸，所述度量值與以一預定頻率的度量相關且用于在協(xié)商期間接受的所有會話的預定范圍；和對所述度量值的分析/應用以評估QoE和調(diào)整條件，使得如果需要，可改進所述QoE。
本文將描述在無線通信網(wǎng)絡中的QoE架構的情況下的各種實施例。應了解本發(fā)明不限于無線環(huán)境。QoE架構的實施例可應用于固線通信網(wǎng)絡(包括同時包含固線和無線元件的通信網(wǎng)絡)或可體驗QoE問題的任何其它網(wǎng)絡。
僅出于說明和解釋的原因，本文使用標準和/或協(xié)議特定的術語、過程、格式或其它協(xié)議特定的實施例來描述各種實施例。舉例而言，關于會話描述協(xié)議(SDP)、實時流協(xié)議(RTSP)和其它標準/協(xié)議來描述某些實施例。這些特定描述的實施例不期望限制本發(fā)明。相反，所述標準/協(xié)議特定的描述僅用期望當結合眾所周知的標準/協(xié)議而實施時，協(xié)助讀者(或一所屬領域的技術人員)理解某些實例實施例的操作和特點。通過本文這些特定描述，所屬領域的技術人員能獲得與對于其它標準/協(xié)議(當前存在或未來將開發(fā))或?qū)τ诔霈F(xiàn)QoE問題的其它應用來說如何制作和使用本發(fā)明的其它實施例相關的知識。
一個所述特定但非限制的QoE架構的實例實施例通過向其提供標準的兼容擴充而平衡諸如SDP(參閱例如RFC 2327SDPSession Description Protocol，Handley M.和Jacobson V.，1998年4月)[2]和RTSP(參閱例如RFC 2326Real Time Streaming Protocol(RTSP)，Schulzrinne H.，Rao A.和Lanphier R.，1998年4月)[3]的現(xiàn)有流描述和控制協(xié)議。一實施例還允許併入現(xiàn)有的基于標準的報告機制，諸如RTCP(參閱例如RFC 3550RTPA Transport Protocol for Real-Time Applications，Schulzrinne H.等人，2003年7月)[4]和RTCP XR(參閱例如RFC 3611RTP Control Protocol Extended Reports(RTCP XR))，T.Friedman等人，2003年11月)[5]。指派到每個這些參考的方括號[]中的數(shù)字將隨后在整個此說明書中用作一簡略技術以指代這些參考。
QoE架構的一實施例還定義一組QoE參數(shù)(度量)，諸如損壞持續(xù)時間、再緩沖持續(xù)時間、起始緩沖持續(xù)時間、連續(xù)丟失、幀速率偏差和/或抖動持續(xù)時間。這些或其它適當定義的度量可單獨地或在任何實踐組合中使用。
圖1展示了根據(jù)一實施例的QoE架構中所包含的組件的圖表。展示了以QoE和質(zhì)量服務(QoS)協(xié)議的方式彼此通信的服務器100和客戶端102。一適當?shù)窍拗频乃隹蛻舳?02的實例是支持QoE協(xié)議的任何兼容3GPP版本6的手持機/播放器，且最小組的經(jīng)定義的度量(例如在S4-040308工作草案26234-050，3GPP TSG-SA4會議#31，Montreal，Canada，2004年5月17-21日中定義的)[1]可與所述服務器100或網(wǎng)絡組件通信?？蛻舳?02的實施例包括QoE客戶端模塊118，其將隨后在下文中進一步詳細描述。
服務器100的實施例將併入一動態(tài)帶寬調(diào)節(jié)(DBA)模塊104、一質(zhì)量服務(QoS)模塊106和一QoE服務器模塊108。所述QoS模塊106平衡協(xié)商的最大位率、保證位率和所述客戶端102與所述網(wǎng)絡間的最大傳輸延遲參數(shù)。其還平衡任何其它網(wǎng)絡層數(shù)據(jù)，諸如丟失、延遲和其它。在2003年5月30日提交的題為“METHOD AND APPARATUS FORDYNAMIC BANDWIDTH ADAPTATION”的美國申請案第10/452,035號中進一步詳細描述所述DBA模塊104的實例實施例，其轉(zhuǎn)讓給相同受讓人作為本申請案且其全文以引用的方式併入本文。
所有這些模塊共同確保用戶體驗如同期望的那樣，且在整個流會話過程中甚至在劇烈變化的網(wǎng)絡條件下被監(jiān)控。一服務提供者/操作者110向一系統(tǒng)監(jiān)控模塊112、向一帳務處理模塊114(假定手持機已被驗證)或向任何其它模塊饋入QoE服務器模塊108輸出。一個實施例的QoE服務器模塊108可經(jīng)定制以滿足插入其中的組件的需要，且可提供QoE度量和QoS參數(shù)的統(tǒng)計分析。
當所述實施例的QoE服務器模塊108展示為駐存在服務器100中時，應了解，所述QoE模塊(或任何其它模塊)可適當?shù)匚挥跓o線或固線網(wǎng)絡中的其它地方。舉例而言，所述QoE服務器模塊108可位于一代理設備、路由器、交換機或其它網(wǎng)絡組件，包括在某些實施例中的客戶端102處。
QoE架構特點之一是向服務提供者110提供一評估終端用戶體驗的構件。一個實施例的QoE架構可用于帳務處理或手持機/播放器檢測的目的。這個用途可被加強，其限制條件為可基本上確保受信任的度量反饋。
如下組織以下描述。部分I描述QOE協(xié)議方面。部分II描述QOE度量方面。部分III描述QOE服務器模塊方面。部分IV描述QOE客戶端模塊方面。
I.QoE協(xié)議在一特定但非限制的實施例中，基于RTSP和SDP的協(xié)議擴充用于在(例如)數(shù)據(jù)包交換流服務客戶端(PSS)102與PSS服務器100之間的QoE度量的傳輸和協(xié)商。當然，所述QoE度量的傳輸和協(xié)商可使用對于RTSP和SDP是替代的或是額外的其它機制。圖1中描述了一QoE協(xié)議116的協(xié)商和傳輸過程的一實例實施例。
如果度量信息嵌入在SDP數(shù)據(jù)中，那么QoE度量協(xié)商以對從客戶端102發(fā)送的DESCRIBE請求響應開始。對于本機存儲的含有QoE度量屬性的SDP的情況，所述協(xié)商以客戶端102的SETUP請求開始。如果PSS客戶端102支持QoE度量，那么所述客戶端102為正在建立的會話階層或媒體階層發(fā)送一含有選定(即被所述客戶端102接受的)/修改(用于再協(xié)商)的QoE度量的SETUP請求。
在接收此SETUP請求后，服務器100返回具有“接受的”QoE度量(即等同于客戶端102的請求中的度量和度量值且被服務器100接受的度量和度量值)和“再協(xié)商”QoE度量(即不等同于客戶端102的請求中的度量和度量值且由服務器100修改用于再協(xié)商的度量和度量值)的RTSP響應。所述“接受的”QoE度量的回復是為再次確認所述客戶端102。服務器100還可拒絕由客戶端102作出的改變(即拒絕“再協(xié)商”QoE度量)。如果服務器100拒絕所述改變，那么服務器100設定新值并將修改的度量再發(fā)送回客戶端102，或服務器100忽略所述“再協(xié)商”度量且不對其再次確認。任何被服務器100確認為“接受的”QoE度量不再協(xié)商(即，其無需在下一RTSP請求中的“3GPP-QoE-Metrics”標頭中被再次發(fā)送，且無需在下一RTSP響應中被再次確認)。
如果服務器100不認可由客戶端102完成的修改，那么服務器100和客戶端102繼續(xù)再協(xié)商直到RTSP PLAY請求和服務器100回復RTSP PLAY響應中的“接受的”QoE度量?？蛻舳?02可通過提出一RTSP PLAY請求而終止協(xié)商過程。應注意，每次在一RTSP請求中發(fā)送“QoE度量”標頭字段，其還存在于對應于那個特定請求的響應中。另外，響應的接收者假定其它終端不支持QoE度量。
如果在RTSP信令傳輸開始時沒有發(fā)送DESCRIBE-RTSP響應對(例如，請參閱圖2)，那么表示通過其它構件接收SDP描述。如果所述SDP含有“3GPP-QoE-Metrics”屬性，那么以與上文所述的方式相同的方式發(fā)生協(xié)商(即，以含有“3GPP-QoE-Metrics”標頭的SETUP請求開始)。如果所述SDP不含有所述“3GPP-QoE-Metrics”屬性且服務器100仍要檢查客戶端102是否支持QoE協(xié)議，那么所述服務器100包括在SETUP響應中含有起始QoE度量的“3GPP-QoE-Metrics”標頭。如果PSS客戶端102在下一請求中發(fā)送QoE度量信息(指示其支持QoE協(xié)議)，那么協(xié)商繼續(xù)直到達成相互認同或提出RTSP PLAY請求和響應消息對。如果客戶端102不在下一請求中向SETUP響應發(fā)送QoE度量信息，那么服務器100假定客戶端102不支持QoE度量。
因為性能和復雜性的原因，流期間的QoE度量協(xié)商不需在一實施例中完成。然而有可能在流會話期間關閉所述度量。舉例而言，所述度量可在會話階層或媒體階層被設定為“Off”。請求統(tǒng)一資源定位器(URL)指示使用哪個階層。如果不使用URL，那么“Off”應用于會話階層。服務器100可使用OPTIONS(具有會話ID)或SET_PARAMETER RTSP方法來關閉QoE反饋。
客戶端102在RTSP準備狀態(tài)期間不發(fā)送QoE反饋。在準備狀態(tài)結束后(即，RTSP狀態(tài)＝播放)，周期性反饋和正常操作會繼續(xù)。此減少在上行鏈路和下行鏈路方向上的網(wǎng)絡負載，和用于PSS客戶端102的處理開支。當由PSS客戶端102在一PAUSE后發(fā)送一RTSPPLAY請求時，重設用于(基于定義的“發(fā)送率”)測量報告周期的時鐘。
如果存在多個非集中會話(即，由一不同的PLAY請求起始每個媒體傳遞)，那么對于每個會話而言，單獨協(xié)商并報告QoE度量。
再者，應強調(diào)上述(且還大體上在下文部分I.A-I.F中接著描述)特定和主要實施的QoE協(xié)議的部分的實施例僅出于說明目的且不期望限制本發(fā)明。可如下總結協(xié)議的更一般描述在服務器100與客戶端102之間起始一會話；服務器100和客戶端102中的一者或兩者可或不可支持某些度量；同樣，客戶端102可選擇包括其支持一特定會話的度量的一子組；客戶端102和服務器100因此參與一協(xié)商過程，其可包含若干來回交換，以確定由客戶端102支持和應發(fā)送的度量，應發(fā)送支持/接受的度量的頻率，如何啟用和/或停用度量，接受的度量要包含的內(nèi)容或值，和其它與度量相關的因素；由客戶端102進行的對度量值的測量和收集；將度量值從客戶端102傳輸?shù)椒掌?00；和會話的終止?？稍u估傳輸?shù)亩攘恐狄源_定在流會話期間和/或隨后的會話是否能或應改進QoE。隨后描述在所定義的標準的情況下的QoE協(xié)議的起始/終止、協(xié)商和傳輸(反饋)特點的實施例的更詳細且非限制性描述。
A.起始/終止RTSP在一說明性且非限制性實施例中，定義一新的RTSP標頭以使PSS客戶端102和服務器100能夠協(xié)商PSS客戶端102應發(fā)送哪個質(zhì)量體驗(QoE)度量、應發(fā)送所述度量的頻率和如何關閉度量傳輸。例如在一RTSP實施中，此標頭可存在于RTSP方法SETUP、SET_PARAMETER、OPTIONS(具有會話ID)和PLAY的請求和響應中。在非RTSP實施中，可使用其它構件傳輸標頭或標頭中的數(shù)據(jù)。在ABNF[3]中定義實例標頭如下QoE-Header="3GPP-QoE-Metrics"":"("Off"/Measure-Spec*(","Measure-Spec))CRLFMeasure-Spec=Stream-URL";"((Metrics";"Sending-rate[";"Measure-Range]*([";"Parameter_Ext]))/"Off")Stream-URL="url""="<">Rtsp_URL<">
Metrics="metrics""=""{"Metrics-Name*(","Metrics-Name)"}"Metrics-Name=1*((0x21..0x2b)/(0x2d..0x3a)/(0x3c..0x7a)/0x7c/0x7e);VCHARexcept";",",","{"or"}"Sending-Rate="rate""="1*DIGIT/"End"Measure-Range="range""="Ranges-SpecifierParameter_Ext="On"/"Off"/(1*DIGIT["."1*DIGIT])/(1*((0x21..0x2b)/(0x2d..0x3a)/(0x3c..0x7a)/0x7c/0x7e))Ranges-Specifier=如RFC 2326中所定義Rtsp_URL=如RFC 2326中所定義有兩種方式使用此標頭用于此特定非限制性實施例——所述標頭可以其它方式用于其它實施例-僅使用“Off”參數(shù)是服務器100或客戶端102希望取消度量報告的指示。
-使用其它參數(shù)指示開始度量傳輸?shù)恼埱蟆?br> 如果“Stream-URL”是一RTSP會話控制URL，那么“Metrics”應用于RTSP會話。如果“Stream-URL”是一RTSP媒體控制URL，那么“Metrics”僅應用于會話的所指示的媒體組件。
具有相同“Stream-URL”、“Sending-rate”和“Measure-Range”的QoE度量集中在單個“Measure-Spec”聲明中。另外，使用多個“Stream-URL”聲明。
“Metrics”字段含有描述將在PSS會話中報告的度量/測量的名稱清單。所述“Metrics”字段中未包括的名稱不在所述會話期間報告。
“Sending-Rate”被設定，且以秒表示兩個連續(xù)QoE報告之間的最大周期。如果所述“Sending-Rate”值為0，那么客戶端102依據(jù)客戶端102中出現(xiàn)的事件而決定報告的發(fā)送時間。值≥1指示精確的報告間隔。最小間隔為一秒且最長間隔未被定義。所述報告間隔對于不同媒體可不同，但可維持一同步程度以避免在上行鏈路方向上的額外流量。值“End”指示在會話結束時僅發(fā)送一個報告。
可選的“Measure-Range”字段(如果使用)定義流中的時間范圍，其中向所述流報告QoE度量。在一實例實施例中，每個測量規(guī)格僅有一范圍。范圍格式可為媒體允許的任何格式。如果所述“Measure-Range”字段不存在，那么使用SDP中的對應的(媒體或會話階層)范圍屬性。如果SDP信息不存在，那么度量范圍為整個會話持續(xù)時間。在一實施例中，在RTSP請求或響應中僅有一個“3GPP-QoE-Metrics”標頭。
B.傳輸/反饋RTSP在一實施例中，可由“3GPP-QoE-Feedback”標頭使用SET_PARAMETER、PAUSE或TEARDOWN方法輸送QoE度量反饋以響應PSS服務器100的請求。在ABNF[3]中定義標頭的一可能實例如下Feedbackheader="3GPP-QoE-Feedback"":"Feedback-Spec*(","Feedback-Spec)CRLFFeedback-Spec=Stream-URL 1*(";"Parameters)[";"Measure-Range]Stream-URL=如[1]中所指定Parameters=Metrics-Name"=""{"SP/(Measure*(","Measure))"}"Metrics-Name=如[1]中所指定Measure=值[SP Timestamp]
Measure-Range=如[1]中所定義Value=(1*DIGIT["."*DIGIT])/1*((0x21..0x2b)/(0x2d..0x3a)/(0x3c..0x7a)/0x7c/0x7e);VCHAR except";",",","{"or"}"Timestamp=NPT-TimeNPT-Time=如RFC 2326中所定義“Stream-URL”為RTSP會話或識別應用反饋參數(shù)的媒體的媒體控制URL。
“Parameters”定義中的“Metrics-Name”字段含有度量/測量的名稱，且將相同的標識符用作“3GPP-QoE-Metrics”標頭。
“Value”字段指示結果。有可能在一監(jiān)控周期期間相同事件出現(xiàn)了多次。在那種情況下，度量值可出現(xiàn)多次以向服務器100指示事件數(shù)。
可選的“Timestamp”(在NPT時間中定義)指示當事件出現(xiàn)或當計算度量時的時間。如果無事件出現(xiàn)，那么報告一空組(僅含有一空格)。
可選的“Measure-Range”指示此報告有效的實際的報告周期。
由PSS客戶端102通過使用(例如)SET_PARAMETER方法而完成QoE度量報告。然而，為了更有效率，在特定情況下還可使用RTSP PAUSE和TEARDOWN方法，諸如情況1當發(fā)送最后的QoE報告時，客戶端102將QoE信息嵌入一TEARDOWN消息中。
情況2當客戶端102希望暫停流流動時，QoE信息應嵌入一PAUSE方法中。當系統(tǒng)暫停時，由于沒有媒體流，所以PSS客戶端102不應向PSS服務器100發(fā)送任何QoE報告。
C.起始/終止SDP在一實施例中，SDP可用于起始QoE協(xié)商。使用SDP的原因是為了支持通過除RTSPDESCRIBE以外的其它方法(例如WAP、HTTP或email)分配SDP的使用情況。下文基于RFC 2327在ABNF中定義了可在會話或媒體階層使用的新實例SDP屬性QoE-Metrics-line="a""=""3GPP-QoE-Metrics:"att_measure_spec*(","att-measure-spec))CRLFatt-measure-spec=Metrics";"Sending-rate[";"Measure-Range]*([";"Parameter_Ext])Metrics=如[1]中所定義Sending-Rate=如[1]中所定義Measure-Range=如[1]中所定義Parameter_Ext=如[1]中所定義服務器100使用此屬性以指示QoE度量被支持且如果還由客戶端102支持就被使用。
當在會話階層存在時，其僅含有應用到完整會話的度量。當在媒體階層存在時，其僅含有可應用到個別媒體的度量。RTSP控制URI(a＝控制)暗含RTSP標頭“3GPP-QoE-Metrics”規(guī)格中使用的URI。
D.起始/終止SDP(實例)以下非限制性實例展示了QoE度量的SDP屬性的語法。監(jiān)控會話階層QoE度量描述(起始緩沖持續(xù)時間和再緩沖)，且在會話結束時報告一次。而且，監(jiān)控度量的視頻特定描述(損壞和解碼字節(jié))，且從流開始直到(例如)40s的時間每15秒報告一次，但此定時在不同實施例中可適當變化。監(jiān)控度量的音頻特定描述(損壞)，且例如自開始直至流結束每20秒報告一次。
實例1Server->ClientRTSP/1.0200OKCseq:1Content-Type:application/sdpContent-Base:rtsp://example.com/foo/bar/baz.3gp/Content-Length:800Server:PSSR6 Serverv=0o=-3268077682 433392265 IN IP4 63.108.142.6s=QoE Enables Session Description Examplee=support@foo.comc=IN IP4 0.0.0.0t=00a=range:npt=0-83.660000a=3GPP-QoE-Metrics:{Initial_Buffering_Duration,Rebuffering_Duration};rate=Enda=control:*m=video 0 RTP/AVP 96b=AS:28a=3GPP-QoE-Metrics:{Corruption_Duration,Decoded_Bytes};rate=15;range:npt=0-40a=control:trackID=3a=rtpmap:96 MP4V-ES/1000a=range:npt=0-83.666000a=fmtp:96profile-level-id=8;config=000001b008000001b50900012000m=audio 0 RTP/AVP 98b=AS:13a=3GPP-QoE-Metrics:{Corruption_Duration};rate=20a=control:trackID=5a=rtpmap:98AMR/8000a=range:npt=0-83.660000a=fmtp:98octet-align=1a=maxptime:200E.起始/終止RTSP(實例)在圖2的實例中，展示了如何在RTSP會話建立期間協(xié)商QoE度量。在協(xié)商后，客戶端102可向服務器100提供測量/收集的接收的度量值作為反饋。Client->Server SETUP rtsp://example.com/foo/bar/baz.3gp/trackID=3RTSP/1.0Cseq:23GPP-QoE-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";
metrics={Corruption_Duration,Decoded_Bytes};rate=10;Range:npt=0-40,url="rtsp://example.com/foo/bar/baz.3gp";
metrics={Initial_Buffering_Duration,Rebuffering_Duration];rate=End在上文實例SETUP請求中，客戶端102將控制URL"rtsp://example.com/foo/bar/baz.3gp/tracklD=3"的QoE度量的發(fā)送率從15修改成10(與起始的SDP描述相比)。假定服務器100確認所述改變，服務器100將如下發(fā)送回一SETUP響應Server->Client RTSP/1.0200 OKCseq:2Session:17903320Transport:RTP/AVP;unicast;client_port=7000-7001;server_port=6970-69713GPP-QoE-Metrics:url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";
metrics={Corruption_Duration,Decoded_Bytes};rate=10;Range:npt=0-40,url="rtsp://example.com/foo/bar/baz.3gp";
metrics={Initial_Buffering_Duration,Rebuffering_Duration};rate=End圖3展示了當不存在DESCRIBE-200/OK時的實例QoE度量協(xié)商。
在下文實例中，(對于所有媒體)在會話階層關閉度量Client->Server,Server->Client SET_PARAMETERrtsp://example.corn/foo/bar/baz.3gpRTSP/1.0
Cseq:302Session:179033203GPP-QoE-Metrics:OffContent-length:0設定所述度量的實例響應為Server->Client,Client->Server RTSP/1.0200 OKCseq:302Session:179033203GPP-QoE-Metrics:OffF.傳輸/反饋RTSP(實例)度量反饋(包含度量值/數(shù)據(jù))可使用任何合適的通信技術從客戶端102傳輸或另外輸送到服務器100。一可能的且非限制性技術是使用SET_PARAMETER方法向服務器100輸送反饋。以下實例展示了在監(jiān)控時間期間出現(xiàn)兩個(2)損壞周期。每個值指示每個損壞周期的持續(xù)時間(以毫秒計)。
實例5(反饋)Client->Server SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0Cseq:302Session:179033203GPP-QoE-Feedback:
url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";Corruption_Duration={200 1300}Content-length:0以下實例展示了在監(jiān)控時間期間出現(xiàn)兩個(2)損壞周期。每個值對指示每個損壞周期的持續(xù)時間(以毫秒計)和損壞的時間標記(例如，第一損壞出現(xiàn)在12秒時且持續(xù)200毫秒)。
實例6(具有時間標記和范圍的反饋)Client->Server SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0Cseq:302Session:179033203GPP-QoE-Feedback:url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";
Corruption_Duration={200 12，1300 16};Range:npt=10-20Content-length:0在以下實例中沒有報告事件。
實例7(無事件的反饋)Client->Server SET_PARAMETER rtsp://example.com/foo/bar/baz.3gp RTSP/1.0Cseq:302Session:179033203GPP-QoE-Feedback:
url="rtsp://example.com/foo/bar/baz.3gp/trackID=3";Corruption_Duration={}Content-length:0II.QoE度量在一實施例中，PSS客戶端102在傳輸層測量度量，但為了更好的精確度還可在應用程序?qū)訙y量。度量的報告周期是計算一組度量的周期。報告周期的最大值經(jīng)由QoE協(xié)議而協(xié)商。報告周期不包括影響實際播放的任何有意事件，諸如暫?；虻罐D(zhuǎn)，或由其引起的任何緩沖或停滯/間隙。在其它實施例中，可通過對于客戶端102是替代或額外的組件測量一個或多個度量，且接著輸送到服務器100和/或客戶端102。
在一實施例中，至少某些度量指示影響通信環(huán)境質(zhì)量的特征，或是通信信道的某些其它指示或結果?？稍诳蛻舳?02的協(xié)議堆棧、客戶端102的應用程序、客戶端102的緩沖器、客戶端102的編碼解碼器或與QoE或任何上述組合相關的其它客戶端特征中測量所述QoE度量。所述度量可用于調(diào)整服務器100和/或客戶端102處的這些層中任何層的行為。
可通過PSS客戶端102實施QoE而得到以下實例度量。應理解，這些度量不僅僅是可用于QoE目的的度量?？捎闷渌攘垦a充這些度量，由其它度量替代、修改、組合等。本文描述以下度量以提供對本發(fā)明的實施例的操作和特點的更好的了解。
下文定義的所有度量可應用于音頻、視頻、語音和定時的文字媒體類型中的至少一者，且不需應用于其它媒體類型，諸如合成音頻、靜止影像、位形、向量圖形和文字。然而應了解，對于這些其它媒體類型可提供其它度量。在一實施例中，客戶端102可忽略任何未知的度量且其不包括在任何QoE報告中。
A.損壞持續(xù)時間度量損壞持續(xù)時間M是從損壞前最后良好幀的NPT時間到第一個后續(xù)的良好幀的NPT時間或報告周期結束(無論哪個在前)之間的周期。一損壞的幀可為一完全丟失的幀或一質(zhì)量降級的媒體幀，且解碼的幀和無錯誤的解碼不同。一良好的幀為一“完全接收的”幀X
-其是一更新的幀(不參考任何先前解碼的幀且隨后接收的幀不參考先于X解碼的任何幀)；-或不參考任何先前解碼的幀；-或參考先前解碼的“良好幀”。
“完全接收”指接收所有位且未出現(xiàn)位錯誤。
在一實施例中，可如下計算以毫秒計的損壞持續(xù)時間Ma)可由客戶端102使用編碼解碼層獲得M，在這種情況下編碼解碼層向客戶端102發(fā)送一良好幀的解碼。還可通過錯誤跟蹤方法獲得一良好幀，但解碼質(zhì)量評估方法不用于一個實施例中而可用于另一實施例中。
b)在不存在來自編碼解碼層的信息的情況下，從損壞前的最后的幀的NPT時間和N獲得M，其中N視情況從服務器100向客戶端102發(fā)送信號，且以毫秒計表示兩個后續(xù)更新幀之間的最大持續(xù)時間。
c)當不存在來自編碼解碼層的信息且如果未發(fā)送N的情況下，那么M默認為∞(對于視頻)或為一幀持續(xù)時間(對于音頻)，或報告周期的結束(無論哪個在前)。
如在點b中定義的可選參數(shù)N與“Corruption_Duration”參數(shù)一起用于“3GPP-QoE-Metrics”標頭中。定義另一可選參數(shù)T以指示客戶端102是否使用錯誤跟蹤。T的值是由客戶端設定的。用于N和T的可包括于“Measure-Spec”([1]的子句5.3.2.3.1)的實例和非限制性語法如下N="N""="1*DIGITT="T""=""On"/"Off"用于QoE反饋標頭的“Metrics-Name Corruption_Duration”的一實例和非限制性語法如[1]的子句5.3.2.3.2中所定義。
可使用空格(SP)報告一事件不存在。
對于“Metrics-Name Corruption_Duration”，子句5.3.2.3.2中的“Value”字段指示損壞持續(xù)時間。此度量的單位以毫秒表達。有可能損壞在一報告周期期間出現(xiàn)多次。在那種情況下，值可出現(xiàn)多次以指示損壞事件數(shù)。
相對于報告周期的開始時間，在報告周期內(nèi)，以回放次序，在損壞出現(xiàn)前，″Timestamp″值等于最后良好幀的NPT時間。如果在報告周期內(nèi)且在損壞前沒有良好幀，那么所述時間標記被設定成報告周期的開始時間。
B.再緩沖持續(xù)時間度量再緩沖被定義為歸因于客戶端一側的任何無意事件的回放時間中的任何停止。
用于QoE反饋標頭的“Metrics-Name Rebuffering_Duration”的一實例和非限制性語法如[1]的子句5.3.2.3.2中所定義。
可使用空格(SP)報告一事件不存在。
對于“Metrics-Name Rebuffering_Duration“，子句5.3.2.3.2中的“Value”字段指示再緩沖持續(xù)時間。此度量的單位以秒表達，且可為一分數(shù)值。有可能再緩沖在一監(jiān)控周期期間出現(xiàn)多次。在那種情況下，度量值可出現(xiàn)多次以指示再緩沖事件的數(shù)目。
可選的“Timestamp”指示當再緩沖從報告周期開始出現(xiàn)時的時間。相對于報告周期的開始時間，在報告周期內(nèi)且在再緩沖出現(xiàn)前，“Timestamp”值等于最后播放的幀的NPT時間。如果在報告周期內(nèi)沒有播放的幀，那么所述時間標記設定成報告周期的開始時間。
C.起始的緩沖持續(xù)時間度量起始的緩沖持續(xù)時間是從接收第一RTP數(shù)據(jù)包直到播放開始的時間。
除用于此度量“Measure”中的“Timestamp”未定義外，用于QoE反饋標頭的“Metrics-Name lnitial_Buffering_Duration”的一實例和非限制性語法如子句5.3.2.3.2中所定義。如果報告周期比“l(fā)nitial_Buffering_Duration”短，那么客戶端只要觀察到，應在每個報告周期發(fā)送此參數(shù)。“Value”字段指示起始的緩沖持續(xù)時間，其中此度量的單位以秒表達，且可為一分數(shù)值。僅可有一個“Measure”且其僅可具有一個“Value”?？墒褂每崭?SP)報告一事件不存在?！發(fā)nitial_Buffering_Duration”是一個會話階層參數(shù)。
D.RTP數(shù)據(jù)包的連續(xù)丟失此參數(shù)指示每個媒體信道的RTP數(shù)據(jù)包連續(xù)丟失的數(shù)目。
用于QoE反饋標頭的“Metrics-Name Successive_Loss″”的一實例和非限制性語法如子句5.3.2.3.2中所定義。
可使用空格(SP)報告一事件不存在。
對于“Metrics-Name Successive_Loss”，“Value”字段指示RTP數(shù)據(jù)包連續(xù)丟失的數(shù)目。此度量的單位表達為一等于或大于1的整數(shù)。有可能在一報告周期期間出現(xiàn)連續(xù)丟失多次。在那種情況下，度量值可出現(xiàn)多次以指示連續(xù)丟失的數(shù)目。
可選的“Timestamp”指示當連續(xù)丟失數(shù)據(jù)包出現(xiàn)時的時間。相對于報告周期的開始時間，在報告周期內(nèi)，以回放次序，在連續(xù)丟失數(shù)據(jù)包出現(xiàn)前，“Timestamp”值等于最后接收的RTP數(shù)據(jù)包的NPT時間。如果在報告周期內(nèi)且在連續(xù)丟失前沒有接收的RTP數(shù)據(jù)包，那么時間標記被設定成報告周期的開始時間。
如果需要一具有序列數(shù)目信息的RTP丟失的全程程度編碼，那么應使用RTCP XR[5]丟失RLE報告區(qū)塊以替代連續(xù)丟失的度量。
E.幀速率偏差幀速率偏差指示回放幀速率信息。當在一報告周期期間實際的回放幀速率偏離一預定值時發(fā)生幀速率偏差。
實際的回放幀速率等于在報告周期期間所播放的幀的數(shù)目除以以秒計的報告周期的持續(xù)時間。
表示預定幀速率值的參數(shù)FR與“Framerate_Deviation”參數(shù)一起用在“3GPP-QoE-Metrics”標頭中?？捎煞掌?00設定FR的值。用于FR的可包括于“Measure-Spec”([1]的子句5.3.2.3.1)中的一實例和非限制性語法如下FR="FR""="1*DIGIT"·"1*DIGIT除用于此度量“Measure”中的“Timestamp”未定義外，用于QoE反饋標頭的Metrics-Name“Framerate_Deviation”的一實例和非限制性語法如子句5.3.2.3.2中所定義?？墒褂每崭?SP)報告一事件不存在。
對于Metrics-Name“Framerate_Deviation”，“Value”字段指示幀速率偏差值，其等于預定的幀速率減去實際的回放幀速率。此度量可以每秒多少幀表達，且可為一分數(shù)值，且可為負值。在一實例和非限制性實施例中，對于此度量，度量值僅可出現(xiàn)一次。
F.抖動持續(xù)時間當實際的回放時間與期望的回放時間之間的絕對差大于100毫秒的預定值時，發(fā)生抖動。在一個實例實施例中，一幀的期望時間等于最后播放的幀的實際的回放時間加上所述幀的NPT時間與最后播放的幀的NPT時間之間的差。
用于QoE反饋標頭的Metrics-Name“Jitter_Duration”的一實例和非限制性語法如[1]的子句5.3.2.3.2中所定義。
可使用空格(SP)報告一事件不存在。
對于Metrics-Name“Jitter_Duration”，5.3.2.3.2中“Value”字段指示回放抖動的持續(xù)時間。此度量的單位以秒表示，且可為一分數(shù)值。有可能抖動在一監(jiān)控周期期間出現(xiàn)多次。在那種情況下，度量值可出現(xiàn)多次以指示抖動事件的數(shù)目。
可選的“Timestamp”字段指示從報告周期開始抖動出現(xiàn)時的時間。相對于報告周期的開始時間，“Timestamp”值等于回放抖動中的第一個播放的幀的NPT時間。
III.QoE服務器模塊圖4展示了根據(jù)一實施例的服務器100中的QoE服務器模塊108。所述QoE服務器模塊108負責在媒體通信時量化若干因素的影響，包括網(wǎng)絡條件、客戶端特征等。QoE服務器模塊108通過從客戶端102收集反饋而實現(xiàn)。
所述QoE服務器模塊108的各種實施例的特征和特點可描述如下1.所述QoE服務器模塊108可駐存于一流服務器中(例如服務器100)。
2.所述QoE服務器模塊108可駐存于一rtsp代理或任何其它合適的網(wǎng)絡設備中。
3.所述QoE服務器模塊108可接受來自各種協(xié)議412的輸入，所述協(xié)議412諸如○ 通過QoE協(xié)議的QoE度量(如上文和[1]中所解釋)○ RTCP度量[4]○ 3GPP鏈路特征[1]○ RTCP XR[5]4.所述QoE服務器模塊108的配置可存儲于一SDP文件或由服務器/代理產(chǎn)生。圖4中的410展示了實例配置參數(shù)。
5.所述QoE服務器模塊108與DBA模塊104交互○ 影響決定以基于統(tǒng)計的QoE結果而增加位率○ 影響決定以基于主觀的QoE結果而增加位率○ 影響決定以基于統(tǒng)計的QoE結果而減少位率○ 影響決定以基于主觀的QoE結果而減少位率○ 以下特征還可基于主觀和/或統(tǒng)計的QoE結果而增加/減少或另外影響/改變幀速率、更新間隔和行為、錯誤彈性、緩沖行為、最大幀大小、峰值位率、片斷、重傳輸和/或其它特征。
○ 如果開啟DBA模塊104■ QoE可影響速率調(diào)節(jié)(可配置).
■ 在一實施例中，通過DBA模塊104控制報告。
○ 如果關閉DBA模塊104■ 在一實施例中，QoE服務器108不影響速率調(diào)節(jié)，但可在另一實施例中影響速率調(diào)節(jié)。
■ 在一實施例中，由QoE服務器108控制報告，而在另一實施例中由其它模塊或組件控制。
○ 在一實施例中，如果關閉DBA和QoE模塊104和108，那么由QoS模塊106控制報告。
6.所述QoE服務器模塊108可以下列模式中的一者或兩者而操作○ 統(tǒng)計模式○ 主觀模式○ 詳細內(nèi)容可以許多方式在所述QoE服務器模塊108中組織使用從客戶端102傳回到服務器100的度量。一種方式是“統(tǒng)計模式”。此處，所述QoE服務器模塊108以最小值、最大值等的形式組織度量的統(tǒng)計。第二方式是“主觀模式”。此處，QoE服務器模塊108通過將度量映射到一質(zhì)量服務類別以組織其接收的度量。因此，(例如)，在觀察度量后，QoE服務器模塊108可確定一特定度量屬于MEDIUM質(zhì)量類別。同樣，此信息可用于確認的目的。舉例而言，如果客戶端102屬于一HIGH質(zhì)量類別，但對于基于服務器100接收的度量的此特定會話，其確定此會話僅屬于MEDIUM質(zhì)量類別，那么所述信息可用于許多目的?？赡軡撛诖嬖谠S多對QoE服務器模塊108接收的度量的其它分析。
7.QoE統(tǒng)計模式○ 在媒體或會話階層計算○ 在單個周期或整個會話測量○ 計算最小值、最大值、平均值和至少以下標準偏差■ 損壞持續(xù)時間(如上文和[1]中所解釋)■ 再緩沖持續(xù)時間(如上文和[1]中所解釋)■ 起始緩沖持續(xù)時間(如上文和[1]中所解釋)■ 連續(xù)丟失(如上文和[1]中所解釋)8.QoE主觀模式○ 在媒體或會話階層計算○ 在整個會話測量(無單個周期的報告)○ 提供對預定的QoS類別的映射■ 盡力服務(Best-effort)或流類別，■ 低、中或高QoE類別。
○ 提供對可能的問題位置的隔離■ 鏈路層■ 網(wǎng)絡協(xié)議堆?！? 編碼解碼器堆棧問題■ 客戶端應用程序問題
■ 夾片問題■ 其它9.QoE報告可整合到○ 監(jiān)控系統(tǒng)○ 帳務系統(tǒng)(如果手持機已被驗證)在一實施例中，DBA模塊104、QoS模塊106和QoE服務器模塊108可共同包含報告模塊400的部分?？捎蓄~外的模塊位于服務器100中，諸如一速率交換模塊402。為了簡潔目的，本文將不提供所述額外模塊的詳細描述。
至少某些與QoE相關和上述其它操作可包含在軟件或存儲于一個或多個機器可讀媒體406上的其它機器可讀指令404。所述機器可讀機器媒體406可位于服務器100中、位于客戶端102中和/或位于其它合適的網(wǎng)絡位置中。一個或多個處理器408耦接到存儲媒體406，以允許處理器408執(zhí)行存儲于其上的軟件404。
IV.QoE客戶端模塊一個實施例的QoE客戶端模塊118是基于客戶端102的。
所述QoE客戶端模塊118可基于許多考慮而決定在一會話期間開啟/關閉QoE度量。一個所述考慮為(例如)可阻礙其正常操作的低電池功率。
所述QoE客戶端模塊118在其決定在會話開始時開啟度量后，可在會話中間關閉度量。此決定可受許多原因影響，包括其收集的度量無效性或其它原因。
所述QoE客戶端模塊118可從其支持的度量組中仔細挑選，對于一特定會話支持何種度量。此決定可受計算度量的復雜性、過去的體驗或其它考慮影響。所述度量選擇可用于與服務器100協(xié)商。
所述QoE客戶端模塊118在其同意在會話開始時測量度量后，可在會話中間選擇選擇性關閉某度量。QoE客戶端模塊118還可選擇報告所述度量的頻率。頻率選擇可用于與服務器100協(xié)商。所述QoE客戶端模塊118可選擇應測量度量的會話范圍。范圍選擇可用于與服務器100協(xié)商。一實施例的QoE服務器模塊108和/或QoE客戶端模塊118可在會話期間改變度量清單、度量階層(媒體/會話)、度量頻率和度量范圍。
QoE客戶端模塊118可動態(tài)測量或當解碼或處理從服務器100接收的媒體時另外獲得度量值“on-the-fly”。來自解碼和/或處理循環(huán)的結果可用在度量收集期間。
所述QoE客戶端模塊118可在各階層(例如應用程序、網(wǎng)絡、編碼解碼器或其它)收集數(shù)據(jù)。所述QoE客戶端模塊118可接著共同使用所述數(shù)據(jù)以確定某些度量。
所述QoE客戶端模塊118可區(qū)分與質(zhì)量體驗有關的客戶端102的有意和無意動作。所述QoE客戶端模塊118可維持其測量的度量的完整性。如果所述選擇有效，那么所述QoE客戶端模塊118可選擇傳輸這些度量的方法。
在一實施例中，所述QoE客戶端模塊118可在仍收集度量的同時改變度量的配置(例如度量的頻率和范圍)。度量還可應用于會話階層、流階層媒體(例如音頻、視頻，獨立地或共同地)。
至少某些與QoE相關和上述其它操作可包含在軟件或其它存儲于一個或多個機器可讀媒體406上的機器可讀指令404中。所述機器可讀媒體406可位于服務器100、位于客戶端102和/或位于其它合適的網(wǎng)絡位置處。一個或多個處理器408耦接到存儲媒體406，以允許處理器408執(zhí)行存儲于其上的軟件404。各種組件，諸如位于服務器100和/或客戶端102處的模塊，可包含在軟件(或其它機器可讀指令)、硬件和/或兩者的組合中。
本說明書和/或申請數(shù)據(jù)表中涉及的所有上述美國專利、美國專利申請公告案、美國專利申請案、外國專利、外國專利申請案和非專利申請案，其全文以引用的方式并入本文。
所說明的實施例的以上描述，包括摘要中所述，并非希望詳盡化或?qū)⒈景l(fā)明限于所揭示的精確形式。當本文出于說明目的而描述特定實施例和實例時，在本發(fā)明的范疇內(nèi)可具有各種等同的修改，且可在不偏離本發(fā)明的精神和范疇的情況下而制作。
舉例而言，當本文在某些特定通信協(xié)議、標準、格式、語法等的情況下描述各種實施例時，對于其它類型的通信協(xié)議、標準、格式、語法等可提供其它實施例。本發(fā)明不限制于本文描述的特定通信協(xié)議、標準、格式、語法等。實施例不僅應用于音頻和視頻媒體流，且可應用于其它形式的媒體的傳遞和消費。
根據(jù)上述詳細描述可對本發(fā)明作這些和其它修改。以上申請專利范圍中使用的術語不應理解為將本發(fā)明限制于說明書和申請專利范圍中所揭示的特定實施例。相反，本發(fā)明的范疇完全由以下申請專利范圍確定，其將根據(jù)申請專利范圍解釋的制定原則而理解。
權利要求
1.一種可用于一通信環(huán)境中的方法，所述方法包含定義至少一個質(zhì)量體驗(QoE)度量，其指示一影響所述通信環(huán)境中的質(zhì)量的特征；在一客戶端與一服務器之間執(zhí)行一協(xié)商以確定在所述客戶端與所述服務器之間的一會話期間將使用所述至少一個QoE度量中的哪個，且將這一QoE度量指定為一接受的QoE度量；在所述會話期間收集一個或多個QoE接受的度量的數(shù)據(jù)；和在所述客戶端與所述服務器之間傳送所述度量數(shù)據(jù)。
2.根據(jù)權利要求1所述的方法，其中定義所述至少一個QoE度量包括定義一影響一無線通信環(huán)境中的質(zhì)量的QoE度量。
3.根據(jù)權利要求1所述的方法，其中定義所述至少一個QoE度量包括定義一影響一固線通信環(huán)境中的質(zhì)量的QoE度量。
4.根據(jù)權利要求1所述的方法，其中在所述會話期間收集一個或多個接受的QoE度量的數(shù)據(jù)包括當所述客戶端設備解碼或處理從所述服務器接收的媒體時，在所述會話期間在所述客戶端設備處動態(tài)地收集所述數(shù)據(jù)。
5.根據(jù)權利要求1所述的方法，其中定義至少一個QoE度量包括定義一個或多個QoE度量損壞持續(xù)時間、再緩沖持續(xù)時間、起始緩沖持續(xù)時間、連續(xù)數(shù)據(jù)包丟失、幀速率偏差和抖動持續(xù)時間。
6.根據(jù)權利要求1所述的方法，其中在所述客戶端與所述服務器之間傳送所述度量數(shù)據(jù)包括將在一個或多個數(shù)據(jù)包中的所述度量數(shù)據(jù)從所述客戶端傳輸?shù)剿龇掌鳌?br> 7.根據(jù)權利要求1所述的方法，其中在所述客戶端與所述服務器之間執(zhí)行所述協(xié)商包括以下任何一者或多者起始所述協(xié)商；確定所述服務器或所述客戶端或其兩者支持哪個度量；在所述協(xié)商期間確認一建議的QoE度量的接收；修改一QoE度量并再協(xié)商所述修改的QoE度量，以確定是否能接受所述修改的QoE度量；接受或拒絕任何起始的或修改的QoE度量；確定在所述會話期間傳送一QoE度量的方式；確定在所述會話期間傳送一QoE度量的頻率；確定一QoE度量的一范圍；確定一QoE度量的一階層；確定一QoE度量的一配置；確定在所述會話期間停用一QoE度量的一方式；確定度量值的參數(shù)；和如果符合某些條件，那么終止所述協(xié)商，包括對最終的一個或多個接受的QoE度量的相互認同。
8.根據(jù)權利要求1所述的方法，其進一步包含評估所述度量數(shù)據(jù)并應用所述度量數(shù)據(jù)。
9.根據(jù)權利要求8所述的方法，其中評估所述度量數(shù)據(jù)包括根據(jù)統(tǒng)計和主觀模式而組織所述度量數(shù)據(jù)。
10.根據(jù)權利要求1所述的方法，其中定義至少一個QoE度量包括定義與所述客戶端的一特征相關聯(lián)的一QoE度量。
11.一種可用于一通信環(huán)境中的系統(tǒng)，所述系統(tǒng)包含用于定義至少一個質(zhì)量體驗(QoE)度量的構件，所述至少一個質(zhì)量體驗度量指示一影響所述通信環(huán)境中的質(zhì)量的特征，所述特征包括一客戶端特征；用于獲得所述QoE度量的數(shù)據(jù)的構件；用于在一客戶端與一網(wǎng)絡設備之間執(zhí)行一協(xié)商以傳送所述度量數(shù)據(jù)的構件；和用于在所述客戶端與所述網(wǎng)絡設備之間傳送所述度量數(shù)據(jù)的構件。
12.根據(jù)權利要求11所述的系統(tǒng)，其中所述通信環(huán)境包括一無線通信環(huán)境。
13.根據(jù)權利要求11所述的系統(tǒng)，其中所述網(wǎng)絡設備包括一服務器。
14.根據(jù)權利要求11所述的系統(tǒng)，其中用于定義至少一個QoE度量的所述構件包括用于定義以下一個或多個QoE度量的構件損壞持續(xù)時間、再緩沖持續(xù)時間、起始緩沖持續(xù)時間、連續(xù)數(shù)據(jù)包丟失、幀速率偏差和抖動持續(xù)時間。
15.根據(jù)權利要求11所述的系統(tǒng)，其中用于執(zhí)行所述協(xié)商的所述構件包括一用于分析所述度量數(shù)據(jù)的QoE模塊構件，其形成一報告模塊構件的部分，所述系統(tǒng)進一步包含一動態(tài)帶寬調(diào)節(jié)(DBA)模塊構件，其形成所述報告模塊構件的部分以用于與所述QoE模塊構件交互，以基于所述度量數(shù)據(jù)而作出與質(zhì)量相關的決定；一質(zhì)量服務(QoS)模塊構件，其形成所述報告模塊構件的部分，以可選地或額外地執(zhí)行對所述QoE構件的報告；和監(jiān)控和帳務模塊構件，其用于與所述報告模塊構件交互以評估所述度量數(shù)據(jù)。
16.根據(jù)權利要求11所述的系統(tǒng)，其進一步包含客戶端側QoE模塊構件以用于以下任何一者或組合基于至少一個考慮而確定在一會話期間是否開啟/關閉QoE度量；在所述會話的一開始時已打開一QoE之后，在所述會話期間關閉所述QoE度量；從一組QoE度量選擇在特定會話期間支持哪幾個QoE度量；選擇報告度量數(shù)據(jù)的一頻率；選擇待測量所述QoE度量的一會話的一范圍；選擇一QoE度量的一階層，包括媒體和會話階層；當解碼或處理從所述網(wǎng)絡設備接收的媒體時，動態(tài)獲得度量數(shù)據(jù)；獲得處于各階層的度量數(shù)據(jù)，包括應用、網(wǎng)絡和編碼解碼階層；區(qū)分對QoE有一影響的所述客戶端的有意和無意的動作；維持已獲得的所述QoE度量的一完整性；選擇一用于傳輸度量數(shù)據(jù)的構件；和改變所述QoE度量的一配置，同時仍收集其數(shù)據(jù)。
17.一種可用于一無線通信環(huán)境中的制造物品，所述制造物品包含一其上存儲有指令的機器可讀媒體，可由一處理器執(zhí)行所述指令以定義至少一個質(zhì)量體驗(QoE)度量，其指示與所述通信環(huán)境相關聯(lián)的一特征，所述特征包括一客戶端特征；在一客戶端與一服務器之間執(zhí)行一協(xié)商，以確定在所述客戶端與所述服務器之間的一會話期間使用所述至少一個QoE度量中的哪個，且將所述QoE度量表示成一接受的QoE度量；和在所述會話期間獲得一個或多個接受的QoE度量相關數(shù)據(jù)。
18.根據(jù)權利要求17所述的制造物品，其中獲得所述度量數(shù)據(jù)的所述指令包括將所述度量數(shù)據(jù)接收作為從所述客戶端設備傳送的數(shù)據(jù)包的部分的指令。
19.根據(jù)權利要求17所述的制造物品，其中所述機器可讀媒體位于所述服務器處。
20.根據(jù)權利要求17所述的制造物品，其中執(zhí)行所述協(xié)商的所述指令包括執(zhí)行以下任何一者或多者的指令起始所述協(xié)商；確定所述服務器或所述客戶端或其兩者支持哪個QoE度量；在所述協(xié)商期間確認一建議的QoE度量的接收；修改一QoE度量并再協(xié)商所述修改的QoE度量以確定是否能接受所述修改的QoE度量；接受或拒絕任何起始的或修改的QoE度量；確定在所述會話期間傳送一度量的方式；確定在所述會話期間傳送一QoE度量的頻率；確定一QoE度量的一范圍；確定一QoE度量的一階層；確定一QoE度量的一配置；確定在所述會話期間停用一QoE度量的一方式；確定度量值的參數(shù)；和如果符合某些條件，那么終止所述協(xié)商，包括對最終的一個或多個接受的QoE度量的相互認同。
21.根據(jù)權利要求17所述的制造物品，其中在所述會話期間獲得一個或多個接受的QoE度量相關數(shù)據(jù)的所述指令包括獲得與以下這些QoE度量中的任何一者或多者相關的度量數(shù)據(jù)的指令損壞持續(xù)時間、再緩沖持續(xù)時間、起始緩沖持續(xù)時間、連續(xù)數(shù)據(jù)包丟失、幀速率偏差和抖動持續(xù)時間。
22.根據(jù)權利要求17所述的制造物品，其中所述機器可讀媒體進一步包括其上存儲的指令，以評估所述度量數(shù)據(jù)并應用所述度量數(shù)據(jù)。
23.根據(jù)權利要求22所述的制造物品，其中應用所述度量數(shù)據(jù)的所述指令包括改變以下任何一者或多者的指令位率、幀速率、更新間隔和行為、錯誤彈性、緩沖器行為、最大幀大小、峰值位率、片斷、重傳輸和其它QoE特征。
24.根據(jù)權利要求22所述的制造物品，其中應用所述度量數(shù)據(jù)的所述指令包括改變所述服務器、所述客戶端和所述網(wǎng)絡環(huán)境中的任何一者或多者的一特征的指令；使用所述度量數(shù)據(jù)以用于帳務的指令；使用所述度量數(shù)據(jù)以用于報告和監(jiān)控的指令；或根據(jù)一主觀模式而使用所述度量數(shù)據(jù)的指令。
25.一種可用于一通信環(huán)境中的裝置，所述裝置包含一質(zhì)量體驗(QoE)模塊，其用于在一客戶端與一服務器之間執(zhí)行一協(xié)商，以確定在所述客戶端與所述服務器之間的一會話期間將使用哪個QoE度量，所述這一經(jīng)確定的QoE度量指定為一接受的QoE度量，所述QoE模塊能進一步在所述會話期間在所述客戶端與所述服務器之間傳送對應于所述接受的QoE度量的經(jīng)收集的度量數(shù)據(jù)。
26.根據(jù)權利要求25所述的裝置，其中所述QoE模塊位于所述客戶端處，且能進一步在解碼或處理從所述服務器接收的媒體時收集所述度量數(shù)據(jù)。
27.根據(jù)權利要求25所述的裝置，其中所述QoE模塊位于所述服務器處，所述裝置進一步包含至少另一模塊以與所述QoE模塊合作，以出于至少一個目的而應用所述度量數(shù)據(jù)。
28.根據(jù)權利要求25所述的裝置，其中所述QoE模塊包括一用于以下任何一者或多者的協(xié)商構件起始所述協(xié)商；確定所述服務器或所述客戶端或其兩者支持哪個度量；在協(xié)商期間確認接收一建議的QoE度量；修改一QoE度量且再協(xié)商所述經(jīng)修改的QoE度量，以確定是否可接受所述修改的QoE度量；接受或拒絕任何起始或修改的QoE度量；確定在所述會話期間傳送一QoE度量的一方式；確定在所述會話期間傳送一QoE度量的頻率；確定一QoE度量的一范圍；確定一QoE度量的一階層；確定一QoE度量的一配置；確定在所述會話期間停用一QoE度量的一方式；確定度量值的參數(shù)；和如果某些符合條件，那么終止所述協(xié)商，包括對最終的一個或多個接受的QoE度量的相互認同。
全文摘要
本發(fā)明涉及一種質(zhì)量體驗(QoE)架構，其提供一評估一終端用戶在一諸如2.5G或3G網(wǎng)絡的移動無線通信環(huán)境中，或在任何其它無線或固線通信環(huán)境中的體驗的技術。所述架構可結合媒體流應用而使用，且使得能夠在提取結果中組合網(wǎng)絡層、傳輸層、編碼解碼層和應用層測量。所述提取結果可用于監(jiān)控和改進(如果需要)終端用戶在劇烈可變的網(wǎng)絡條件下的體驗。
文檔編號G06F15/16GK1839597SQ200480024040
公開日2006年9月27日 申請日期2004年8月23日 優(yōu)先權日2003年8月21日
發(fā)明者加姆澤·塞奇金, 拉加文德拉·C·納加拉吉, 拉利特·薩爾納, 艾倫·曾, 賈揚克·M·巴洛德, 馬彥達 申請人:維迪亞特企業(yè)公司