專利名稱：基于無線電承載配置的緩沖器狀態(tài)報告的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及無線通信系統(tǒng)，并且更具體來說涉及用于在無線通信系統(tǒng)中周期性地報告緩沖器(buffer)狀態(tài)的方法和設(shè)備。
背景技術(shù)：
UTRAN(通用地面無線電接入網(wǎng)絡(luò))是標識出UMTS (通用移動電信系統(tǒng))的無線 電接入網(wǎng)絡(luò)的術(shù)語，其中UTRAN包括無線電網(wǎng)絡(luò)控制器(RNC)和NodeB(即無線電基站)。 NodeB與移動用戶設(shè)備無線通信，并且RNC控制NodeB。另外，RNC還連接到核心網(wǎng)絡(luò)(CN)。 演進型UTRAN(E-UTRAN)是UTRAN朝著高數(shù)據(jù)率、低延遲和分組優(yōu)化的無線電接入網(wǎng)絡(luò)的演 進。另外，E-UTRAN包括eNodeB(演進型eNodeB)，并且eNodeB被互連并且還被連接到演 進型分組核心網(wǎng)絡(luò)(EPC)。E-UTRAN也被稱為長期演進(LTE)并且在第三代合作伙伴計劃 (3GPP)內(nèi)被標準化。在LTE中，上行鏈路媒體接入控制(MAC)調(diào)度器存在于eNodeB中，并且將傳輸資 源指派給小區(qū)中的用戶設(shè)備。此外，eNodeB選擇傳輸格式(TF)以供用戶設(shè)備使用。為了 執(zhí)行這些任務，MAC調(diào)度器需要關(guān)于UE當前緩沖器狀態(tài)的信息，即該UE在其優(yōu)先級隊列 中是否緩沖有數(shù)據(jù)或者緩沖有多少數(shù)據(jù)。MAC調(diào)度器還可能需要另外的信息，比如用于估計 上行鏈路增益以選擇合適TF的可用功率上升空間(headroom)和傳送功率。非常精確和最 新的調(diào)度信息實現(xiàn)了準確的調(diào)度決策。然而，從UE向eNodeB提供該信息引起一定的成本， 其中必須將所述成本與其提供的收益相比較。詳細的緩沖器狀態(tài)報告在比特數(shù)方面可能非常大，并且如果被頻繁傳送則將花費 相當大的開銷。對于許多應用而言，緩沖器狀態(tài)是連續(xù)變化的。例如，傳輸控制協(xié)議(TCP) 連續(xù)地增大其擁塞窗口，但是在經(jīng)歷丟包(packet drop)時，其減小擁塞窗口。對于使用 TCP的應用而言，被頻繁更新的粗略緩沖器指示更加有益。在3GPP中，緩沖器狀態(tài)報告正被標準化。緩沖器狀態(tài)報告由UE執(zhí)行以向eNodeB 報告存儲在其緩沖器中的可供傳送的數(shù)據(jù)量。eNodeB使用緩沖器狀態(tài)報告來向UE分配資 源并且確定小區(qū)中的UE之間的資源分配的優(yōu)先級。LTE與UE部分和E-UTRAN部分這二者的OSI分層參考模型都兼容。該協(xié)議架構(gòu) 被細分成控制平面，其負責信令信息的傳送；以及用戶平面，其負責用戶數(shù)據(jù)的傳送。圖1 示出了 LTE中的用戶平面的協(xié)議棧。具體來說，考慮三個協(xié)議層物理層(第1層)、數(shù)據(jù) 鏈路層(第2層)以及網(wǎng)絡(luò)層(第3層)。第2層協(xié)議包括媒體接入控制(MAC)協(xié)議、無線 電鏈路控制(RLC)協(xié)議以及分組數(shù)據(jù)會聚協(xié)議(PDCP)。圖2中示出了用于上行鏈路的第 2層結(jié)構(gòu)。MAC執(zhí)行緩沖器狀態(tài)報告。RLC給無線電接口提供無線電鏈路管理。PDCP主控 (host)首部壓縮、重排序功能以及加密功能(如圖3所示)。如3GPP標準化文獻TS 36. 323中所陳述的那樣，LTE支持在PDCP中對網(wǎng)際協(xié)議 (IP)首部進行壓縮。所述首部壓縮協(xié)議基于魯棒性首部壓縮(RoHC)框架、RFC 4995。RoHC 通過在具有有限容量的鏈路之前放置壓縮器以及在該鏈路之后放置解壓縮器來將40字節(jié)或60字節(jié)的開銷壓縮成通常1或3字節(jié)。壓縮器將大的開銷轉(zhuǎn)換成僅僅幾個字節(jié)，而解壓 縮器進行相反的操作。存在多種在RoHC框架中所定義的首部壓縮算法(稱為類(profile))。每個類都 專門針對特定的網(wǎng)絡(luò)層、傳輸層、或者上層協(xié)議組合_例如TCP/IP和RTP/UDP/IP(實時傳 輸協(xié)議/用戶數(shù)據(jù)報協(xié)議/IP)。然而，由首部壓縮算法所實現(xiàn)的壓縮比取決于多個因素，包括 數(shù)據(jù)字段在分組序列中從一個分組到另一分組的改變行為_例如IP標識符行 為或者序列號和時間戳在分組間的典型的增加； 壓縮上下文(context)的狀態(tài) 在承載經(jīng)壓縮的分組的鏈路上的可能的損傷-例如損失、重排序、請求上下文 修復的反饋；以及 實施方式特定的因素-比如魯棒性算法，例如相同類型的更新的重復次數(shù)、反 饋邏輯以及所支持的經(jīng)壓縮的首部的子集等。由于這些因素，對于特定的分組，不能在壓縮過程本身之前確定可能實現(xiàn)的壓縮 比。因此，需要在UE與eNodeB之間被傳送的確切比特量僅僅在首部壓縮已經(jīng)被執(zhí)行之后 才被得知。此外，RLC能夠被配置為在不同的模式下操作_例如透明模式(TM)、非確認模式 (UM)以及確認模式(AM)。RLC-TM功能包括傳輸用戶數(shù)據(jù)。RLC-UM功能包括傳輸用戶數(shù)據(jù)、 分割和重組功能、以及定序(sequencing)。RLC-AM通過重傳來提供可靠性。RLC-AM功能包 括傳輸用戶數(shù)據(jù)、分割和重組功能、糾錯、副本檢測(duplicatedetection)、協(xié)議檢錯和恢 復。RLC-AM包括自動重復請求(ARQ)功能，所述功能給要求較高傳輸可靠性的服務(比如 分組交換數(shù)據(jù)服務)提供糾錯。然而，在RLC-UM模式中，RLC并不執(zhí)行ARQ，并且因此一些 RLC SDU(服務數(shù)據(jù)單元)可能丟失。當UE執(zhí)行從一個小區(qū)到另一小區(qū)的切換(例如eNodeB內(nèi)切換或eNodeB間切換) 時，對于以RLC-AM配置的無線電承載(raidobearer)而言，UE從對應于在該切換指示之前 還未被RLC確認的最舊的PDU的序列號開始累積地重傳所有的PDCP SDU。以RLC-AM配置 的無線電承載還可以被配置為使用PDCP狀態(tài)報告。PDCP狀態(tài)報告在切換時被用于在切換 之前未被成功接收的PDCP SDU ；這可以被所述報告的接收機用于避免在切換之后將副本發(fā) 送給目標eNodeB。此外，在切換時，加密和首部壓縮這二者都被重新啟動。因此，為了在目標小區(qū)中 傳送PDCP SDU，必須使用新的安全上下文和新的首部壓縮上下文。結(jié)果，由于安全和首部壓 縮二者都被重新啟動，因此緩沖在RLC層中的任何數(shù)據(jù)都變得無用并且因此被丟棄。如果 可供傳送的數(shù)據(jù)被緩沖在PDCP層之下，也就是說，已經(jīng)對緩沖數(shù)據(jù)執(zhí)行了首部壓縮和加密 二者，則UE必須仍然具有訪問未壓縮和未加密的數(shù)據(jù)的手段，以便在切換時基于新的相應 上下文對所述數(shù)據(jù)進行壓縮和加密。否則，當RLC緩沖器被清除時，所述數(shù)據(jù)丟失。另一方 面，如果可供傳送的數(shù)據(jù)被緩沖在PDCP層之上，則還未對緩沖數(shù)據(jù)進行首部壓縮和加密。 在首部壓縮被配置的情況下，UE僅能夠報告其緩沖器中所緩沖的未壓縮的數(shù)據(jù)量，并且因 此該緩沖器報告不準確。應當注意，UE在通常情況下僅僅在其中數(shù)據(jù)被發(fā)送的TTI (傳輸 時間間隔)中處理所述數(shù)據(jù)。因此，數(shù)據(jù)可能被緩沖在PDCP層之下和PDCP層之上。
另外，可以執(zhí)行主動隊列管理(AQM)以在為了傳送而緩沖的數(shù)據(jù)量超過UE存儲和 傳送數(shù)據(jù)的容量時從隊列中丟棄分組。通常情況下優(yōu)選的是，在PDCP層之前對具有較高分 組速率的IP流執(zhí)行AQM以便不會對PDCP功能造成負面影響-例如避免安全/首部壓縮同 步的損失。在現(xiàn)有技術(shù)緩沖器狀態(tài)報告機制中，UE總是要么報告1)未壓縮數(shù)據(jù)的大小2)基于對壓縮比的估計而報告接近于經(jīng)壓縮數(shù)據(jù)的大小的數(shù)據(jù)大小；要么報告3)經(jīng)壓縮數(shù)據(jù)的大小。然而，在情況1)下(也就是說，當首部壓縮被配置時未壓縮數(shù)據(jù)的大小被報告)， 如前面所解釋的那樣，所報告的數(shù)據(jù)大小將不準確。在情況2)下(也就是說，接近于經(jīng)壓 縮數(shù)據(jù)的大小的數(shù)據(jù)大小被報告)，該報告將是不準確的，因為壓縮比不是確定性的并且不 能被準確地預測。另外，為了執(zhí)行該估計將引入復雜度。在情況3)下(也就是說，經(jīng)壓縮 數(shù)據(jù)的大小被報告)，這意味著要么UE在數(shù)據(jù)一到達PDCP層中就執(zhí)行對所有數(shù)據(jù)的首部 壓縮，要么UE不能產(chǎn)生針對所述數(shù)據(jù)中的一些數(shù)據(jù)的報告。所預期的是，UE將僅在傳送的 時候處理數(shù)據(jù)_例如執(zhí)行首部壓縮和加密，以便考慮到壓縮狀態(tài)的任何變化_即由于定時 器或反饋造成的變化并且使存儲器需求最小化。UE在一些情況下(例如當RLC AM被配置 時)必須保留經(jīng)壓縮的PDCPSDU的未壓縮的拷貝，因為否則的話，在RLC緩沖器被重置時 (例如執(zhí)行切換時)，一些數(shù)據(jù)可能丟失。如前面所提到的那樣，eNodeB使用從UE接收的緩沖器狀態(tài)報告來向UE分配無線 電資源以滿足服務需求，以便避免UE緩沖器溢出，并且在UE不再有數(shù)據(jù)要傳送時停止向該 UE分配資源。在沒有緩沖器狀態(tài)報告或者緩沖器狀態(tài)報告不準確(其中所報告的UE緩沖 器中的數(shù)據(jù)大小大于實際將被傳送的數(shù)據(jù)大小)的情況下，eNodeB將分配比該UE所需的 更多的資源，并且導致UE針對已經(jīng)授予給該UE的許可(grant)傳送填充物(padding)。在 所報告的UE緩沖器中的數(shù)據(jù)大小小于實際被傳送的數(shù)據(jù)大小的情況下，eNodeB將分配過 少的資源，這將導致分割和增加的傳輸延時。緩沖器狀態(tài)報告中的錯誤的重要程度取決于相對于未壓縮的首部的大小的IP 有效載荷的大小。如果UE總是基于未壓縮的數(shù)據(jù)大小報告其緩沖器的狀態(tài)并且首部壓縮 被配置，則所報告的數(shù)據(jù)大小將完全不準確。對于其中IP分組中有效載荷的大小很小并且 與未壓縮首部的大小可比的數(shù)據(jù)服務(例如IP語音、純TCP確認)，則該錯誤將是非常重要 的_例如對于利用RoHC壓縮的IP語音/AMR12. 2為大致50%，否則該錯誤可能不那么重 要。

