5G NR - RLC協議閱讀筆記 - Overview
1. 寫在前面的話
誠如通訊著名部落格sharetechnote作者Jaeku Ryu在其LTE RLC筆記的開場白時說：
Personally to me, RLC layer is one of the trickest area to understand in very detail. At the beginning it seems to be simple, but as I getting deeper and deeper into this layer I get more and more confused. Another difficulties is that I don‘t find any books or other training material explaining very detail on this area, whereas you would find a lot of books and materials digging very deeply into other layer.
RLC初看覺得簡單，因為協議一共也就33頁，只有RRC的三十分之一，甚至比看起來更簡單的PDCP協議還少了接近20頁，但實際上要理解其各種細節並非易事，Jaeku Ryu提到一個重要原因是幾乎沒有書籍或資料詳細講解RLC. 但我發現還是有極少數書籍的RLC章節講得很不錯。另外我覺得這方面資料少並不是因為RLC專家不願意寫，而是很難從理論層面寫得太詳細，原因可能有幾點：
1. RLC協議本身內容不多，單從理論上沒法寫太細
2. 理解RLC需要理解很多關聯的概念和邏輯，這些概念和邏輯分佈在RLC之外的領域，比如使用者面，L2, RB, 邏輯通道，HARQ, MAC排程…
3. RLC真正難的部分不是理解協議，而是具體實現和處理現實中的複雜問題
因此要更深入理解RLC，一是要對使用者面有比較清晰的總體認識(比如資料如何從QoS Flow一步步通過SDAP下發到空口)，二是要多動手，多處理具體問題。
若既沒有詳細解析RLC的書籍/資料，又沒有實踐機會(開發RLC和處理bug)，怎樣的學習方式比較高效？我最初看LTE RLC協議亦是剪不斷理還亂，因為狀態變數(State Variables)太多，而且名字全然不具備啟發性，比如AM接收變數VR(MR), VR(MS), VR(R), VR(X), VR(H), 光是看到這5個‘VR’就已暈頭轉向，勿論混雜這些變數(通常還結合幾個定時器)的各種處理了！NR有所改善：變數名具備一定啟發性了(比如，將LTE的VR(X)改成了RX_Next_Status_Trigger)，但是光看不動手，仍會被那些處理流程弄得一頭霧水，因此我試圖在閱讀RLC協議時邊看邊根據協議處理流程在紙上畫出對應的收發包例項，如下圖，這樣理解就稍微深一點：
2. Big Picture
在OTA訊息中，我們見得較多的一個名詞是RB – Radio Bearer(無線承載)，比如RRC Setup和RRC Reconfiguration訊息裡的SRB/DRB配置。如其名，RB用來在空口(Radio)承載(Bear)資料，凡是基站發往UE的資料(無論是RRC訊息 - SRB資料，還是網路來的QoS flow對映到DRB的資料)都扔給RB，至於資料如何通過RB傳送到UE，需要基站進行一系列處理，UE發給基站也一樣。RB並非是一個實際的通道，而是對應於一套空口資源(RLC通道，邏輯通道，傳輸通道，物理通道，電磁波)和協議軟體實體(PDCP, RLC, MAC, PHY)的抽象概念， 也就是說資料通過某個RB傳輸，實際上是先對映到邏輯通道(這裡由於PDCP處理較簡單，主要是頭壓縮和安全處理 - 加密和完整性保護，其與RB是一對一的對映關係，因此我們先忽略PDCP和RLC Channel，於後續PDCP筆記專門講解)，而邏輯通道同樣是抽象概念，需要進一步對映到傳輸通道，傳輸通道再對映到物理通道，最終通過電磁波發射出去。那RB的資料是直接扔給邏輯通道嗎？當然不是，上面提到的一系列對映都要經過協議實體處理，其中用於處理RB到邏輯通道對映過程的實體就叫做 - RLC – Radio Link Control(無線鏈路控制)。如下圖(38.300: Figure 6.1-1)，我們可以看到RLC在L2(SDAP+PDCP+RLC+MAC)架構中的位置：
3. RLC功能
從RLC全稱Radio Link Control可以看出，其用於無線鏈路控制，主要是保證資料傳輸的可靠性(把錯誤率控制在一定範圍)，其融合了OSI七層協議的資料鏈路層和傳輸層(TCP)的功能/機制(比如ARQ，滑動視窗等等)。
瞭解RLC的功能前，我們要先了解兩個最最基本的概念SDU和PDU以及RLC三種傳輸模式(因為每個功能有其適用的mode).
1) SDU和PDU
在協議體系裡，下層協議是為上層協議提供服務(service)的，因此凡是上層發過來的或者發往上層的資料都叫SDU(Service Data Unit)。而上層協議(Protocol)實體對資料進行處理後，通過下層協議提供的服務繼續往後面傳送，因此凡是發給下層或從下層收到的資料叫做PDU(Protocol Data Unit)，通過下圖可以得到一個直觀的認識：
2) 三種傳輸模式
TM - Transparent Mode
transparent, 顧名思義，就是透傳，傳送端不對RLC SDU做分段(segementation)操作，也不新增RLC Header，只是快取資料，然後在MAC層通知傳輸機會時傳送給底層，接收端收到資料後直接發給上層。
適合的邏輯通道：BCCH, DL/UL CCCH, PCCH, andSBCCH
UM - Unacknowledged Mode
無響應模式，類似於UDP，傳送端可以對資料進行分段處理，但不需要接收端反饋接收狀態。
適合的邏輯通道：DL/UL DTCH, SCCH, and STCH
AM - Acknowledged Mode
響應模式，接收端通過RLC status report反饋包接收狀態，傳送端根據status report決定是否重傳資料。
適合的邏輯通道：DL/UL DCCH, DL/UL DTCH, SCCH,and STCH
3) RLC功能overview
如下是RLC各功能概覽，各功能細節會穿插在後面系列筆記中：
- 新增RLC序列號(Sequence Numbering)
給上層發過來的每個SDU新增序列號並作為RLC PDU header的一部分，適用於AM和UM, 這個序列號獨立於PDCP層的序列號。
- 糾錯(Error Correction)
AM模式下，通過ARQ(自動重傳請求)機制糾錯，也就是基於接收端反饋的RLC status reports重傳RLC PDU或PDU分段(segments)。
- 分段和重分段(Segmentation and Re-segmentation)
MAC根據排程的TB大小通知RLC可傳送的PDU大小，當預處理(pre-processing, 這是NR對LTE的區別之一，會在下篇講解)的RLC PDU或需要重傳的PDU Segment大於MAC層指示的大小時，就需要對RLC PDU進行分段(適用AM和UM)或對PDU Segment重分段(適用AM)。
- 重組 SDU(Reassembly of SDU)
既然傳送端有分段(segement)，那麼接收端就要將這些分段重新組合成SDU才能傳送給上層。
- 重複包檢測(Duplicate Dectection)
如果在接收視窗內收到的PDU所包含的全部內容或部分內容之前已經收到過，那麼就丟棄整個PDU或PDU中跟之前已收到的內容有重複的部分。
- RLC SDU丟棄(RLC SDU discard)
比如在reassembly window之外的SDU或者PDCP指示需要丟棄的SDU.
- RLC實體重建(RLC Re-establishment)
比如UE傳送切換(handover)時。
- 協議錯誤偵測(Protocol Error Detection)
比如當ARQ重傳次數達到最大值時。僅適用AM.
4. 與RB和邏輯通道的關係
一個RB對應一個邏輯通道，反之亦然。
一個RLC實體對應一個RB或邏輯通道，但反之不一定：
- TM和UM，由於傳送和接收RLC實體是獨立的，一個RB或邏輯通道可以對應兩個RLC實體
- AM, 由於傳送和接收在同一個RLC實體，一個RB或邏輯通道對應一個RLC實體
可以通過一個AM例項看一下：
----- clip ----
rlc-BearerToAddModList
{
{
logicalChannelIdentity 4, //一個邏輯通道
servedRadioBearer drb-Identity : 4, //一個RB
rlc-Config am : //一個傳輸模式為AM的實體
{
ul-AM-RLC
{
...
},
dl-AM-RLC
{
...
}
},
----- clip ----
————————————————
版權宣告：本文為CSDN博主「yu_yuan_hong」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/travel_life/article/details/123867117