專利名稱：無線鏈路控制層減少冗余報(bào)文重傳的方法及系統(tǒng)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動(dòng)通信領(lǐng)域，特別涉及一種LTE(Long Term Evolution,長(zhǎng)期演化) 系統(tǒng)內(nèi)，無線鏈路控制層協(xié)議實(shí)體的重建過程(Re-establishmentprocedure)中，減少或 避免發(fā)送側(cè)重傳冗余報(bào)文的方法及系統(tǒng)。
背景技術(shù)：
RLC(Radio Link Control,無線鏈路控制)協(xié)議層在LTE的無線接口協(xié)議棧中，是 L2(層2)的一個(gè)子層，位于MAC(Media Access Control,媒體接入控制)層之上，RLC協(xié)議層 為用戶和控制數(shù)據(jù)提供分段和重傳業(yè)務(wù)。RLC協(xié)議層的功能包括鏈接控制、封裝和重組、級(jí) 聯(lián)、用戶數(shù)據(jù)傳輸、糾錯(cuò)、協(xié)議錯(cuò)誤檢測(cè)和修復(fù)等。每個(gè)RLC協(xié)議實(shí)體由RRC(Radio Resource Control，無線資源控制)配置并以三種模式進(jìn)行操作，分別為透明模式(TM，Transparent Mode)、非確認(rèn)模式(UM， Unacknowledged Mode)、確認(rèn)模式(AM， Ack麗ledgedMode)。
確認(rèn)模式中的ARQ(Auto R印eat Request,自動(dòng)重傳請(qǐng)求)，是通過接收端向發(fā) 送端發(fā)送狀態(tài)報(bào)告(Status R印ort)來實(shí)現(xiàn)的，發(fā)送端根據(jù)Status R印ort中的ACK SN、 NACK SN來判定哪些PDU(Protocol Data Unit，協(xié)議數(shù)據(jù)單元)已經(jīng)被接收端確認(rèn)收到， 哪些PDU或PDU片段需要重傳，從而保證數(shù)據(jù)傳輸?shù)目煽啃?。?6. 322協(xié)議中，為了避 免Status R印ort發(fā)送過于頻繁，占用空口資源，在RLC協(xié)議實(shí)體的接收端設(shè)定了一個(gè)T_ status—prohibit(狀態(tài)報(bào)告禁止)定時(shí)器，每發(fā)送一個(gè)Status R印ort后啟動(dòng)該定時(shí)器，在 定時(shí)器運(yùn)行期間，禁止發(fā)送Status R印ort。 在UE(User Equipment,用戶設(shè)備)側(cè)和eNodeB (Evolution NodeB，演進(jìn)基站M則， 對(duì)應(yīng)歸屬于該UE的每一條邏輯信道(Logic Channel) ， UE和eNodeB都會(huì)建立對(duì)等的RLC 協(xié)議實(shí)體，該協(xié)議實(shí)體執(zhí)行RLC協(xié)議層的處理流程。在本文中描述的本端即指UE或eNodeB 中從屬于某一個(gè)UE、并對(duì)應(yīng)一條特定的邏輯信道的RLC協(xié)議實(shí)體，對(duì)端即是上文所指，與該 協(xié)議實(shí)體對(duì)應(yīng)同一條邏輯信道、對(duì)等的RLC協(xié)議實(shí)體。 RLC協(xié)議實(shí)體重建過程(Re-establishment procedure)，指的是RLC協(xié)議實(shí)體，由 高層指示的實(shí)體復(fù)位(Reset)過程，在這個(gè)過程中，涉及到當(dāng)前上、下行報(bào)文的處理、定時(shí) 器的設(shè)置、協(xié)議狀態(tài)變量的改變等一系列相關(guān)流程。本發(fā)明是針對(duì)AM確認(rèn)模式下的重建過 程。 36. 322協(xié)議中，目前對(duì)AM模式的RLC協(xié)議實(shí)體重建過程的描述如圖1所示接 收端接收到RRC的重建指示后，直接將接收滑窗內(nèi)的已接收到的報(bào)文全部投遞給上層，即 PDCP (Packet Data Convergence Protocol,分組數(shù)據(jù)匯聚協(xié)議)層，而無論其是否連續(xù)，此 時(shí)不會(huì)向發(fā)送端發(fā)送Status R印ort。重建完成后，發(fā)送端需要重新發(fā)送接收端沒有回送過 應(yīng)答的報(bào)文。 目前觸發(fā)RLC協(xié)議實(shí)體重建過程的條件包含以下幾類
參切換，由RRC指示；
參RLC協(xié)議層處理異常；
參網(wǎng)絡(luò)情況惡劣，如某個(gè)報(bào)文多次重傳均發(fā)送失敗。 圖2描述了 RLC協(xié)議實(shí)體重建過程中，造成冗余報(bào)文傳輸?shù)脑?。如圖所示，在發(fā) 生重建過程之前，接收端收到了序號(hào)為0、1、2、3、7的報(bào)文，4、5、6缺失。收到上層指示重建， 則接收端會(huì)將0、1、2、3、7這5個(gè)報(bào)文全部向PDCP層投遞。對(duì)PDCP而言，序號(hào)為0、1、2、3 的報(bào)文屬于連續(xù)收到的報(bào)文，可以繼續(xù)向上層投遞，而從序號(hào)4開始，則需在重建后繼續(xù)等 待發(fā)送端重傳的報(bào)文。 然而，在重建過程中，接收端并沒有給發(fā)送端發(fā)送Status R印ort，對(duì)發(fā)送端而言， 序號(hào)從O到7的所有報(bào)文均沒有收到應(yīng)答。RLC協(xié)議實(shí)體重建過程完成后，發(fā)送端會(huì)重新傳 輸序號(hào)從O到7的全部報(bào)文。接收端的RLC協(xié)議實(shí)體復(fù)位后，所有狀態(tài)變量和定時(shí)器歸零， 無法判定這些報(bào)文是重傳還是新發(fā)，所以還是將其投遞到PDCP，由PDCP來判斷報(bào)文是否重 復(fù)。對(duì)PDCP來說，序號(hào)0、1、2、3、7的報(bào)文都是冗余報(bào)文，只能丟棄。從流程上來說，因?yàn)槿?少重建過程中接收端和發(fā)送端的交互，導(dǎo)致那些接收端雖已正確收到、但因發(fā)生重建沒有 發(fā)送Status R印ort從而導(dǎo)致發(fā)送端沒有收到應(yīng)答的報(bào)文被重復(fù)傳輸，浪費(fèi)了空口資源和 協(xié)議層的處理時(shí)間。 在最近的協(xié)議討論文稿CR R2-085804中，去掉了針對(duì)單個(gè)DRB(Data RadioBear， 數(shù)據(jù)無線承載)的重建過程，代之以UE將該UE所有專用DRB全部重建的方式。這也就是 說， 一個(gè)DRB的異常，可能導(dǎo)致多條DRB上的冗余報(bào)文傳輸，從而造成更大的空口資源的浪費(fèi)。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種無線鏈路控制層減少報(bào)文重傳的方 法，用于解決RLC協(xié)議實(shí)體重建后重復(fù)發(fā)送接收端已確認(rèn)接收到的冗余報(bào)文，導(dǎo)致空口資 源浪費(fèi)的技術(shù)問題。 本發(fā)明的核心思想是在觸發(fā)RLC協(xié)議實(shí)體重建過程的條件中，除了切換這一由 高層直接發(fā)起的條件外，其余兩種條件下的重建，都是由RLC通知高層后，再由高層發(fā)起， 由此可知，RLC協(xié)議層可提前預(yù)測(cè)重建是否發(fā)生，因此，在RLC協(xié)議實(shí)體收到重建指示之前 讓歸屬于該UE的每個(gè)數(shù)據(jù)無線承載(DRB)都試圖發(fā)送一個(gè)狀態(tài)報(bào)告(Status R印ort)給 發(fā)送端，發(fā)送端在收到重建請(qǐng)求之前就首先處理掉這些已確認(rèn)收到的報(bào)文，在重建完成后 不再重復(fù)發(fā)送，從而減少冗余報(bào)文重傳。 為達(dá)到上述目的，本發(fā)明的技術(shù)方案是這樣實(shí)現(xiàn)的
—種無線鏈路控制層減少報(bào)文重傳的方法，包括以下步驟 步驟A :在eNodeB或UE側(cè)，當(dāng)對(duì)應(yīng)于某一條邏輯信道的RLC協(xié)議實(shí)體檢測(cè)到觸發(fā) RLC協(xié)議實(shí)體重建的異常時(shí)，通知本端從屬于同一UE的與邏輯信道對(duì)應(yīng)的其它RLC協(xié)議實(shí) 體或僅通知本端從屬于同一 UE的與邏輯信道對(duì)應(yīng)的確認(rèn)模式下的RLC協(xié)議實(shí)體；
在eNodeB側(cè)，歸屬于同一個(gè)UE的多個(gè)RLC協(xié)議實(shí)體通常是運(yùn)行在同一塊單板或 數(shù)字信號(hào)處理器上，在UE側(cè)只包含本UE的RLC協(xié)議實(shí)體。無論是eNodeB側(cè)還是UE側(cè)，檢 測(cè)到觸發(fā)RLC協(xié)議實(shí)體重建異常的RLC協(xié)議實(shí)體可通過函數(shù)調(diào)用、消息通信機(jī)制或全局變 量標(biāo)識(shí)等方式來通知本端其它與邏輯信道對(duì)應(yīng)的RLC協(xié)議實(shí)體，本端需要重建從屬于同一 UE的所有RLC協(xié)議實(shí)體。
步驟B:本端收到通知的處于確認(rèn)模式的無線鏈路控制協(xié)議實(shí)體向?qū)Χ藢?duì)等的 RLC協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告(Status R印ort); 步驟A中，若發(fā)現(xiàn)異常的RLC協(xié)議實(shí)體只通知本端從屬于同一UE的處于確認(rèn)模式 下的RLC實(shí)體，則該步驟不用再判斷當(dāng)前收到通知的RLC協(xié)議實(shí)體是否處于確認(rèn)模式；若步 驟A中，發(fā)現(xiàn)異常的RLC協(xié)議實(shí)體通知本端從屬于同一 UE的所有RLC實(shí)體，則步驟B中還 需要判斷當(dāng)前RLC協(xié)議實(shí)體是否處于確認(rèn)模式，只有處于確認(rèn)模式下的RLC協(xié)議實(shí)體才需 要發(fā)送狀態(tài)報(bào)告。若步驟A中檢測(cè)到觸發(fā)RLC協(xié)議實(shí)體重建異常的RLC協(xié)議實(shí)體也處于確 認(rèn)模式，則該RLC協(xié)議實(shí)體與本端其它處于確認(rèn)模式的RLC協(xié)議實(shí)體都需要向?qū)Χ税l(fā)送狀 態(tài)報(bào)告。 步驟C :所述對(duì)端對(duì)等的RLC協(xié)議實(shí)體收到狀態(tài)報(bào)告后，刪除狀態(tài)報(bào)告中已確認(rèn)收 到的協(xié)議數(shù)據(jù)單元(Protocol Data Unit,PDU)和上層對(duì)應(yīng)的服務(wù)數(shù)據(jù)單元(Service Data Unit,SDU)。 進(jìn)一步地，步驟A中，所述觸發(fā)RLC協(xié)議實(shí)體重建的異常是指協(xié)議處理錯(cuò)誤或報(bào)文 重傳異常； 進(jìn)一步地，步驟B中，本端收到通知的處于確認(rèn)模式的無線鏈路控制協(xié)議實(shí)體無 論其狀態(tài)報(bào)告禁止定時(shí)器(乙status—prohibit定時(shí)器)是否運(yùn)行，都向?qū)Χ藢?duì)等的RLC協(xié) 議實(shí)體發(fā)送一個(gè)狀態(tài)報(bào)告(Status R印ort); 進(jìn)一步地，步驟B中，所述本端收到通知的處于確認(rèn)模式的無線鏈路控制協(xié)議實(shí) 體向?qū)Χ藢?duì)等的RLC協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告的步驟如下 步驟B01、判斷T_status_prohibit定時(shí)器是否運(yùn)行，如果未運(yùn)行，則執(zhí)行步驟 B02 ;若運(yùn)行，則執(zhí)行B03 ; 步驟B02、向?qū)Χ藢?duì)等的RLC協(xié)議實(shí)體發(fā)送Status R印ort，執(zhí)行步驟B05 ;
步驟B03、停止T_status_prohibit定時(shí)器，然后執(zhí)行步驟B04 ;
步驟B04、向?qū)Χ藢?duì)等的RLC協(xié)議實(shí)體發(fā)送Status R印ort ;
步驟B05、重新啟動(dòng)T_status_prohibit定時(shí)器。 本發(fā)明的另一目的在于提供一種無線鏈路控制層減少冗余報(bào)文重傳的系統(tǒng)，包括
UE側(cè)和eNodeB側(cè)，UE側(cè)和eNodeB側(cè)都包括控制面處理單元及用戶面處理單元，用戶面
處理單元中包含一個(gè)或多個(gè)與邏輯信道對(duì)應(yīng)的無線鏈路控制協(xié)議實(shí)體，當(dāng)對(duì)應(yīng)于某一條邏
輯信道的無線鏈路控制協(xié)議實(shí)體檢測(cè)到觸發(fā)無線鏈路控制協(xié)議實(shí)體重建的異常時(shí)，具有通
知本端從屬于同一終端的其它無線鏈路控制協(xié)議實(shí)體或處于確認(rèn)模式的無線鏈路控制協(xié)
議實(shí)體的功能；本端收到通知的處于確認(rèn)模式的無線鏈路控制協(xié)議實(shí)體在接收到所述通知
后，具有向?qū)Χ藢?duì)等無線鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告的功能。 進(jìn)一步地，本發(fā)明所述RLC協(xié)議實(shí)體進(jìn)一步包括 實(shí)體處理模塊，用于實(shí)現(xiàn)RLC協(xié)議實(shí)體的基本功能； 通知模塊，用于當(dāng)對(duì)應(yīng)于某一條邏輯信道的RLC協(xié)議實(shí)體檢測(cè)到觸發(fā)RLC協(xié)議實(shí) 體重建的異常時(shí)通知本端其它從屬于同一 UE的所有RLC協(xié)議實(shí)體； 重建前狀態(tài)報(bào)告模塊，用于在本端處于確認(rèn)模式下的RLC協(xié)議實(shí)體重建之前向?qū)?端對(duì)等RLC協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告。 進(jìn)一步地，RLC協(xié)議實(shí)體重建完成后，RLC協(xié)議實(shí)體僅重傳最近接收到的Status
6R印ort中未確認(rèn)的報(bào)文。 需說明的是，如果是因?yàn)榫W(wǎng)絡(luò)情況惡劣，則Status R印ort也可能無法發(fā)送到對(duì) 端，所以這個(gè)方案是一種保護(hù)機(jī)制，是否能實(shí)時(shí)生效則取決于觸發(fā)重建時(shí)的網(wǎng)絡(luò)環(huán)境。
采用本發(fā)明的實(shí)施方法以后，可以讓RLC協(xié)議實(shí)體重建完成后，發(fā)送端的協(xié)議實(shí) 體僅發(fā)送接收端未確認(rèn)收到的報(bào)文，避免了接收端已收到報(bào)文的重復(fù)傳輸，降低了空口的 開銷。


