專利名稱：使用傳輸窗口的通信系統(tǒng)中的優(yōu)化分組數(shù)據(jù)傳輸協(xié)議的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及分組數(shù)據(jù)的傳輸和重傳，尤其涉及在使用傳輸窗口的 無線通信系統(tǒng)中的分組數(shù)據(jù)傳輸協(xié)議。
背景技術(shù)：
以數(shù)據(jù)分組的形式在數(shù)字通信網(wǎng)絡(luò)中傳輸數(shù)據(jù)，典型地是使用協(xié) 議棧方案來執(zhí)行。協(xié)議通過分層次的協(xié)議層來組織數(shù)據(jù)傳輸，協(xié)議層 聚合在一起被稱為協(xié)議棧。層的層次典型地從物理層(其指示其中每 個比特是發(fā)射的方式)向上延伸到應(yīng)用層，在應(yīng)用層決定例如高等級 的計算機(jī)程序之間怎樣相互作用。
協(xié)議棧的中間層的一個例子是邏輯鏈路控制(LLC)層，它控制 穿過網(wǎng)絡(luò)中單組織鏈路的數(shù)據(jù)傳輸。例如，在根據(jù)通用移動電話標(biāo)準(zhǔn) (UMTS)的蜂窩無線通信系統(tǒng)中，在LLC層，單組織鏈路存在于無線 網(wǎng)絡(luò)控制器(RNC)和用戶設(shè)備之間，用戶設(shè)備通常為諸如移動電話 的移動站(MS)，而在物理層，物理連接由第一物理鏈路(Iub)以及 第二物理鏈路(Uu)來實現(xiàn)，所述第一物理鏈路(Iub)是從RNC到 中間物理實體，被稱為Node-B (在UMTS技術(shù)中用作基站收發(fā)站)； 所述第二物理鏈路(Uu)是從Node-B到MS。在前面的例子中，RNC 可能是分組控制單元(PCU)或鏈路層的發(fā)射終端(Tx-終端)，并且 MS為接收終端(Rx-終端)。協(xié)議棧中的各層可以相互獨立地操作。
在LLC鏈路層，被稱為自動重復(fù)請求(ARQ)的機(jī)制為數(shù)據(jù)傳輸 提供錯誤控制機(jī)制，其允許Rx-終端周期性的警告Tx-終端所已經(jīng)接收 到的數(shù)據(jù)分組是否正確或錯誤。這樣，Tx-終端可以重新發(fā)射在前面的 周期傳輸出錯的分組。Rx-終端發(fā)送的信息為確認(rèn)/否定確認(rèn)(ACK/NACK) 。 ACK/NACK 消息包括在前傳輸?shù)姆纸M數(shù)據(jù)單元(PDU)的ACK/NACK狀態(tài)，分組 數(shù)據(jù)單元也稱為數(shù)據(jù)分組或塊，由Tx-終端發(fā)射到Rx-終端。接收到 ACK/NACK信息時，Tx-終端能夠重新發(fā)射那些Rx-終端報告的接收錯 誤(NACKed)的分組；典型地，最早被報告錯誤接收的PDU最先重 新發(fā)射。在這種方案中，當(dāng)嘗試傳輸實時(RT)業(yè)務(wù)時便會出現(xiàn)一些 問題。
當(dāng)端對端(ETE)連接建立時，某些業(yè)務(wù)質(zhì)量(QoS)需求要進(jìn)行 協(xié)商，比如，分組傳輸時間延遲，保障的比特率和其中的優(yōu)先權(quán)。典 型的，傳輸時間延遲相對于諸如傳輸控制協(xié)議(TCP)分段的傳播層協(xié) 議分組的傳送來限定。當(dāng)網(wǎng)絡(luò)有若干鏈路時，時間延遲會被分解為用 于每個鏈接的特定值，比如，當(dāng)涉及無線的無線接入網(wǎng)(RAN)時， 時間延遲中一個特殊的比例將為空中接口而擱置。為了滿足整個ETE QoS的要求，每個鏈路需要達(dá)到各自的QoS要求。
實時(RT)業(yè)務(wù)，例如語音和視頻的傳遞時間延遲，是業(yè)務(wù)的關(guān) 鍵QoS需求之一，因為以較低的時間延遲變化支持連續(xù)的數(shù)據(jù)流對于 支持可用業(yè)務(wù)是很重要的。典型地，在不支持重傳時，就使用諸如用 戶數(shù)據(jù)報協(xié)議(UDP)的傳輸協(xié)議。這是因為沒有足夠的時間在傳播 層重新發(fā)射分組，因此這樣的業(yè)務(wù)必然有一定程度的分組錯誤或丟失 容忍度。然而對于非實時(NRT)業(yè)務(wù)是不一樣的，其中傳輸?shù)乃?數(shù)據(jù)都是需要的。因此支持重傳的協(xié)議典型的用于這樣的業(yè)務(wù)，例如 TCP。
在空中接口，連接被分配為電路交換(cs)連接或分組交換(PS) 連接中的一種。因為可以提供復(fù)用增益，而不捆綁到專用的cs資源，
PS連接的使用可以更加有效的利用空中接口。典型的，例如可以容許 高時間延遲變化的網(wǎng)頁瀏覽或FTP文件傳輸?shù)腘RT業(yè)務(wù)，被映射到PS承載(PS bearer)。然而，比如IP電話(VoIP)，無線一鍵通(PoC) 以及甚至視頻中，存在將更多的RT業(yè)務(wù)映射到PS承載的趨勢。因此 在PS域需要支持QoS保障。
無線網(wǎng)絡(luò)比相應(yīng)的有線網(wǎng)絡(luò)更容易出現(xiàn)高得多的錯誤率。實際上， 有線網(wǎng)絡(luò)中的丟包常常是由于節(jié)點處的緩沖溢出，即擁塞，而不是實 際的解碼錯誤。結(jié)果是PS域的、用來通過空中接口傳播更高層分組的 無線鏈路控制(RLC)協(xié)議，常常在用戶面運(yùn)行在確認(rèn)模式(AM)。 只要沒有超出QoS時間延遲預(yù)算，重傳是容許的。
首先，應(yīng)該注意到這些問題適用于任何使用傳輸窗口的傳輸協(xié)議， 例如無線鏈路控制(RLC)和TCP。因為目前在移動缺少對于RT和 NRT業(yè)務(wù)分離的RLC連接的支持，到GPRS中的應(yīng)用特別相關(guān)與以上 問題，因此，必須要在一個臨時塊流(TBF)下支持上述兩種業(yè)務(wù)。如 前面所述，典型的過程是在不支持重傳的協(xié)議下支持RT業(yè)務(wù)，然而在 移動的電池功率需要節(jié)省的情況下，維護(hù)多個TBF可能被認(rèn)為是效率 較低的。在這種情況下，RT和NRT都要使用維持NRT電信業(yè)務(wù)期望 的可靠性且允許RT業(yè)務(wù)滿足它們的傳輸時間延遲保障的協(xié)議。
由于在發(fā)射和接收相應(yīng)的確認(rèn)狀態(tài)之間的往返時間，重傳的一個 問題是它們需要時間。即使應(yīng)用了降低不滿足QoS需求幾率的機(jī)制， 仍然存在重傳率過高的可能。另外，由于傳輸窗口大小有限，當(dāng)前分 組之后的更高層的分組被攔截，直到當(dāng)前分組從傳輸窗口中清除。這 在GPRS網(wǎng)絡(luò)中尤其難以解決，因為3GPP規(guī)范只允許在原始編碼方案 下的RLC塊的重傳(以更加魯棒的編碼方案重新發(fā)射RLC塊需要更多 的RLC塊來發(fā)射，由于這樣可能超出了窗口的大小，所以不能被在移 動中的RLC實體識別)，這就意味著如果信道條件下降，重傳的錯誤 率會甚至高于原始傳輸?shù)腻e誤率。3GPP GPRS規(guī)范沒有提供改進(jìn)傳輸 窗口的方法，而是為接收實體提供用來指示發(fā)射實體正經(jīng)歷拖延(stall) 的機(jī)制(在確認(rèn)的報頭中提供的指示位)。然而，更有可能的是在信息獲得之前傳輸窗口已經(jīng)被拖延。所有的發(fā)射實體能做的就是重新發(fā) 射被否定確認(rèn)的數(shù)據(jù)塊或重新發(fā)射那些沒有接收到任何確認(rèn)的塊。
重傳的另外一個問題是只有在存在窗口中最早的塊已經(jīng)被肯定確 認(rèn)時，下一個傳輸窗口中的新的數(shù)據(jù)塊才可以發(fā)射。因此，因為這些 塊在傳輸窗口之外，如果最早的塊沒有得到確認(rèn)，當(dāng)沒有新的數(shù)據(jù)塊 可以被發(fā)射時，將到達(dá)一個點。這就是提到的拖延(stall)的情況。結(jié) 果是所有緩存的塊都被攔截(因為他們不能跳過隊列)，因而形成加
長的隊列時間延遲。這樣，不僅高層分組的QoSTD需求被損害，而且 整個會話的QoS TD需求也被損害到的可能性會進(jìn)一步增加。
此外，當(dāng)RT和NRT會話復(fù)用同一個空中接口連接的情況下，在 RLC中，很可能是RTLLC幀排在NRTLLC幀之后。目前還沒有已知 的方法提前終止NRT LLC傳輸來提高用于滿足RT會話的QoS保障的 幾率。
因此有必要在本發(fā)明的領(lǐng)域中解決使用傳輸窗口的傳輸協(xié)議的缺 陷，從而提高滿足QoS保障的幾率。

