[發明專利]狀態報告的發送方法及裝置

有效

• 申請號: 201610804996.0
• 申請日: 2016-09-06
• 公開（公告）號: CN107801200B
• 公開（公告）日: 2022-05-20
• 發明（設計）人: 陳飛;帥哲;劉利九;方皆樂
• 申請（專利權）人: 中興通訊股份有限公司
• 主分類號: H04W24/08
• 分類號: H04W24/08;H04W24/10;H04W28/04;H04W28/14
• 代理公司: 北京天昊聯合知識產權代理有限公司 11112
• 代理人: 姜春咸;馮建基

本發明實施例提供一種狀態報告的發送方法及裝置，在狀態禁止定時器定時期間檢測到有狀態報告待向缺失數據的發送端發送時，檢測當前的網絡傳輸環境，當前的網絡傳輸環境差、不宜等待狀態禁止定時器定時結束再發送狀態報告時，直接向發送端發送狀態報告，在很大程度上增加了發送端接收到狀態報告的幾率，提前了發送端接收到狀態報告的時間，避免了在網絡傳輸環境差的情況下依靠狀態禁止定時器的定時控制狀態報告發送而導致的發送端接收狀態報告幾率小、接收狀態報告時間長的問題，因此，也就解決無線傳輸效率低、發送窗口被已發送但未經確認的數據占滿，傳輸停止的問題，見成效了數據傳輸時延，提高了傳輸效率和網絡吞吐量，保證了通信質量。

技術領域

本發明涉及通訊領域，尤其涉及狀態報告的發送方法及裝置。

背景技術

RLC(Radio Link Control，無線鏈路層控制協議)是標準化3GPP(3rd GenerationPartnership Project，第三代伙伴計劃)所擬定的無線通信系統中的無線鏈路控制層協議。RLC子層不僅承載控制面的數據，而且也承載用戶面的數據。RLC子層有三種工作模式，分別是透明模式(TM，Transparent Mode)、非確認模式(UM，Unacknowledged Mode)和確認模式(AM，Acknowledged Mode)。

在AM模式中，ARQ(Automatic Repeat Request，自動重復請求協議)是通過接收端向發送端發送狀態報告，便于發送端根據狀態報告來判斷哪些PDU(Protocol Data Unit，協議數據單元)或PDU分段已經被接收端收到，哪些PDU或PDU分段需要重傳，從而保證數據的可靠性傳輸。

目前觸發接收端發送狀態報告的情況包括這樣兩種：一、接收端收到發送端發起的輪詢(Polling)；二、接收端檢測到一個PDU或PDU分段接收失敗，即重排定時器(t-Reordering)超時，如當前接收端接收到了SN(Sequence Number，序號)為5的數據，且在此之前，接收端應經接收到了SN小于4的全部數據。這時候，接收端會啟動重排定時器，當重排定時器定時結束之后，接收端還未收到SN為4的數據，則接收端判定SN為4的數據接收失敗，這時接收端應當向數據發送端發送狀態報告，在狀態報告中必需包含表征SN為4的信息以告知發送端SN為4需要重傳，同時狀態報告中還包括“VR(H)＝6”的信息，“VR(H)＝6”表征下一個接收到的數據的SN值最可能為6，通過這種方式，能夠讓發送端了解到SN值小于6的所有數據中，除了SN為4的數據，其他的都已被接收成功。

在第二種情況下，如果一個狀態報告發送時，接收端還未收到前一個狀態報告觸發的重傳，則可能導致同一個PDU或PDU分段被要求重傳2次，從而導致無線資源浪費。在AM模式下，這是導致接收端重復收到PDU的一個重要原因。為了避免這種情況的發生，現有技術定義了一個狀態禁止功能，即在一個狀態報告發送的同時啟動狀態禁止定時器(t-StatusProhibit)，在狀態禁止定時器定時期間禁止向發送端發送狀態報告。所以在發送狀態報告時，需要滿足狀態禁止定時器不在定時中的要求，狀態報告觸發過程參見圖1所示：

S101、檢測到需要向發送端發送狀態報告。

需要發送狀態報告可以是接收端接收到發送端的輪詢指令或者接收端檢測由缺失數據出現，即有數據接收失敗。

S102、判斷當前狀態禁止定時器是否處于定時狀態。

當判斷結果為是，則直接結束流程，當判斷結果為否，則執行S103。

S103、向發送端發送狀態報告并啟動狀態禁止定時器。

狀態禁止定時器啟動后，在其定時結束期間能夠避免接收端向發送端重復發送狀態報告，強制接收端等待定時時長，當接收端在定時期間接收到了缺失數據，則在后續過程中可以不再針對該缺失數據發送狀態報告。