圖1為一般情況下RLC協(xié)議實(shí)體重建流程的實(shí)現(xiàn)； 圖2為重建過程完成后冗余報(bào)文重傳的示意圖； 圖3為本發(fā)明所述系統(tǒng)的邏輯結(jié)構(gòu)示意圖； 圖4為本發(fā)明所述系統(tǒng)中RLC協(xié)議實(shí)體的邏輯結(jié)構(gòu)圖； 圖5A為本發(fā)明一具體實(shí)施例中RLC協(xié)議實(shí)體檢測(cè)到觸發(fā)重建異常時(shí)的處理流 程； 圖5B為本發(fā)明另一具體實(shí)施例中RLC協(xié)議實(shí)體檢測(cè)到觸發(fā)重建異常時(shí)的處理流 程； 圖6為本發(fā)明RLC協(xié)議實(shí)體收到通知后的處理流程； 圖7為本發(fā)明對(duì)端RLC協(xié)議實(shí)體收到Status R印ort，重建前后的處理流程； 圖8為本發(fā)明重建過程整體實(shí)現(xiàn)時(shí)序流程圖。
具體實(shí)施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點(diǎn)更加清楚明白，以下舉實(shí)施例并參照附圖，對(duì) 本發(fā)明進(jìn)一步詳細(xì)說明。 圖3為本發(fā)明所述系統(tǒng)的邏輯結(jié)構(gòu)示意圖，包括UE端和eNodeB端兩部分，兩端的 協(xié)議層次關(guān)系及模塊組成基本一致。兩端都包括控制面處理單元及用戶面處理單元兩部 分，每一個(gè)UE在eNodeB端都會(huì)有一個(gè)對(duì)應(yīng)的用戶面處理單元，用于處理從屬于同一UE的 用戶面數(shù)據(jù)。用戶面處理單元中的RLC實(shí)體用于完成無線鏈路控制層協(xié)議功能，每一端有 可能包括多個(gè)業(yè)務(wù)邏輯信道，因此會(huì)有多個(gè)RLC協(xié)議實(shí)體與業(yè)務(wù)邏輯信道對(duì)應(yīng)，每一個(gè)RLC 協(xié)議實(shí)體都通過業(yè)務(wù)信道與對(duì)端的對(duì)等的RLC協(xié)議實(shí)體進(jìn)行通信，現(xiàn)有協(xié)議中，當(dāng)RLC協(xié)議 實(shí)體在檢測(cè)到觸發(fā)RLC協(xié)議實(shí)體重建的異常時(shí)，會(huì)通知控制面處理單元中的無線資源控制 實(shí)體，無線資源控制實(shí)體會(huì)向針對(duì)從屬于同一UE的所有RLC協(xié)議實(shí)體發(fā)送重建指示消息， 待本端RLC協(xié)議實(shí)體重建完成后，再重新發(fā)送未得到確認(rèn)的消息數(shù)據(jù)。本發(fā)明中，RLC協(xié)議 實(shí)體在檢測(cè)到觸發(fā)RLC協(xié)議實(shí)體重建的異常時(shí)，會(huì)首先通知本端的所有從屬于同一 UE的 RLC協(xié)議實(shí)體，收到通知的且處于確認(rèn)模式下的RLC協(xié)議實(shí)體會(huì)在重建前發(fā)送狀態(tài)報(bào)告給 對(duì)端RLC協(xié)議實(shí)體。 圖4為本發(fā)明所述系統(tǒng)中的RLC協(xié)議實(shí)體的邏輯結(jié)構(gòu)示意圖，包括，實(shí)體處理模 塊，通知模塊，重建前狀態(tài)報(bào)告模塊。實(shí)體處理模塊用于完成現(xiàn)有協(xié)議中無線鏈路控制層的 功能；通知模塊，用于當(dāng)對(duì)應(yīng)于某一條邏輯信道的RLC協(xié)議實(shí)體檢測(cè)到觸發(fā)RLC協(xié)議實(shí)體重 建的異常時(shí)通知本端其它RLC協(xié)議實(shí)體；重建前狀態(tài)報(bào)告模塊用于在本端RLC協(xié)議實(shí)體重建之前向?qū)Χ藢?duì)等RLC協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告。實(shí)體處理模塊檢測(cè)到異常后通知重建前狀 態(tài)報(bào)告模塊及通知模塊，在重建前狀態(tài)報(bào)告模塊向?qū)Χ税l(fā)送完?duì)顟B(tài)報(bào)告消息及通知模塊向 本端從屬于同一 UE的其它RLC協(xié)議實(shí)體發(fā)送異常通知消息后，實(shí)體處理模塊將異常上報(bào)給 無線資源控制實(shí)體，無線資源控制實(shí)體決策進(jìn)行重建并向?qū)嶓w處理模塊發(fā)送重建指示。
本發(fā)明一具體實(shí)施例中，假設(shè)在某eNodeB有歸屬于UE(User Equipment,用戶設(shè) 備)的5個(gè)RLC協(xié)議實(shí)體，均為確認(rèn)模式，分別對(duì)應(yīng)5種不同業(yè)務(wù)的DRB，用DRBl DRB5來 分別。假設(shè)現(xiàn)在每個(gè)DRB的RLC協(xié)議實(shí)體接收端都按序收到了序號(hào)為0 9的10個(gè)報(bào)文， 長(zhǎng)度均為1024字節(jié)，因?yàn)槲催_(dá)到觸發(fā)StatusR印ort的條件，目前都未向發(fā)送端即UE的RLC 對(duì)等協(xié)議實(shí)體發(fā)送StatusR印ort ;UE側(cè)每個(gè)DRB的對(duì)等RLC協(xié)議實(shí)體發(fā)送端已發(fā)送了序號(hào) 為0 9的IO個(gè)報(bào)文，還有序號(hào)為10 14的5個(gè)報(bào)文待發(fā)送，長(zhǎng)度同樣均為1024字節(jié)。 當(dāng)DRBl對(duì)應(yīng)的RLC協(xié)議實(shí)體檢測(cè)到協(xié)議處理錯(cuò)誤或報(bào)文重傳超過閾值的異常后，處理流程 如圖5A : 步驟5-01 :DRB1的RLC協(xié)議實(shí)體檢測(cè)到協(xié)議處理錯(cuò)誤或某一報(bào)文重傳超過閾值的 異常； 步驟5-02 :DRB1的RLC協(xié)議實(shí)體通過消息或函數(shù)調(diào)用的方式通知?dú)w屬于本UE的 從DRBl到DRB5的所有RLC協(xié)議實(shí)體； 步驟5-03 :DRB1的RLC協(xié)議實(shí)體將該異常通知本端的無線資源控制實(shí)體。
本發(fā)明一具體實(shí)施例中，假設(shè)在某eNodeB有歸屬于UE(User Equipment,用戶設(shè) 備)的8個(gè)RLC協(xié)議實(shí)體，分別對(duì)應(yīng)8種不同業(yè)務(wù)的DRB，用DRBl DRB8來分別。其中 DRBl DRB5為確認(rèn)模式的RLC協(xié)議實(shí)體，DRB6 DRB8為非確認(rèn)模式的RLC協(xié)議實(shí)體。假 設(shè)現(xiàn)在每個(gè)DRB的RLC協(xié)議實(shí)體接收端都按序收到了序號(hào)為0 9的10個(gè)報(bào)文，長(zhǎng)度均為 1024字節(jié)，因?yàn)槲催_(dá)到觸發(fā)Status R印ort的條件，目前所有確認(rèn)模式的RLC協(xié)議實(shí)體都未 向發(fā)送端即UE的RLC對(duì)等協(xié)議實(shí)體發(fā)送Status R印ort ;UE側(cè)每個(gè)DRB的對(duì)等RLC協(xié)議實(shí) 體發(fā)送端已發(fā)送了序號(hào)為0 9的10個(gè)報(bào)文，還有序號(hào)為10 14的5個(gè)報(bào)文待發(fā)送，長(zhǎng) 度同樣均為1024字節(jié)。當(dāng)DRBl對(duì)應(yīng)的RLC協(xié)議實(shí)體檢測(cè)到協(xié)議處理錯(cuò)誤或報(bào)文重傳超過 閾值的異常后，處理流程如圖5B : 步驟5-11 :DRB1的RLC協(xié)議實(shí)體檢測(cè)到協(xié)議處理錯(cuò)誤或某一報(bào)文重傳超過閾值的 異常； 步驟5-12 :DRB1的RLC協(xié)議實(shí)體通過消息或函數(shù)調(diào)用的方式通知?dú)w屬于本UE的 從DRBl到DRB5的確認(rèn)模式的RLC協(xié)議實(shí)體，但并不通知DRB6到DRB8這些非確認(rèn)模式的 RLC協(xié)議實(shí)體； 步驟5-13 :DRB1的RLC協(xié)議實(shí)體將該異常通知本端的無線資源控制實(shí)體。 對(duì)從DRBl到DRB5中每個(gè)被通知到的RLC協(xié)議實(shí)體(包括首先檢測(cè)到錯(cuò)誤的RLC
協(xié)議實(shí)體)而言，執(zhí)行如圖6所示的如下步驟 步驟6-1 :RLC協(xié)議實(shí)體收到通知，得知已偵測(cè)到可能觸發(fā)RLC協(xié)議實(shí)體重建的異 常； 步驟6-2 :該RLC協(xié)議實(shí)體判斷自身的T_statuS_prohibit (狀態(tài)禁止)定時(shí)器是 否處于運(yùn)行態(tài)，如果是，則轉(zhuǎn)入流程6-3，否則直接跳轉(zhuǎn)到流程6-4 ;
步驟6-3 :停止T_status_prohibit定時(shí)器；
8
步驟6-4 :向?qū)Χ藢?duì)等的RLC協(xié)議實(shí)體發(fā)送Status R印ort，其中包含的ACK_SN等
于10，即標(biāo)識(shí)0 9的報(bào)文均已收到； 步驟6-5 :啟動(dòng)T_status_prohibit定時(shí)器。 對(duì)端的RLC協(xié)議實(shí)體接收到Status R印ort之后，處理流程如圖7所示
步驟7-1 :RLC協(xié)議實(shí)體收到對(duì)端發(fā)來的Status R印ort ; 步驟7-2 :根據(jù)Status R印ort，刪除協(xié)議實(shí)體中已發(fā)送隊(duì)列內(nèi)已被對(duì)端正確接收 到的序號(hào)為0 9的PDU，并通知上層刪除對(duì)應(yīng)的SDU ;
步驟7-3:重建完成； 步驟7-4 :向?qū)Χ薘LC重傳尚未刪除的SDU，即序號(hào)10 14的PDU對(duì)應(yīng)的SDU。
綜上所述，包含本發(fā)明所述方法的重建過程如圖8所示，執(zhí)行如下步驟
步驟8-1 :接收端RLC協(xié)議實(shí)體得知已發(fā)生可能觸發(fā)RLC協(xié)議實(shí)體重建的異常；
步驟8-2 :接收端RLC協(xié)議實(shí)體向?qū)Χ税l(fā)送Status R印ort ; 步驟8-3 :發(fā)送端RLC協(xié)議實(shí)體收到Status R印ort后，刪除已發(fā)送隊(duì)列中被對(duì)端 正確接收到的PDU，并通知上層刪除對(duì)應(yīng)的SDU ; 步驟8-4 :接收端和發(fā)送端RLC協(xié)議實(shí)體都收到上層的重建指示； 步驟8-5 :接收端RLC協(xié)議實(shí)體將接收緩沖區(qū)中的所有報(bào)文，無論其是否連續(xù)均向
PDCP投遞； 步驟8-6 :RLC協(xié)議實(shí)體重建完成； 步驟8-7 :發(fā)送端RLC協(xié)議實(shí)體向?qū)Χ税l(fā)送尚未得到確認(rèn)的PDU。
從這個(gè)流程的描述可以看到，因?yàn)槭盏街亟ㄖ甘厩?，接收端和發(fā)送端進(jìn)行了一次 Status R印ort的交互，使得發(fā)送端可以刪除接收端已確認(rèn)的PDU。這樣在重建后只會(huì)傳輸 那些未得到確認(rèn)的PDU，避免了冗余報(bào)文的大量重傳。在這個(gè)實(shí)施例中，5個(gè)DRB，每個(gè)DRB 在重建后都沒有重復(fù)傳輸序號(hào)為0 9的10個(gè)PDU報(bào)文，每個(gè)長(zhǎng)度均為1024字節(jié)，即在空 口減少了 50K的數(shù)據(jù)傳輸，效果是相當(dāng)明顯的。 以上所述，僅為本發(fā)明的較佳實(shí)施例，并非用于限定本發(fā)明的保護(hù)范圍。
權(quán)利要求
一種無線鏈路控制層減少冗余報(bào)文重傳的方法，其特征在于，包括A、在演進(jìn)基站或終端側(cè)，當(dāng)對(duì)應(yīng)于某一條邏輯信道的無線鏈路控制協(xié)議實(shí)體檢測(cè)到觸發(fā)無線鏈路控制協(xié)議實(shí)體重建的異常時(shí)，通知本端從屬于同一終端的與邏輯信道對(duì)應(yīng)的其它無線鏈路控制協(xié)議實(shí)體或處于確認(rèn)模式的無線鏈路控制協(xié)議實(shí)體；B、本端收到通知的處于確認(rèn)模式的無線鏈路控制協(xié)議實(shí)體向?qū)Χ藢?duì)等的無線鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告；C、所述對(duì)端對(duì)等的無線鏈路控制協(xié)議實(shí)體收到狀態(tài)報(bào)告后，刪除狀態(tài)報(bào)告中已確認(rèn)收到的協(xié)議數(shù)據(jù)單元和上層對(duì)應(yīng)的服務(wù)數(shù)據(jù)單元。
2. 根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟A中，所述觸發(fā)無線鏈路控制協(xié)議實(shí) 體重建的異常是指協(xié)議處理錯(cuò)誤或報(bào)文重傳異常。
3. 根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B中，所述本端收到通知的處于確認(rèn) 模式的無線鏈路控制協(xié)議實(shí)體無論其狀態(tài)報(bào)告禁止定時(shí)器是否運(yùn)行，都向?qū)Χ藢?duì)等的無線 鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告。
4. 根據(jù)權(quán)利要求1所述的方法，其特征在于，步驟B中，所述本端收到通知的處于確認(rèn) 模式的無線鏈路控制協(xié)議實(shí)體向?qū)Χ藢?duì)等的無線鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告的步驟 如下B01、判斷狀態(tài)禁止定時(shí)器是否運(yùn)行，如果未運(yùn)行，則執(zhí)行步驟B02 ;若運(yùn)行，則執(zhí)行B03 ;B02、向?qū)Χ藢?duì)等的無線鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告，執(zhí)行B05 ;B03、停止?fàn)顟B(tài)禁止定時(shí)器，然后執(zhí)行步驟B04 ;B04、向?qū)Χ藢?duì)等的無線鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告；B05、啟動(dòng)狀態(tài)禁止定時(shí)器。
5. —種無線鏈路控制層減少冗余報(bào)文重傳的系統(tǒng)，包括終端側(cè)及演進(jìn)基站側(cè)，兩端都 包括控制面處理單元及用戶面處理單元，用戶面處理單元中包含一個(gè)或多個(gè)與邏輯信道對(duì) 應(yīng)的無線鏈路控制協(xié)議實(shí)體，其特征在于，當(dāng)對(duì)應(yīng)于某一條邏輯信道的無線鏈路控制協(xié)議實(shí)體檢測(cè)到觸發(fā)無線鏈路控制協(xié)議實(shí) 體重建的異常時(shí)，具有通知本端從屬于同一終端的其它無線鏈路控制協(xié)議實(shí)體或處于確認(rèn) 模式的無線鏈路控制協(xié)議實(shí)體的功能；本端收到通知的處于確認(rèn)模式的無線鏈路控制協(xié)議實(shí)體在接收到所述通知后，具有向 對(duì)端對(duì)等無線鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告的功能。
6 根據(jù)權(quán)利要求5所述的系統(tǒng)，其特征在于，本發(fā)明所述無線鏈路控制協(xié)議實(shí)體進(jìn)一 步包括實(shí)體處理模塊，用于實(shí)現(xiàn)無線鏈路控制協(xié)議實(shí)體的基本功能；通知模塊，用于當(dāng)對(duì)應(yīng)于某一條邏輯信道的無線鏈路控制協(xié)議實(shí)體檢測(cè)到觸發(fā)無線鏈 路控制協(xié)議實(shí)體重建的異常時(shí)通知本端其它從屬于同一終端的所有無線鏈路控制協(xié)議實(shí) 體；重建前狀態(tài)報(bào)告模塊，用于在本端處于確認(rèn)模式下的無線鏈路控制協(xié)議實(shí)體重建之前 向?qū)Χ藢?duì)等無線鏈路控制協(xié)議實(shí)體發(fā)送狀態(tài)報(bào)告。
7. 根據(jù)權(quán)利要求5所述的系統(tǒng)，其特征在于，無線鏈路控制協(xié)議實(shí)體重建完成后，無線鏈路控制協(xié)議實(shí)體僅重傳最近接收到的狀態(tài)報(bào)告中未確認(rèn)的報(bào)文'
全文摘要
本發(fā)明公開了一種LTE系統(tǒng)中無線鏈路控制層協(xié)議實(shí)體的重建過程中減少冗余報(bào)文重傳的方法及系統(tǒng)，用于解決RLC協(xié)議實(shí)體重建后，發(fā)送端重復(fù)發(fā)送接收端已確認(rèn)收到的冗余報(bào)文，導(dǎo)致空口資源浪費(fèi)的技術(shù)問題。本發(fā)明利用RLC協(xié)議層可提前預(yù)測(cè)重建是否發(fā)生這一特點(diǎn)，在RLC協(xié)議實(shí)體收到重建指示之前讓歸屬于同一終端的確認(rèn)模式的接收端RLC協(xié)議實(shí)體都試圖發(fā)送一個(gè)狀態(tài)報(bào)告給發(fā)送端，發(fā)送端RLC協(xié)議實(shí)體在收到重建請(qǐng)求之前首先根據(jù)狀態(tài)報(bào)告刪除接收端已確認(rèn)收到的報(bào)文，在重建完成后不再重復(fù)發(fā)送這些報(bào)文，從而減少冗余報(bào)文重傳，降低空口的開銷。
文檔編號(hào)H04W76/04GK101753281SQ20081023944
公開日2010年6月23日 申請(qǐng)日期2008年12月10日 優(yōu)先權(quán)日2008年12月10日
發(fā)明者李邈, 湯德龍 申請(qǐng)人:中興通訊股份有限公司