專利名稱：在多媒體流中用于發(fā)信號報告客戶機速率能力的方法
技術(shù)領(lǐng)域：
本發(fā)明通常涉及多媒體流，更具體地說，涉及在多媒體流會話中發(fā)信號報告客戶機的數(shù)據(jù)包速率能力(rate capacity)。
背景技術(shù)：
在多媒體流服務(wù)中，涉及三個參與者流服務(wù)器、流客戶機以及在服務(wù)器和客戶機之間提供連接性的基礎(chǔ)網(wǎng)絡(luò)。服務(wù)器向客戶機提供遞交多媒體流內(nèi)容的功能。為此，客戶機和服務(wù)器就能力交換(capabilityexchange)的方法、內(nèi)容遞交方法協(xié)商、內(nèi)容遞交控制等方面，經(jīng)由網(wǎng)絡(luò)相互通信。這樣的信息交換可以借助明確定義的網(wǎng)絡(luò)協(xié)議來實現(xiàn)。
為了成功地建立和啟動多媒體流會話，服務(wù)器和客戶機必須支持最少的一組協(xié)議，所述協(xié)議由服務(wù)選為標準協(xié)議。這種服務(wù)的一個例子可見于3GPP TS 26.234 V5.1.0，“Transparent End-to-End Packet SwitchedStreaming Service(PSS)；Protocols and Codecs(第5版)”，2002年6月，在下文稱為TS 26.234。在3G PSS中所用的這樣一組協(xié)議的例子是SDP(例如，參見IFTF TFC 2327“SDPSession Description Protocol”，Handley等人，1998年4月)、RTSP(例如，參見IETF RFC 2326“RealTime Streaming Protocal(RTSP)”，Schulzrinne等人，1998年4月)以及RTP/RTCP(例如，參見IETF RFC 1889“RTPA Transport Protocolfor Real-Time Applications”，Schulzrinne等人，1996年1月)。
在流服務(wù)中，客戶機可以是運行在資源受限(resource-limited)裝置上的應用。這可能是下述情況，即客戶機不能處理到達其接收節(jié)點的多于明確規(guī)定數(shù)目的數(shù)據(jù)包。
在大多數(shù)服務(wù)中，服務(wù)器和客戶機就用于內(nèi)容遞交的可用帶寬進行協(xié)商。然而，如果客戶機是資源受限裝置，則客戶機也有對它能夠?qū)嶋H從其接收節(jié)點捕獲的數(shù)據(jù)包的最大數(shù)目的限制。時常，不發(fā)信號報告該限制。
這可能是問題的一種特定情況是在音頻流中，其中可能以50數(shù)據(jù)包/秒的數(shù)據(jù)包速率遞交數(shù)據(jù)(例如，1 AMR-NB幀/有效負荷的AMR-NB編解碼器)。如果存在兩個同時向同一客戶機遞交數(shù)據(jù)的音頻媒體源(或在不同情況下，當除了音頻媒體源之外還有一個以50數(shù)據(jù)包/秒的數(shù)據(jù)包速率遞交煤體數(shù)據(jù)包的視頻源時)，則會有100數(shù)據(jù)包/秒的數(shù)據(jù)包遞交速率，這對于客戶機來說太高了從而不能以沒有數(shù)據(jù)包丟失(packet dropping)來處理。
因此，存在協(xié)商客戶機和服務(wù)器之間的該數(shù)值以便具有良好匹配(well-adapted)的會話的某種需求。

發(fā)明內(nèi)容
本發(fā)明提供了一種在多媒體流服務(wù)中關(guān)于從服務(wù)器到客戶機的數(shù)據(jù)遞交方面從資源受限客戶機和服務(wù)器之間進行發(fā)信號報告和協(xié)商的方法。尤其是，本發(fā)明提供了這樣一種方法，即向服務(wù)器發(fā)信號報告客戶機的最大數(shù)據(jù)包速率能力，使得服務(wù)器不會超過該最大數(shù)據(jù)包速率值，超過該最大數(shù)據(jù)包速率值會導致數(shù)據(jù)包在客戶機端丟失或使客戶移動裝置崩潰。所述方法可利用能力交換機制來實現(xiàn)，或利用多媒體流控制協(xié)議來實現(xiàn)。
因此，本發(fā)明提供了一種方法，用于在具有服務(wù)器的多媒體流網(wǎng)絡(luò)中控制流數(shù)據(jù)遞交，用于以數(shù)據(jù)包數(shù)據(jù)速率向客戶機提供流數(shù)據(jù)，其特征在于在消息中聲明在客戶機的最大數(shù)據(jù)速率能力；以及發(fā)信號將消息報告給服務(wù)器。
根據(jù)本發(fā)明，消息包括通過能力交換機制發(fā)送給服務(wù)器的請求，并且請求包括用于指示最大數(shù)據(jù)速率能力的能力簡檔。由能力簡檔中的能力參數(shù)指示最大數(shù)據(jù)速率能力，并且能力參數(shù)包括在RTSP DESCRIBE請求中。
此外，在駐留在能力交換服務(wù)器中的能力信息中指示最大數(shù)據(jù)速率能力，其中所述請求包括指向該能力信息的URL。服務(wù)器響應該請求，通過能力交換機制從能力交換服務(wù)器中檢索能力參數(shù)，用于調(diào)整數(shù)據(jù)包數(shù)據(jù)速率。
服務(wù)器可根據(jù)能力參數(shù)調(diào)整數(shù)據(jù)包數(shù)據(jù)速率，以便適合在客戶機的最大數(shù)據(jù)包數(shù)據(jù)速率。
可選擇地，通過多媒體流控制協(xié)議發(fā)信號將消息報告給服務(wù)器，并且消息包括請求，該請求包括指示最大數(shù)據(jù)速率能力的RTSP標題擴展。