發(fā)明內(nèi)容
如上所述，現(xiàn)有技術(shù)方案中的UE緩沖器狀態(tài)報告可能顯著偏離UE必須傳送給 eNodeB的實際數(shù)據(jù)大小。此外，如果出于提高緩沖器狀態(tài)報告的準確度這一目的而將命令 UE在數(shù)據(jù)一經(jīng)變得可供傳送時就立即執(zhí)行首部壓縮，則UE的存儲器需求將增加，因為UE必 須保留所述數(shù)據(jù)的副本以防備安全和首部壓縮上下文改變。因此，本發(fā)明的目的是提供用 于改進的緩沖器狀態(tài)報告的方法和設(shè)備。該目的根據(jù)本發(fā)明通過在確定由UE發(fā)送給eNodeB的緩沖器狀態(tài)報告的內(nèi)容時考慮到無線電承載配置的類型來實現(xiàn)。根據(jù)本發(fā)明的第一方面，提供有一種供無線通信系統(tǒng)的用戶設(shè)備將緩沖器狀態(tài)報 告給該無線通信系統(tǒng)的網(wǎng)絡(luò)節(jié)點的方法。所述用戶設(shè)備包括與無線電承載相關(guān)聯(lián)的數(shù)據(jù)緩 沖器，并且該數(shù)據(jù)緩沖器中的將被傳送到該網(wǎng)絡(luò)節(jié)點的可供傳送的數(shù)據(jù)被確定。此外，無線 電承載的配置被確定。另外，緩沖器大小基于可供傳送的數(shù)據(jù)和無線電承載的配置中的至 少之一而被確定。包括緩沖器大小的緩沖器狀態(tài)被報告給該網(wǎng)絡(luò)節(jié)點。根據(jù)本發(fā)明的第二方面，提供有一種適于將緩沖器狀態(tài)報告給網(wǎng)絡(luò)節(jié)點的用戶設(shè) 備。該用戶設(shè)備和該網(wǎng)絡(luò)節(jié)點被包含在無線通信系統(tǒng)中，并且該用戶設(shè)備包括與無線電承 載相關(guān)聯(lián)的數(shù)據(jù)緩沖器。該用戶設(shè)備包括用于確定該數(shù)據(jù)緩沖器中的將被傳送到該網(wǎng)絡(luò)節(jié) 點的可供傳送的數(shù)據(jù)的裝置。此外，該用戶設(shè)備包括用于確定無線電承載的配置的裝置、以 及用于基于該數(shù)據(jù)緩沖器中的數(shù)據(jù)和無線電承載的配置中的至少之一來確定緩沖器大小 的裝置。另外，該用戶設(shè)備包括用于將包括緩沖器大小的緩沖器狀態(tài)報告給該網(wǎng)絡(luò)節(jié)點的 傳送機。本發(fā)明的優(yōu)點是，其提供更準確的UE緩沖器狀態(tài)報告。所述緩沖器狀態(tài)報告并不 顯著偏離該UE必須傳送給eNodeB的實際數(shù)據(jù)大小。這意味著，該eNodeB執(zhí)行更高效的無 線電資源分配。另一優(yōu)點是，由于UE并不需要為了提供更準確的報告而壓縮其緩沖器中的所有 數(shù)據(jù)，所以并不給UE中的存儲器存儲帶來附加的需求，因為UE在通常情況下必須保留數(shù)據(jù) 的副本以防備安全和首部壓縮上下文的改變。又一優(yōu)點是，能夠在時間關(guān)鍵的處理路徑之外執(zhí)行首部壓縮和加密。