發(fā)明內(nèi)容
綜上所述，本發(fā)明試圖適當(dāng)?shù)亟档汀p少或者消除上述一個或多 個缺陷的單個或其任意組合。
本發(fā)明的第一個方面，提供一種分組數(shù)據(jù)傳輸協(xié)議的方法，如權(quán) 利要求1所述。
本發(fā)明的第二個方面，提供一種分組數(shù)據(jù)傳輸協(xié)議的裝置，如權(quán) 利要求8所述。
本發(fā)明的第三個方面，提供一種分組數(shù)據(jù)傳輸協(xié)議的系統(tǒng)，如權(quán)利要求15所述。
本發(fā)明的第四方面，提供一種存儲介質(zhì)，如權(quán)利要求23所述。 更多的方面限定在從屬權(quán)利要求中。
根據(jù)本發(fā)明，為防止拖延的情況，包括至少報頭信息的虛擬的RLC
塊被作為重新發(fā)射塊以較低的編碼速率發(fā)送，來提高用戶設(shè)備接收新
的數(shù)據(jù)塊的幾率。盡管LLC層將使塊的日期無效，但是由于LLC層有 了恢復(fù)的替代方式，這樣比拖延情況要好。


現(xiàn)在僅作為舉例的，參考相應(yīng)的附圖來描述本發(fā)明的實施例，其
中
圖1為根據(jù)現(xiàn)有技術(shù)在蜂窩通信系統(tǒng)中執(zhí)行數(shù)據(jù)分組的傳輸和重 傳的示意圖2為本發(fā)明實施例中協(xié)議棧的協(xié)議層的示意圖3為根據(jù)本發(fā)明的協(xié)議的示意圖；以及
圖4為示出本發(fā)明實施例中采用的處理步驟的流程圖。
具體實施例方式
下面的描述主要關(guān)注于可應(yīng)用在蜂窩通信系統(tǒng)中的本發(fā)明的實施 例，所述蜂窩通信系統(tǒng)使用GPRS提供實時業(yè)務(wù)。但是，應(yīng)當(dāng)理解的 是，本發(fā)明不限于該應(yīng)用，而是可以應(yīng)用到許多其他的使用受到傳輸 時間延遲不利影響的業(yè)務(wù)的蜂窩通信系統(tǒng)中。
一般來說，本發(fā)明可以應(yīng)用到根據(jù)通用移動電話標(biāo)準(zhǔn)(UMTS)的 蜂窩通信系統(tǒng)中。為了幫助理解本實施例，例如，在圖1中給出了這 樣的通信系統(tǒng)1的示意圖。由終端用戶使用的用戶設(shè)備，如移動站(MS) 2，經(jīng)由根據(jù)UMTS規(guī)范的Uu接口操作的無線鏈路6，耦合到基站收發(fā)器，在UMTS中稱為Node-B 4。Node-B 4經(jīng)由根據(jù)UMTS規(guī)范的Iub 接口操作的物理鏈路(如，陸線)10，耦合到無線網(wǎng)絡(luò)控制器(RNC) 8。 RNC8經(jīng)由根據(jù)UMTS規(guī)范的Iu接口操作的物理鏈路(如，陸線) 14，耦合到，例如，互聯(lián)網(wǎng)的核心網(wǎng)絡(luò)12。
本實施例涉及數(shù)據(jù)分組，該數(shù)據(jù)分組從分組控制單元(PCU)， 如RNC 8，發(fā)送到MS2，并且如此，PCU代表LLC層的發(fā)射終端， MS2代表鏈路層(見圖2的示例)的接收終端。從RNC8到MS2的 相應(yīng)的物理層在MS 2和Node-B 4中實現(xiàn)，Node-B形成MS 2和RNC 8之間的物理層的中間物理實體。
實現(xiàn)中轉(zhuǎn)終端鏈路層的RNC 8，通過陸線10連接到執(zhí)行物理層的 發(fā)射終端的Node-B 4。圖l示意性的示出原始的，即新的數(shù)據(jù)分組塊 16，該數(shù)據(jù)分組塊16被從RNC8發(fā)送到MS2。
對于每個數(shù)據(jù)分組，MS 2返回ACK/NACK消息18給RNC，所 述ACK/NACK消息18即確認(rèn)(在正確接收的情況下)或否定確認(rèn)(字 啊沒有正確接收的情況下)。ARQ機(jī)制可以從RNC 8或者可選的從 Node-B 4通過有組織地只使用鏈路層，在無線鏈路控制(RLC)層協(xié) 議下操作。RNC或者Node-B可以在物理層接收到分組數(shù)據(jù)后，在給定 的有限時間內(nèi)在高速緩沖存儲器存儲該分組，這樣被否定確認(rèn)的數(shù)據(jù) 分組20可以被重新發(fā)射到MS 2。
圖2顯示了根據(jù)本發(fā)明的適合執(zhí)行數(shù)據(jù)分組塊的傳輸?shù)膮f(xié)議棧配 置28 (用于圖4中的系統(tǒng))。協(xié)議棧的Rx-終端30 (相應(yīng)的為MS2) 包括鏈路層32和物理層34。協(xié)議棧的Tx-終端36 (相應(yīng)的為RNC 8) 包括LLC鏈路層38。轉(zhuǎn)發(fā)終端物理層在稱做Node-B 4的中間物理實 體中實現(xiàn)，并且這加入到協(xié)議棧附加物理層部分46，如圖2所示。在 本實施例中，存在與物理層相關(guān)的Tx-終端鏈路層高速緩沖存儲器42， 其可以位于Node-B或RNC中(如圖中所示的)。將在下面描述的用于實現(xiàn)上述布置，以及執(zhí)行方法步驟的裝置， 釆用傳統(tǒng)裝置和/或提供附加的模塊。具體地，附加裝置可以在中間物
理實體處提供，即在Node-B 4。裝置可以是硬件、固件、軟件或上述 相結(jié)合的形式。裝置包括一個或多個處理器，用于執(zhí)行指令以及使用 存儲在存儲介質(zhì)中，如計算機(jī)硬盤或PROM中的數(shù)據(jù)。
圖3示意性示出了適合根據(jù)本實施例操作的裝置和通信系統(tǒng)。如 上的，原始的，即新的數(shù)據(jù)分組16，被從分組控制單元(PCU)發(fā)射 實體(例如，Node-B 4或RNC 8)發(fā)送到用戶設(shè)備(UE) MS 2。同 樣如上的，對于每一個數(shù)據(jù)分組，MS 2返回ACK/NACK消息1S給 PCU，所述ACK/NACK消息18即確認(rèn)(在正確接收情況下)或否定 確認(rèn)(在沒有正確接收的情況下)。然而，對比圖1中的過程，本發(fā) 明根據(jù)觸發(fā)事件60發(fā)射虛擬數(shù)據(jù)分組(即RLC)塊62，其至少具有報 頭身份。
根據(jù)本發(fā)明，當(dāng)滿足一定的觸發(fā)條件時，發(fā)射實體(如包括Node-B 或RNC 二者之一的分組控制單元(PCU))用只包含相關(guān)報頭信息(以 最小的方式)的虛擬塊替代了需要重傳的錯誤塊。在GPRS的情況下， 虛擬塊以更加魯棒(即較低)的編碼機(jī)制進(jìn)行編碼，優(yōu)選最魯棒的編 碼機(jī)制。在TCP的情況下，建議將負(fù)載減少到最小。在上述任意一種 情況下，對下一個傳輸窗口來說都有好處，由此去除了拖延情況(被 動地)或者降低了拖延發(fā)生的幾率(主動地)。
在TCP的情況下，由于較短的分組的傳輸時間延遲會更低，因而 達(dá)到這一目的。對于GPRS，由于更加魯棒的編碼方案具有更大的成功 傳輸?shù)母怕?，也可以達(dá)到這一目的。本發(fā)明可以應(yīng)用于任何GPRS臨 時塊流(TBF),而不用考慮所正在傳播的是RT、 NRT或兩種會話類 型的組合。當(dāng)重組更高層的PDU (在GPRS情況下的LLC幀)時，在 虛擬塊中的"無含義"信息被傳遞到更高的LLC層。實際上，PCU以較低的編碼速率發(fā)送虛擬RLC塊，所述虛擬RLC 塊具有最小的至少合適的報頭ID。因為較低的編碼率在較低的編碼速 率下會產(chǎn)生較大的編碼長度，這不能容納在定時窗口中。因此，只能 發(fā)送報頭和已知的只要適合RLC時間的任何其他數(shù)據(jù)。在接收到虛擬 塊時，MS就知道將切換到新的、更加魯棒的編碼方案來接收新的RLC 塊。虛擬塊被傳遞到MS的LLC層，MS決定該塊無效，并將其丟棄。 幸運(yùn)的是，LLC層(圖2中的32)與物理層(圖2中的34)獨立地操 作，物理層以新的速率處理新塊的下載，這樣就防止了RLC拖延。
余下的描述偏向于GPRS系統(tǒng)，不過基本原理可以應(yīng)用到任何無 損的傳輸協(xié)議。
對于GPRS，虛擬塊利用相同的RLC塊ID來構(gòu)造，以便于如果塊 被無誤的接收時(由于使用了更加魯棒的編碼方案，這種情況很有可 能)，則接收實體在RLC層會有效地"被欺騙"而相信實際的信息塊已 經(jīng)被正確接收。另外，虛擬RLC塊可以這樣構(gòu)造，使得長度指示符字 段精確指示RLC數(shù)據(jù)字段的長度，所述RLC數(shù)據(jù)字段包含用來發(fā)射虛 擬塊的編碼方案的(剩余的)假設(shè)的LLCPDU?？蛇x地，長度指示符 可以設(shè)置為0來指示LLC PDU已經(jīng)由RLC塊不完全地發(fā)射。另一個 實施例以更加魯棒的編碼方案來編碼原始的RLC塊信息，當(dāng)新的RLC 塊沒有足夠的空間時，截短LLC PDU (因為只有一個LLC幀可能被壓 縮，當(dāng)RLC塊中包含來自一個以上LLC幀的信息時，這種方法極為優(yōu) 越)。
具有在虛擬塊中包含的信息的LLC PDU的重構(gòu)，根據(jù)下面3GPP TS 44.064第5.8款嚴(yán)格的規(guī)范，會導(dǎo)致無效LLC幀
1.根據(jù)控制字段的內(nèi)容，LLC幀包含比包括以下字段所需的更 少的八位字節(jié)，所述字段為構(gòu)成一個完整的幀所需的幀檢查序列(FCS)字段、地址字段、控制字段、和信息字段。
2. LLC幀包括FCS錯誤。
無效的LLC幀被丟棄，而不通知發(fā)送方。對于該幀不做進(jìn)一步的 反應(yīng)。
有效地丟棄RLC PDU，并且從而破壞了正被傳播的LLC幀，而 導(dǎo)致了LLC幀的丟棄，以上是優(yōu)選的用來損害整個會話的QoS TD要 求。RT可以容許一定的錯誤率，實際上，業(yè)務(wù)數(shù)據(jù)單元(SDU)錯誤 比率，作為用于分組數(shù)據(jù)流上下文(PFC)的QoS保障的一部分，也 要進(jìn)行協(xié)商。另外，NRT業(yè)務(wù)常常使用更高層傳輸協(xié)議，如TCP，來 修復(fù)這樣的錯誤(通過重傳)。
根據(jù)本發(fā)明，有幾種情況會觸發(fā)傳輸虛擬RLC塊。示例包括，但 不限于
1) 當(dāng)用于下一個窗口中的RLC塊的編碼方案低于用于當(dāng)前窗口 中的RLC塊的編碼方案時。
2) 當(dāng)發(fā)生RLC窗口拖延，該拖延超過計時器所確定的時間段時， 所述計時器當(dāng)要求第一重傳時被設(shè)置，并且當(dāng)分組輪詢請求(Packet Polling Request)不再接收用于RLC塊的更多請求時被重新設(shè)置。當(dāng)計 時器超時時，發(fā)送虛擬RLC數(shù)據(jù)塊。
3) 當(dāng)確定拖延情況已經(jīng)結(jié)束時，例如，由于丟棄分組的一般操 作過程，在傳輸窗口中新的塊的數(shù)量減少到一定數(shù)量/整個大小的一定 百分比之下時。
4) 當(dāng)RTLLC幀的傳輸排在NRTLLC幀之后時，然后，可以采用這種方法對NRT LLC幀進(jìn)行RLC重傳，用來從RLC窗口中清除NRT IXC幀。
5)如果預(yù)測到當(dāng)前RTLLC幀的TD要求不能滿足時，那么，沒 有必要通過錯誤的重傳引起更多的時間延遲，并且因此，重傳可以被 限定在最魯棒的編碼方案，用來清除該LLC幀。這樣可以減小以后的 RT LLC幀也達(dá)不到TD要求的可能性。
在特定的實施方式中，這些或其他項可以激活或禁止。
這種技術(shù)可能的副作用表現(xiàn)在感知的誤塊率；因為可以看到在更 加魯棒的編碼方案中導(dǎo)致的錯誤率的改善。問題是通常使用誤塊率估 計作為鏈路適應(yīng)(編碼方案選擇)算法的一部分，因此樂觀的誤塊率 估計可能使鏈路適應(yīng)算法錯誤地增加所選定的編碼方案。然而，通過 接收實體提供需要的誤塊率位圖報告(發(fā)送關(guān)于的每個塊的錯誤狀態(tài) 的報告)，在GPRS中可以克服這一點。由于這樣做發(fā)射實體知道哪 個塊被降低到較低的編碼方案，并且在誤塊率統(tǒng)計時將其排除。
參考圖3，本發(fā)明提供了一種方法，通過該方法，當(dāng)通過參數(shù)， 如傳輸時間延遲或傳輸窗口拖延的結(jié)束的測量，確認(rèn)更高層分組或數(shù) 據(jù)傳輸?shù)腝oS的目標(biāo)作為一個整體被損害時，只是重新發(fā)送用于傳輸 塊重傳的報頭信息(作為最小的)(用以激活用于無丟失傳輸協(xié)議的 傳輸窗口的優(yōu)點)。
如現(xiàn)有技術(shù)已知的，第一個步驟100包括發(fā)射第一個傳輸窗口中 的數(shù)據(jù)分組塊。
下一個步驟102包括對于所發(fā)射的數(shù)據(jù)分組，接收至少一個否定 確認(rèn)(NACK)。該NACK為上述傳輸窗口指示已經(jīng)存在拖延或即將 發(fā)生拖延。下一個步驟104包括為協(xié)議建立觸發(fā)，其中只有基于觸發(fā)事件， 才進(jìn)行下面的步驟。本步驟可以發(fā)生在該方法中的任何處。觸發(fā)事件 本身已經(jīng)在前面做了描述。如果任何一個觸發(fā)事件都不滿足105，那么
如現(xiàn)有技術(shù)已知的，處理繼續(xù)重傳塊103。
基于觸發(fā)事件105，下一個步驟106包括構(gòu)造虛擬數(shù)據(jù)分組(即， 無線鏈路控制(RLC))塊，其包括至少一個報頭身份。
下一個步驟108包括發(fā)送虛擬RLC塊，該虛擬RLC塊以比原始 發(fā)送的數(shù)據(jù)分組所使用的更魯棒的編碼速率發(fā)送。
下一個步驟IIO包括接收用于虛擬RLC塊的確認(rèn)，其中用戶設(shè)備 重新配置以新的編碼速率接收分組。
下一個步驟112包括從下一個傳輸窗口以新的編碼速率發(fā)射新的 數(shù)據(jù)分組塊，從而防止如前面詳述的對于RLC塊的拖延的情況。
在本發(fā)明的研究中，除GPRS系統(tǒng)之外，任何其他使用傳輸窗口 的無線網(wǎng)絡(luò)，都可以從這里描述的技術(shù)中獲益，其中所述傳輸窗口使 用無損傳輸協(xié)議。這樣的協(xié)議包括RLC和TCP。
可以理解本發(fā)明有以下優(yōu)點
(i) 關(guān)于GPRS，為了克服在GPRS上的冗長的RLC拖延，經(jīng) 由以更加魯棒的編碼方案傳輸RLC塊，來模擬將需要重新發(fā)射的RLC 塊，本發(fā)明激活了 LLC幀的丟棄。目前在GPRS規(guī)范中還沒有已知的 方法可以取得這樣的效果；
(ii) 在本發(fā)明之前，GPRSRLC塊的重傳是基于相同的編碼方案和錯誤保護(hù)來發(fā)生的。這會引起RLC窗口拖延，特別是當(dāng)原始傳輸 和重傳之間的時間段內(nèi)無線鏈路條件惡化時。因為當(dāng)無線條件惡化時 正好是會經(jīng)常產(chǎn)生重傳的時候，因此上述情況經(jīng)常會發(fā)生，并且，在 無線鏈路條件一直很差的同時，重傳的成功率也很低；
(iii) 類似的，對于TCP，在每一個分組中TCP的末端表示了 目前窗口中可用的空間，如果減去已經(jīng)發(fā)送到系統(tǒng)中的任何未確認(rèn)數(shù) 據(jù)的該窗口大小為零，則便不能發(fā)送數(shù)據(jù)；以及
(iv) 在本發(fā)明之前，當(dāng)TCP窗口的太小而不能讓分組穿過鏈路 時，TCP重傳將會發(fā)生拖延，并且當(dāng)窗口已滿之后，對于要發(fā)送的下 一個分組，確認(rèn)不能被及時發(fā)送和接收。往返時間(RTT)受到TCP 分組大小和分組需要穿過的跳(hop)(以及每跳中的隊列時間延遲) 的數(shù)目的影響。減小TCP分組的大小就縮短了 RTT，從而允許對于給 定的窗口大小發(fā)射更多的分組。
應(yīng)當(dāng)理解的是，為了清晰起見，上面的描述參考了了不同的功能 單元和處理器來描述了本發(fā)明的實施方式。然而，顯然可以使用任何 合適的在不同功能單元或處理器之間的功能上的分配，而不影響本發(fā) 明。比如，分離的處理器或控制器執(zhí)行的功能可以由同一個處理器或 控制器執(zhí)行。因此，特定的功能單元只是作為用來提供所述功能的合 適裝置的參考，而沒有用于指示嚴(yán)格的邏輯或物理結(jié)構(gòu)或組織。
本發(fā)明可以以任何合適的形式實現(xiàn)，包括硬件、軟件、固件或上 述任意組合。本發(fā)明可以選擇性地至少部分的作為計算機(jī)軟件，在一 個或多個數(shù)據(jù)處理器和/或數(shù)字信號處理器上運(yùn)行。本發(fā)明實施例中的 元件和組件可以被物理的、功能的和邏輯的，以任何合適的形式實現(xiàn)。 實際上，功能可以在單個單元、多個單元或其他功能單元的一部分中 實現(xiàn)。這樣，本發(fā)明的可以在單個單元中實現(xiàn)或在物理地和功能地上 分布在不同的單元和處理器之間。盡管本發(fā)明結(jié)合了一些實施例來描述，但不旨在局限于這里描述 的特定形式。相反，本發(fā)明的范圍僅由附加的權(quán)利要求限定。另外， 盡管看起來已經(jīng)結(jié)合特定的實施例而描述了特征，本領(lǐng)域技術(shù)人員應(yīng) 當(dāng)明了，描述的實施例中不同的特征可以根據(jù)本發(fā)明相互組合。在權(quán) 利要求書中，術(shù)語"包括"并不排除其他元件或步驟的存在。
此外，盡管是單個地列出，多種裝置、元件或方法步驟可以由例
如單個單元或處理器實現(xiàn)。另外，盡管單個的特征包括在不同的權(quán)利
要求中，這些特征可以方便地組合，不同權(quán)利要求中的內(nèi)容也不意味
著特征的組合不可行和/或不方便的。同樣，在同一組權(quán)利要求中的特
征的內(nèi)含物也不意味著限定在該組權(quán)利要求中，而是應(yīng)理解為該特征
可以平等的應(yīng)用到其他的權(quán)利要求組中。而且，權(quán)利要求中的特征的
順序也不意味著特征必須按照特定的順序來工作，并且，方法權(quán)利要 求中的單個的步驟的順序也不意味著必須按照該順序執(zhí)行步驟。相反，
可以以任何合適的順序執(zhí)行步驟。
權(quán)利要求
1. 一種用于使用傳輸窗口的分組數(shù)據(jù)傳輸協(xié)議的方法，所述方法包括以下步驟從第一傳輸窗口中發(fā)射數(shù)據(jù)分組塊；接收關(guān)于所發(fā)射數(shù)據(jù)分組的至少一個否定確認(rèn)；構(gòu)造包括至少報頭信息的虛擬數(shù)據(jù)分組塊；以比原始發(fā)射的數(shù)據(jù)分組使用的編碼速率更加魯棒的編碼速率發(fā)送所述虛擬塊；接收關(guān)于所述虛擬塊的確認(rèn)；以及從下一個傳輸窗口中發(fā)射新的數(shù)據(jù)分組塊。
2. 如權(quán)利要求l所述的方法，其中所述虛擬數(shù)據(jù)分組塊為虛擬無 線鏈路控制(RLC)塊。
3. 如權(quán)利要求l所述的方法，進(jìn)一步包括建立所述協(xié)議的觸發(fā)的 步驟，其中只有當(dāng)所述觸發(fā)的事件發(fā)生時，才發(fā)生所述構(gòu)造和發(fā)送步 驟。
4. 如權(quán)利要求3所述的方法，其中所述觸發(fā)包括從下面的組中選 擇的情況當(dāng)所接收到的否定確認(rèn)引起了出現(xiàn)超過預(yù)定時間段的RLC窗口拖延時；當(dāng)所述傳輸窗口中的新塊數(shù)量減少到指示即將發(fā)生拖延情況的預(yù) 定界限以下時；當(dāng)實時(RT)邏輯鏈路控制(LLC)幀的傳輸排列在非實時(NRT) LLC幀之后時；以及當(dāng)確定當(dāng)前所述實時(RT)邏輯鏈路控制(LLC)幀的時間延遲 要求不能滿足時。
5. —種用于使用傳輸窗口的分組數(shù)據(jù)傳輸協(xié)議的裝備，所述裝備包括用于從第一傳輸窗口中發(fā)射數(shù)據(jù)分組塊的裝置； 用于接收關(guān)于所發(fā)射數(shù)據(jù)分組的至少一個否定確認(rèn)的裝置； 用于構(gòu)造虛擬數(shù)據(jù)分組塊的裝置，所述虛擬數(shù)據(jù)分組塊包括至少 報頭信息；用于以比原始發(fā)射的數(shù)據(jù)分組使用的編碼速率更加魯棒的編碼速 率發(fā)送所述虛擬塊的裝置；用于接收關(guān)于所述虛擬塊的確認(rèn)的裝置；以及 用于從下一個傳輸窗口中發(fā)射新的數(shù)據(jù)分組塊的裝置。
6. 如權(quán)利要求5所述的裝備，其中所述虛擬數(shù)據(jù)分組塊為虛擬無 線鏈路控制(RLC)塊。
7. 如權(quán)利要求5所述的裝備，進(jìn)一步包括建立所述協(xié)議的觸發(fā)的 裝置，其中只有當(dāng)所述觸發(fā)的事件發(fā)生時，發(fā)生所述協(xié)議。
8. 如權(quán)利要求7所述的裝備，其中所述觸發(fā)包括下面組中的一個當(dāng)所述下一個窗口中RLC塊的編碼方案比當(dāng)前窗口中RLC塊使用的編碼方案更魯棒時的情況；當(dāng)所接收到的否定確認(rèn)引起了出現(xiàn)超過預(yù)定時間段的RLC窗口拖延時的情況；當(dāng)所述傳輸窗口中的新數(shù)據(jù)塊的數(shù)量減少到指示即將發(fā)生拖延情 況的預(yù)定界限以下時的情況；當(dāng)實時(RT)邏輯鏈路控制(LLC)幀的傳輸排列在非實時(NRT) LLC幀之后時的情況；以及當(dāng)確定所述當(dāng)前實時(RT)邏輯鏈路控制(LLC)幀的時間延遲 要求不能滿足時的情況。
9. 一種用于使用傳輸窗口的分組數(shù)據(jù)傳輸協(xié)議的系統(tǒng)，所述系統(tǒng)包括分組控制單元，用于從第一傳輸窗口中發(fā)送數(shù)據(jù)分組塊；以及 用戶設(shè)備，用于接收所述數(shù)據(jù)分組塊并且向所述分組控制單元通知所述接收，其中如果所述用戶設(shè)備發(fā)送關(guān)于所發(fā)射數(shù)據(jù)分組的至少一個否定確認(rèn)，則所述分組控制單元構(gòu)造包括至少報頭信息的虛擬數(shù)據(jù)分組塊，并且以比原始發(fā)射的數(shù)據(jù)分組使用的編碼速率更加魯棒的編碼速率發(fā)送所述虛擬塊給所述用戶設(shè)備。
10.如權(quán)利要求9所述的系統(tǒng)，進(jìn)一步包括關(guān)于所述協(xié)議的觸發(fā)， 其中只有當(dāng)所述觸發(fā)的事件發(fā)生時，發(fā)生所述協(xié)議。
全文摘要
一種使用傳輸窗口的分組數(shù)據(jù)傳輸協(xié)議，包括從第一傳輸窗口發(fā)射(100)數(shù)據(jù)分組塊的分組控制單元(PCU)(4)、(8)。如果沒有正確接收到分組，用戶設(shè)備(UE)(2)發(fā)送(102)否定確認(rèn)給PCU，于是PCU構(gòu)造(106)虛擬無線鏈路控制(RLC)塊(60)，其包括至少關(guān)于建立(104)的觸發(fā)(60)事件的時間的報頭信息。PCU以更加魯棒的編碼速率發(fā)送(108)虛擬RLC塊來阻止RLC拖延情況。
文檔編號H04L1/00GK101421965SQ200780013752
公開日2009年4月29日 申請日期2007年3月30日 優(yōu)先權(quán)日2006年4月18日
發(fā)明者史蒂文·J·辛普森, 沃爾特·費瑟斯通, 考林·Y·張, 霍華德·J·托馬斯 申請人:摩托羅拉公司