圖1示出了根據(jù)本發(fā)明的作為發(fā)信號報告和協(xié)商過程-部分的客戶機所作的聲明。
具體實施例方式
根據(jù)本發(fā)明，在多媒體流服務(wù)中就數(shù)據(jù)遞交過程的自適應方面在客戶機和服務(wù)器之間進行發(fā)信號報告和協(xié)商的方法，可通過能力交換機制或通過多媒體流控制協(xié)議來實現(xiàn)。多媒體流控制協(xié)議在服務(wù)上下文(servicecontext)內(nèi)是明確定義和標準化的。能力交換機制是本領(lǐng)域中眾所周知的，因此不是本發(fā)明的一部分。數(shù)據(jù)遞交過程的自適應是基于資源受限客戶機的最大數(shù)據(jù)包速率能力?？蛻魴C利用MaxPacketRate值(數(shù)據(jù)包/秒)來定義在某一時間間隔內(nèi)它能夠處理的數(shù)據(jù)包的最大數(shù)量。
當通過能力交換機制來實現(xiàn)發(fā)信號報告時，步驟(procedure)可以基于例如在TS 26.234中提出的標準。
讓屬性“MaxPacketRate”在RDF(資源描述框架)Schema詞匯表中定義，用于發(fā)信號報告客戶機的最大數(shù)據(jù)包處理速率能力的值。屬性在packets-per-second單元中定義。
發(fā)信號報告步驟如下-客戶機在其能力簡檔中將MaxPacketRate值聲明為能力參數(shù)。例如，客戶機將RTSP DESCRIBE請求發(fā)送給服務(wù)器，該請求帶有指向駐留在能力交換服務(wù)器中的客戶機能力信息的URL。
-服務(wù)器通過能力交換機制從能力交換服務(wù)器中檢索客戶機的能力聲明。如圖1所示，聲明具有用于客戶機端流能力的部分。在聲明中粗體線表示客戶機的最大數(shù)據(jù)包速率能力。一獲得MaxPacketRate值，服務(wù)器就具有了關(guān)于當前數(shù)據(jù)包速率的信息，以便調(diào)整客戶機的最大數(shù)據(jù)包接收速率能力。然后服務(wù)器能夠調(diào)整向客戶機遞交的最大數(shù)據(jù)包速率。然而，直到服務(wù)器采取必要的行動并對數(shù)據(jù)包遞交進行相關(guān)的調(diào)整。
當通過多媒體流控制協(xié)議實現(xiàn)發(fā)信號報告時，客戶機能夠利用明確定義的RTSP選項標記(option tag)和RTSP標題擴展(例如，參見IETF RFC2326) 。
讓“x-maxpacketratesupport”為RTSP選項標記。
讓“x-maxpacketrate”為在packets-per-second單元中定義的RTSP標題擴展。
假設(shè)客戶機事先知道用于多媒體會話的RTSP URL(統(tǒng)一資源定位符)。
發(fā)信號報告步驟如下-客戶機在與發(fā)信號報告x-maxpacketrate值一起發(fā)送的DESCRIBE請求中聲明MaxPacketRate值Client->Server:
DESCRIBE rtsp://foo/twister RTSP/1.0CSeq:1Require:x-maxpacketratesupportx-maxpacketrate:70-如果服務(wù)器沒有利用客戶機的最大數(shù)據(jù)包速率能力，則服務(wù)器用含有“Unsupported:x-maxpacketrate”行的RTSP 551“Option NotSupported”消息或者用含有“Unsupported:x-maxpacketrate”行的RTSP200 OK消息來響應。通過利用RTSP“Require”標題，客戶機知道服務(wù)器是否考慮參數(shù)。如果服務(wù)器考慮參數(shù)，則客戶機能夠利用任一RTSP消息體在會話期間發(fā)信號報告更新的最大數(shù)據(jù)包速率能力。
-如果服務(wù)器利用該參數(shù)，則服務(wù)器檢查RTSP請求并查看其包含明確定義的x-maxpacketrate值。服務(wù)器從RTSP請求消息中檢索所述值。
-在得知客戶機發(fā)送的請求中的MaxPacketRate值之后，服務(wù)器就利用該值調(diào)整遞交給客戶機的最大數(shù)據(jù)包速率。不過，直到服務(wù)器采取必要的行動，并對數(shù)據(jù)包遞交進行相關(guān)的調(diào)整。需要注意的是，客戶裝置能夠支持的來自網(wǎng)絡(luò)接口的最大輸入數(shù)據(jù)包速率，可以在RDF schema詞匯表中被定義為MaxPacketRate，但是其可以被稱為其它名稱。同樣地，在RTSP消息中可以用“x-maxpacketrate”或不同的名稱，只要它可以用來指定客戶裝置能夠支持的來自網(wǎng)絡(luò)接口的最大輸入數(shù)據(jù)包速率?！皒-maxpacketratesupport”或不同的名稱可用于RTSP“Require”標題中，只要它能夠用來指定服務(wù)器知道并考慮客戶機裝置發(fā)送的任何RTSP消息體中傳送的最大輸入數(shù)據(jù)包速率標題的能力。
權(quán)利要求
1.一種在具有服務(wù)器的多媒體流網(wǎng)絡(luò)中用于以數(shù)據(jù)包數(shù)據(jù)速率向客戶機提供流數(shù)據(jù)的控制流數(shù)據(jù)遞交的方法，所述方法特征在于在消息中聲明在客戶機的最大數(shù)據(jù)速率能力；以及發(fā)信號將所述消息報告給所述服務(wù)器。
2.根據(jù)權(quán)利要求1所述的方法，其特征在于，所述消息包括通過能力交換機制發(fā)送給所述服務(wù)器的請求，并且所述請求包括用于指示所述最大數(shù)據(jù)速率能力的能力簡檔。
3.根據(jù)權(quán)利要求2所述的方法，其特征在于，由所述能力簡檔中的能力參數(shù)指示所述最大數(shù)據(jù)速率能力。
4.根據(jù)權(quán)利要求3所述的方法，其特征在于，所述能力參數(shù)包括在RTSPDESCRIBE請求中。
5.根據(jù)權(quán)利要求4所述的方法，其特征在于，在駐留在能力交換服務(wù)器中的能力信息中指示所述最大數(shù)據(jù)速率能力，并且其中所述請求包括指向所述能力信息的URL。
6.根據(jù)權(quán)利要求5所述的方法，其特征在于，所述服務(wù)器響應所述請求，通過所述能力交換機制從所述能力交換服務(wù)器中檢索所述能力參數(shù)，用于調(diào)整所述數(shù)據(jù)包數(shù)據(jù)速率。
7.根據(jù)權(quán)利要求6所述的方法，進一步的特征在于，所述服務(wù)器根據(jù)能力參數(shù)調(diào)整所述數(shù)據(jù)包數(shù)據(jù)速率，以便符合在所述客戶機的所述最大數(shù)據(jù)速率能力。
8.根據(jù)權(quán)利要求1所述的方法，其特征在于，通過多媒體流控制協(xié)議發(fā)信號將所述消息報告給所述服務(wù)器。
9.根據(jù)權(quán)利要求8所述的方法，其特征在于，所述消息包括請求，所述請求包括指示所述最大數(shù)據(jù)速率能力的RTSP標題擴展。
全文摘要
一種在多媒體流服務(wù)中就數(shù)據(jù)包數(shù)據(jù)遞交方面在資源受限客戶機和服務(wù)器之間進行發(fā)信號報告和協(xié)商的方法。為了避免因客戶機最大數(shù)據(jù)包數(shù)據(jù)能力而引起在客戶機端丟失數(shù)據(jù)包，客戶機發(fā)信號報告服務(wù)器，聲明最大數(shù)據(jù)包速率能力?？赏ㄟ^能力交換機制或利用多媒體流協(xié)議將這種能力發(fā)信號報告給客戶機?？蛻魴C在發(fā)送到服務(wù)器的請求中插入指示最大數(shù)據(jù)包數(shù)據(jù)速率能力的參數(shù)。直到服務(wù)器采取必要的行動并進行數(shù)據(jù)包遞交速率調(diào)整。
文檔編號G06F15/16GK101088081SQ200480004195
公開日2007年12月12日 申請日期2004年2月13日 優(yōu)先權(quán)日2003年2月13日
發(fā)明者E·B·阿克蘇, I·D·D·庫爾喬, D·萊昂, V·瓦薩, 王如生 申請人:諾基亞有限公司