為了更好地理解，參考下面的附圖和本發(fā)明的優(yōu)選實施例。圖1示出了根據(jù)現(xiàn)有技術(shù)的LTE中的用戶平面的協(xié)議棧。圖2示出了根據(jù)現(xiàn)有技術(shù)的LTE中的上行鏈路的第2層結(jié)構(gòu)。圖3示出了根據(jù)現(xiàn)有技術(shù)的LTE中的PDCP層所主控的首部壓縮、重排序功能以及 加密功能。圖4示意性地示出了其中可以根據(jù)現(xiàn)有技術(shù)實施本發(fā)明的無線通信網(wǎng)絡(luò)。圖5是根據(jù)本發(fā)明的實施例的用于UE的方法的流程圖。圖6是根據(jù)本發(fā)明的另一實施例的用于UE的方法的流程圖。圖7是根據(jù)本發(fā)明的又一實施例的用于UE的方法的流程圖。圖8示意性地示出了根據(jù)本發(fā)明的實施例的UE的框圖。
具體實施例方式在下面的描述中，出于說明而不是限制的目的而闡述了特定細節(jié)_比如特定的步 驟序列、信令協(xié)議以及設(shè)備配置，以便提供對本發(fā)明的透徹理解。對于本領(lǐng)域的技術(shù)人員而 言將顯而易見的是，可以以偏離這些特定細節(jié)的實施例來實施本發(fā)明。此外，本領(lǐng)域的技術(shù)人員將會理解，在此之后所說明的裝置和功能可以使用結(jié)合 經(jīng)編程的微處理器或通用計算機運行的軟件、和/或使用專用集成電路(ASIC)來實施。還能夠理解，盡管本發(fā)明主要是以方法和設(shè)備的形式被描述的，但是本發(fā)明還可以體現(xiàn)為計 算機程序產(chǎn)品以及包括計算機處理器和耦合到該處理器的存儲器的系統(tǒng)，其中以一個或多 個可以執(zhí)行在此所公開的功能的程序?qū)λ龃鎯ζ鬟M行編碼。如上所述，現(xiàn)有技術(shù)方案中的UE緩沖器狀態(tài)報告可能顯著偏離UE必須傳送給 eNodeB的實際數(shù)據(jù)大小。此外，UE必須保留所述數(shù)據(jù)的副本以防備安全和首部壓縮上下文 的改變。因此，本發(fā)明提供了用于在報告緩沖器狀態(tài)報告時考慮到無線電承載配置的類型 的改進的緩沖器狀態(tài)報告的方法和設(shè)備。根據(jù)本發(fā)明的實施例，這通過在確定由UE發(fā)送給 eNodeB的緩沖器狀態(tài)報告的內(nèi)容時考慮到無線電承載配置的類型來實現(xiàn)。圖4示意性地示出了其中可以實施本發(fā)明的無線通信網(wǎng)絡(luò)。該通信網(wǎng)絡(luò)被廣泛部 署以提供多種通信服務-比如語音和分組數(shù)據(jù)。如圖4所示，該無線通信網(wǎng)絡(luò)可以包括連 接到核心網(wǎng)絡(luò)300的一個或多個eNodeB 200，并且多個UE 100可以位于一個小區(qū)中。無線 電鏈路可以被定義成UE 100與eNodeB 200之間的邏輯信道。其物理實現(xiàn)包括無線電承載 傳送。上行鏈路緩沖器狀態(tài)報告包括UE中的邏輯信道隊列中所緩沖的可供傳送的數(shù)據(jù)的 fn息o現(xiàn)在轉(zhuǎn)到圖5-8，其示出了根據(jù)本發(fā)明實施例的方法的流程圖和設(shè)備的框圖。圖5示出了根據(jù)本發(fā)明的第一實施例的方法的流程圖。UE 100(如圖4所示)包括 與無線電承載相關(guān)聯(lián)的數(shù)據(jù)緩沖器。UE 100確定數(shù)據(jù)緩沖器中的將被傳送到eNodeB 200 的可供傳送的數(shù)據(jù)10。另外，UE100還確定無線電承載的配置20-即該無線電承載是否被 以首部壓縮進行配置。在下一步驟中，UE 100確定緩沖器大小30，這基于可供傳送的數(shù)據(jù) 和該無線電承載的配置。當UE 100將緩沖器狀態(tài)的報告40發(fā)送給eNodeB時，緩沖器大小 被包含在所述緩沖器狀態(tài)報告中。在下面的描述中描述關(guān)于如何基于可供傳送的數(shù)據(jù)和無 線電承載的配置來確定緩沖器大小的不同替代方案。當無線電承載未被以首部壓縮進行配置時，緩沖器大小被確定為可供傳送的數(shù)據(jù) 大小。例如，如果該緩沖器中的數(shù)據(jù)是數(shù)據(jù)A、B、C、D和E，則緩沖器狀態(tài)報告中的緩沖器大 小是數(shù)據(jù)A、B、C、D、和E的大小。然而，當無線電承載被以首部壓縮進行配置時，該數(shù)據(jù)緩 沖器可能包括未壓縮的數(shù)據(jù)和經(jīng)壓縮的數(shù)據(jù)。例如，數(shù)據(jù)緩沖器中的數(shù)據(jù)是數(shù)據(jù)a、b、c、D 和E，其中a、b和c分別表示經(jīng)壓縮的數(shù)據(jù)A、B和C，而D和E分別表示未壓縮的數(shù)據(jù)D和 E0作為第一替代方案，于是緩沖器大小可以被確定為該數(shù)據(jù)緩沖器中的經(jīng)壓縮數(shù)據(jù) 的大小。因此，緩沖器狀態(tài)報告中的緩沖器大小是經(jīng)壓縮的數(shù)據(jù)a、b和c的大小。使用第 一替代方案的典型場景是當無線電承載被以RLC-UM進行配置的時候。通常，RLC-UM被用于 實時服務(所述實時服務經(jīng)常交換具有以固定間隔傳送的小有效載荷的分組)_比如VoIP 服務，對于這些服務而言重要的是網(wǎng)絡(luò)容量和對無線電資源的高效利用。一個優(yōu)點是，已經(jīng) 除去了緩沖器狀態(tài)報告的錯誤，其中所述錯誤可能是通過在首部幾乎同有效載荷本身一樣 大時報告未壓縮數(shù)據(jù)而被引入的。因此，eNodeB接收關(guān)于UE緩沖器狀態(tài)的更精確的信息， 并且能夠結(jié)合服務行為的知識而更高效地管理無線電資源。作為第二替代方案，緩沖器大小可以被確定為該數(shù)據(jù)緩沖器中的經(jīng)壓縮數(shù)據(jù)和未 壓縮數(shù)據(jù)的大小。在先前例子中，這將意味著緩沖器狀態(tài)報告中的緩沖器大小是經(jīng)壓縮的 數(shù)據(jù)a、b和c以及未壓縮的數(shù)據(jù)D和E的大小。
作為第三替代方案，緩沖器大小可以被確定為該數(shù)據(jù)緩沖器中的未壓縮數(shù)據(jù)和經(jīng) 壓縮數(shù)據(jù)的未壓縮版本的大小。因此，緩沖器狀態(tài)報告中的緩沖器大小是未壓縮的數(shù)據(jù)A、 B和C以及未壓縮的數(shù)據(jù)D和E的大小。使用第三替代方案的典型場景是當無線電承載被 以RLC-AM進行配置的時候。通常，RLC-AM被用于盡力服務(best-effortservice)(所述盡 力服務經(jīng)常交換較大數(shù)據(jù)量)_比如TCP數(shù)據(jù)傳輸，對于所述服務，網(wǎng)絡(luò)將分配無線電資源 以通過無線電(over the air)提供可接受的數(shù)據(jù)率，使得不致于由于資源分配不足而讓UE 饑餓或者由于資源過量分配而讓UE傳送填充物。對于RLC-AM、TCP和大分組而言，首部的 開銷與有效載荷相比相對較小。因此，一個優(yōu)點是，eNodeB接收如下信息根據(jù)所述信息， eNodeB能夠基于業(yè)務特性的知識-例如分組大小推斷出比特速率或分組速率。在圖6所示的本發(fā)明的另一實施例中，當首部壓縮被配置在無線電承載上時，首 部大小基于可供傳送的數(shù)據(jù)以及該無線電承載的特性和/或該數(shù)據(jù)緩沖器中的可供傳送 的數(shù)據(jù)的特性。UE另外確定25無線電承載類型和/或可供傳送的數(shù)據(jù)的數(shù)據(jù)服務類型、和 /或可供傳送的數(shù)據(jù)的數(shù)據(jù)協(xié)議類型、和/或可供傳送的數(shù)據(jù)的分組大小。此外，緩沖器大 小基于無線電承載類型和/或可供傳送的數(shù)據(jù)的數(shù)據(jù)服務類型、和/或可供傳送的數(shù)據(jù)的 數(shù)據(jù)協(xié)議類型、和/或可供傳送的數(shù)據(jù)的分組大小。根據(jù)前面所描述的第一、第二和第三替 代方案，包含在緩沖器狀態(tài)報告中的緩沖器大小被確定。在本發(fā)明實施例的場景中，無線電承載被確定為以首部壓縮進行配置并且無線電 承載類型是以RLC-AM配置的無線電承載。在該場景中，緩沖器大小通?？梢员淮_定為該數(shù) 據(jù)緩沖器中的未壓縮數(shù)據(jù)和經(jīng)壓縮數(shù)據(jù)的未壓縮版本的大小。如果數(shù)據(jù)緩沖器中的數(shù)據(jù)是 a、b、c、D和E，則緩沖器狀態(tài)報告中的緩沖器大小是未壓縮數(shù)據(jù)A、B和C以及未壓縮數(shù)據(jù) D和E的大小。然而，應當注意，在所描述的場景中還可以應用確定緩沖器大小的其它替代 方案(即第一和第二替代方案)。在本發(fā)明實施例的又一場景中，無線電承載被確定為以首部壓縮進行配置并且無 線電承載類型是以RLC-UM配置的無線電承載。在該場景中，緩沖器大小通?？梢员淮_定為 該數(shù)據(jù)緩沖器中的經(jīng)壓縮數(shù)據(jù)的大小。如果數(shù)據(jù)緩沖器中的數(shù)據(jù)是a、b、c、D和E，則緩沖 器狀態(tài)報告中的緩沖器大小是經(jīng)壓縮的數(shù)據(jù)a、b和c的大小。然而，應當注意，在所述場景 中還可以應用確定緩沖器大小的其它替代方案(即第二和第三替代方案)。在本發(fā)明實施例的另一場景中，無線電承載被確定為以首部壓縮進行配置并且數(shù) 據(jù)協(xié)議類型是TCP。在該場景中，緩沖器大小通?？梢员淮_定為該數(shù)據(jù)緩沖器中的未壓縮 數(shù)據(jù)和經(jīng)壓縮數(shù)據(jù)的未壓縮版本的大小。如果數(shù)據(jù)緩沖器中的數(shù)據(jù)是a、b、c、D和E，則緩 沖器狀態(tài)報告中的緩沖器大小是未壓縮數(shù)據(jù)A、B和C以及未壓縮數(shù)據(jù)D和E的大小。一個 優(yōu)點是，eNodeB接收如下信息根據(jù)所述信息，eNodeB能夠基于業(yè)務特性的知識-例如分 組大小推斷出比特速率或分組速率。此外，如果數(shù)據(jù)協(xié)議類型被確定為RTP (實時協(xié)議)， 則緩沖器大小通?？梢员淮_定為該數(shù)據(jù)緩沖器中的經(jīng)壓縮數(shù)據(jù)的大小。如果數(shù)據(jù)緩沖器中 的數(shù)據(jù)是a、b、c、D和E，則緩沖器狀態(tài)報告中的緩沖器大小是經(jīng)壓縮的數(shù)據(jù)a、b和c的大 小。一個優(yōu)點是，eNodeB接收關(guān)于UE緩沖器狀態(tài)的更精確的信息，并且能夠結(jié)合服務行為 的知識而更高效地管理無線電資源。在本發(fā)明實施例的又一場景中，無線電承載被確定為以首部壓縮進行配置并且數(shù) 據(jù)緩沖器中的可供傳送的數(shù)據(jù)的分組大小被確定為大于預定閾值。在該場景中，緩沖器大小通?？梢员淮_定為該數(shù)據(jù)緩沖器中的未壓縮數(shù)據(jù)和經(jīng)壓縮數(shù)據(jù)的未壓縮版本的大小。如 果數(shù)據(jù)緩沖器中的數(shù)據(jù)是a、b、c、D和E，則緩沖器狀態(tài)報告中的緩沖器大小是未壓縮數(shù)據(jù) A、B和C以及未壓縮數(shù)據(jù)D和E的大小。然而，如果所述分組大小被確定為小于或等于預 定閾值，則緩沖器大小通?？梢员淮_定為該數(shù)據(jù)緩沖器中的經(jīng)壓縮數(shù)據(jù)的大小。如果數(shù)據(jù) 緩沖器中的數(shù)據(jù)是a、b、c、D和E，則緩沖器狀態(tài)報告中的緩沖器大小是經(jīng)壓縮的數(shù)據(jù)a、b、 和c的大小。在本發(fā)明實施例的又一場景中，無線電承載被確定為以首部壓縮進行配置并且數(shù) 據(jù)緩沖器中的可供傳送的數(shù)據(jù)的數(shù)據(jù)服務類型被確定為盡力類型的數(shù)據(jù)服務-比如文件 傳輸或者例如使用TCP的web (網(wǎng)絡(luò))瀏覽。在該場景中，緩沖器大小通?？梢员淮_定為 該數(shù)據(jù)緩沖器中的未壓縮數(shù)據(jù)和經(jīng)壓縮數(shù)據(jù)的未壓縮版本的大小。如果數(shù)據(jù)緩沖器中的 數(shù)據(jù)是a、b、c、D和E，則緩沖器狀態(tài)報告中的緩沖器大小是未壓縮數(shù)據(jù)A、B和C以及未壓 縮數(shù)據(jù)D和E的大小。然而，如果所述數(shù)據(jù)服務類型被確定為實時類型的數(shù)據(jù)服務_比如 VoIP服務或者游戲服務，則緩沖器大小通?？梢员淮_定為該數(shù)據(jù)緩沖器中的經(jīng)壓縮數(shù)據(jù)的 大小。如果數(shù)據(jù)緩沖器中的數(shù)據(jù)是a、b、c、D和E，則緩沖器狀態(tài)報告中的緩沖器大小是經(jīng) 壓縮的數(shù)據(jù)a、b和c的大小。圖7示出了本發(fā)明的實施例，其中UE從eNodeB接收關(guān)于如何確定緩沖器大小的 指令27。所述指令可以是使用確定將被包含在緩沖器狀態(tài)報告中的緩沖器大小的三個替代 方案中的任意一個。此外，對緩沖器大小的確定可以在無線通信系統(tǒng)中被預先配置?？梢?針對每個無線電承載、每組無線電承載或者該UE所使用的所有無線電承載來定義所述指 令和預先配置?，F(xiàn)在轉(zhuǎn)到圖8，圖8示出了根據(jù)本發(fā)明的一個實施例的將被實施在UE中的裝置。UE 100適于將緩沖器狀態(tài)報告給網(wǎng)絡(luò)節(jié)點_即eNodeB 200 (如圖4所示)。該UE 包括與無線電承載相關(guān)聯(lián)的數(shù)據(jù)緩沖器110。另外，該UE包括用于確定該數(shù)據(jù)緩沖器中的 將被傳送到該網(wǎng)絡(luò)節(jié)點的可供傳送的數(shù)據(jù)的裝置120、以及用于確定無線電承載的配置的 裝置130。另外，該UE還包括用于基于該數(shù)據(jù)緩沖器中的可供傳送的數(shù)據(jù)和所確定的無線 電承載的配置中的至少之一來確定緩沖器大小的裝置140。另外，該UE還包括用于將包括 緩沖器大小的緩沖器狀態(tài)報告給該網(wǎng)絡(luò)節(jié)點的傳送機150。在本發(fā)明的實施例中，該UE包 括用于確定無線電承載類型、數(shù)據(jù)服務類型、數(shù)據(jù)協(xié)議類型和分組大小中的至少之一的裝 置160。在本發(fā)明的另一實施例中，該UE包括用于從該網(wǎng)絡(luò)節(jié)點接收關(guān)于如何確定緩沖器 大小的指令的接收機170。盡管已經(jīng)針對特定實施例(包括某些設(shè)備裝置和各種方法中的某些步驟次序)描 述了本發(fā)明，但是本領(lǐng)域的技術(shù)人員將會認識到，本發(fā)明并不限于在此所描述和所圖示的 具體實施例。因此，應當理解，本公開僅僅是說明性的。因此，旨在僅僅通過此處所附權(quán)利 要求書的范圍來限定本發(fā)明。
權(quán)利要求
一種供無線通信系統(tǒng)的用戶設(shè)備將緩沖器狀態(tài)報告給所述無線通信系統(tǒng)的網(wǎng)絡(luò)節(jié)點的方法，所述用戶設(shè)備包括與無線電承載相關(guān)聯(lián)的數(shù)據(jù)緩沖器，所述方法包括步驟-確定數(shù)據(jù)緩沖器中的將被傳送到網(wǎng)絡(luò)節(jié)點的可供傳送的數(shù)據(jù)(10)；其特征在于所述方法包括附加的步驟-確定無線電承載的配置(20)；-基于可供傳送的數(shù)據(jù)和無線電承載的配置中的至少之一來確定緩沖器大小(30)；以及-將包括緩沖器大小的緩沖器狀態(tài)報告給網(wǎng)絡(luò)節(jié)點(40)。
2.根據(jù)權(quán)利要求1所述的方法，其中所述無線電承載被確定為未以首部壓縮進行配置 并且所述緩沖器大小被確定為可供傳送的數(shù)據(jù)的大小。
3.根據(jù)權(quán)利要求1或2中任一項所述的方法，包括附加的步驟_確定無線電承載類型、數(shù)據(jù)服務類型、數(shù)據(jù)協(xié)議類型和分組大小中的至少之一(25)； _基于可供傳送的數(shù)據(jù)、無線電承載的配置、無線電承載類型、數(shù)據(jù)服務類型、數(shù)據(jù)協(xié)議 類型和分組大小中的至少之一來確定緩沖器大小(30)。
4.根據(jù)權(quán)利要求1或3中任一項所述的方法，其中所述無線電承載被確定為以首部壓 縮進行配置并且可供傳送的數(shù)據(jù)包括部分未壓縮的數(shù)據(jù)和部分經(jīng)壓縮的數(shù)據(jù)。
5.根據(jù)權(quán)利要求4所述的方法，其中所述緩沖器大小被確定為未壓縮的數(shù)據(jù)的大小和 經(jīng)壓縮的數(shù)據(jù)的未壓縮版本的大小的總大小。
6.根據(jù)權(quán)利要求4所述的方法，其中所述緩沖器大小被確定為經(jīng)壓縮的數(shù)據(jù)的大小。
7.根據(jù)權(quán)利要求4所述的方法，其中所述緩沖器大小被確定為未壓縮的數(shù)據(jù)的大小和 經(jīng)壓縮的數(shù)據(jù)的大小的總大小。
8.根據(jù)權(quán)利要求4至7中任一項所述的方法，其中所述無線電承載類型是以RLC-AM或 RLC-UM配置的無線電承載。
9.根據(jù)權(quán)利要求6所述的方法，其中所述數(shù)據(jù)協(xié)議類型是RTP。
10.根據(jù)權(quán)利要求5所述的方法，其中所述數(shù)據(jù)協(xié)議類型是TCP。
11.根據(jù)權(quán)利要求5所述的方法，其中所述分組大小大于預定值。
12.根據(jù)權(quán)利要求6所述的方法，其中所述分組大小小于或等于預定值。
13.根據(jù)權(quán)利要求5所述的方法，其中所述數(shù)據(jù)服務類型是盡力服務類型。
14.根據(jù)權(quán)利要求6所述的方法，其中所述數(shù)據(jù)服務類型是實時服務類型。
15.根據(jù)權(quán)利要求1至14中任一項所述的方法，包括附加的步驟 -從所述網(wǎng)絡(luò)節(jié)點接收關(guān)于如何確定緩沖器大小的指令(27)。
16.根據(jù)權(quán)利要求1至15中任一項所述的方法，其中對緩沖器大小的確定在所述無線 通信系統(tǒng)中被預先配置。
17.—種適于將緩沖器狀態(tài)報告給網(wǎng)絡(luò)節(jié)點的用戶設(shè)備(100)，所述用戶設(shè)備和所述 網(wǎng)絡(luò)節(jié)點被包含在無線通信系統(tǒng)中，所述用戶設(shè)備包括與無線電承載相關(guān)聯(lián)的數(shù)據(jù)緩沖器 (110)，以及用于確定所述數(shù)據(jù)緩沖器中的將被傳送到網(wǎng)絡(luò)節(jié)點的可供傳送的數(shù)據(jù)的裝置(120)；其特征在于所述用戶設(shè)備包括用于確定無線電承載的配置的裝置(130)；用于基于數(shù)據(jù)緩沖器中的數(shù)據(jù)和無線電承載的配置中的至少之一來確定緩沖器大小 的裝置(140)；以及用于將包括緩沖器大小的緩沖器狀態(tài)報告給網(wǎng)絡(luò)節(jié)點的傳送機(150)。
18.根據(jù)權(quán)利要求17所述的用戶設(shè)備，其中所述無線電承載被確定為未以首部壓縮進 行配置并且所述緩沖器大小被確定為可供傳送的數(shù)據(jù)的大小。
19.根據(jù)權(quán)利要求17或18中任一項所述的用戶設(shè)備，包括用于確定無線電承載類型、數(shù)據(jù)服務類型、數(shù)據(jù)協(xié)議類型和分組大小中的至少之一的 裝置(160)；用于基于可供傳送的數(shù)據(jù)、無線電承載的配置、無線電承載類型、數(shù)據(jù)服務類型、數(shù)據(jù) 協(xié)議類型和分組大小中的至少之一來確定緩沖器大小的裝置(140)。
20.根據(jù)權(quán)利要求17或19中任一項所述的用戶設(shè)備，其中所述無線電承載被確定為以 首部壓縮進行配置并且可供傳送的數(shù)據(jù)包括部分未壓縮的數(shù)據(jù)和部分經(jīng)壓縮的數(shù)據(jù)。
21.根據(jù)權(quán)利要求20所述的用戶設(shè)備，其中所述緩沖器大小被確定為未壓縮的數(shù)據(jù)的 大小和經(jīng)壓縮的數(shù)據(jù)的未壓縮版本的大小的總大小。
22.根據(jù)權(quán)利要求20所述的用戶設(shè)備，其中所述緩沖器大小被確定為經(jīng)壓縮的數(shù)據(jù)的 大小。
23.根據(jù)權(quán)利要求20所述的用戶設(shè)備，其中所述緩沖器大小被確定為未壓縮的數(shù)據(jù)的 大小和經(jīng)壓縮的數(shù)據(jù)的大小的總大小。
24.根據(jù)權(quán)利要求20至23中任一項所述的用戶設(shè)備，其中所述無線電承載類型是以 RLC-AM或RLC-UM配置的無線電承載。
25.根據(jù)權(quán)利要求22所述的用戶設(shè)備，其中所述數(shù)據(jù)協(xié)議類型是RTP。
26.根據(jù)權(quán)利要求21所述的用戶設(shè)備，其中所述數(shù)據(jù)協(xié)議類型是TCP。
27.根據(jù)權(quán)利要求21所述的用戶設(shè)備，其中所述分組大小大于預定值。
28.根據(jù)權(quán)利要求22所述的用戶設(shè)備，其中所述分組大小小于或等于預定值。
29.根據(jù)權(quán)利要求21所述的用戶設(shè)備，其中所述數(shù)據(jù)服務類型是盡力服務類型。
30.根據(jù)權(quán)利要求22所述的用戶設(shè)備，其中所述數(shù)據(jù)服務類型是實時服務類型。
31.根據(jù)權(quán)利要求17至30中任一項所述的用戶設(shè)備，包括用于從所述網(wǎng)絡(luò)節(jié)點接收關(guān)于如何確定緩沖器大小的指令的裝置(170)。
32.根據(jù)權(quán)利要求17至31中任一項所述的用戶設(shè)備，其中對緩沖器大小的確定在所述 無線通信系統(tǒng)中被預先配置。
全文摘要
本發(fā)明涉及無線通信系統(tǒng)，并且更具體來說涉及用于在無線通信系統(tǒng)中周期性地報告緩沖器狀態(tài)的方法和設(shè)備。提供了用于考慮到無線電承載配置的類型的改進的緩沖器狀態(tài)報告的方法和設(shè)備。根據(jù)本發(fā)明的實施例，這通過在確定由UE發(fā)送給eNodeB的緩沖器狀態(tài)報告的內(nèi)容時考慮到無線電承載配置的類型來實現(xiàn)。
文檔編號H04W72/12GK101843157SQ200880114172
公開日2010年9月22日 申請日期2008年10月30日 優(yōu)先權(quán)日2007年11月1日
發(fā)明者G·佩萊蒂爾, J·佩薩, M·林德斯特倫 申請人:愛立信電話股份有限公司