其他相關內容
RLC PDU and Parameters
RLC架構和RLC entity

一 RLC entity handling

RLC entity有建立、重建和釋放的過程(establishment，re-establishment和release)，這些都來自于高層請求，其實就是RRC。

• 如果高層請求establishment，UE將會建立RLC entity，設置狀態變量為初始值；
• 如果高層請求re-establishment，UE則刪掉所有的SDU，SDU segment和PDU，重置timer，將狀態變量重置為初始值。
• 如果高層請求release，UE同樣會刪掉所有RLC SDU，SDU segment和PDU，并release RLC entity。

二 Data transfer procedures

我們知道RLC有三種傳輸模式：TM、UM和AM，且這三種傳輸模式由業務類型決定：TM和UM適合時延敏感、錯誤不敏感的實時業務，而AM適合時延不敏感、錯誤敏感的非實時業務。根據各自傳輸特點，三種傳輸模式有各自不同的數據傳輸過程。

1 TM data transfer

TM模式下，即所謂的透傳，是三種傳輸模式中最簡單的一種，RLC層對上層PDCP來的SDU不做任何處理，直接送到MAC層進行傳輸，對收到的來自MAC的PDU同樣不做任何處理，直接送到PDCP。

此時，傳輸側的RLC entity被叫做transmitting TM RLC entity，其傳輸的PDU叫做TMD PDU。當一個RLC SDU (PDCP PDU)到達RLC時，transmitting TM RLC entity不做任何加工，直接將這個RLC SDU送到MAC層，換句話說，就是在透傳時，一個RLC SDU就是一個TMD PDU，transmitting TM RLC entity不對TMD PDU做加頭、分段等處理。對應的，在接收側，receiving TM RLC entity也直接將收到的TMD PDU送到PDCP，因為發送端沒有加頭、分段，所以接收端也不需要去頭、重組等操作。

2 UM data transfer

與TM模式同理的地方是，UM模式下，傳輸側叫做transmitting UM RLC entity，接收側叫做receiving UM RLC entity，傳輸的PDU叫做UMD PDU。

與TM模式不同的地方是，UM雖然是Unacknowledge mode，即非確認模式，也就是UM模式也不保證正確傳輸，但比TM模式要復雜一些，發送側需要對RLC SDU進行分段(如必要時)和加頭，來構建UMD PDU，接收側相應的需要對UMD PDU進行去頭和重組(如必要)。分段和重組是因為MAC會告知UM RLC entity它所能接收的UMD PDU的大小限制，因為大小受限，所以對于過大的RLC SDU，在將其構建為UMD PDU時，一個PDU里有時無法包含一個完整的SDU，所以此時需要將RLC SDU進行分割，分割為多個片段RLC SDU segment，然后每個PDU的數據域里只包含一個RLC SDU segment，再加頭構建為UMD PDU，送往MAC層進行傳輸。所以分段/重組和加頭/去頭就是UM模式和TM模式的主要不同。

為了正常實現UM RLC entity的這些功能，UM RLC entity需要維護一些狀態變量和計時器，這里先將這些狀態變量和計時器列舉如下，并對其概念進行初步解釋，以方便后面對UM模式下的數據傳輸過程的理解。

發送端狀態變量：
a) TX_Next，該變量指示下一個要構建的包含RLC SDU segment的UMD PDU的順序號SN，每到最后一個segment時更新。簡單的說就是發送側發送的UMD PDU的順序號，初始值為0。
接收端狀態變量：
a) RX_Next_Reassembly，這個變量指向所有要重組的包中，最早的那個SN；
b) RX_Timer_Trigger，這個變量指向觸發計時器t-Reassembly的那個包的SN+1；
c) RX_Next_Highest，這個變量指向所有已收到的UMD PDU中最大的SN+1。
計時器：
t-Reassembly，這個timer用于接收端檢測是否有丟包存在，從邏輯上講，如果一個包沒收到的，那接收端不可能無限制等下去，這就是這個timer的意義所在。一個RLC entity在一個時刻，只能維護一個t-Reassembly。

了解了UM模式的基本邏輯和一些狀態變量及計時器后，下面對具體的數據傳輸過程進行描述。

發送端

發送端根據MAC層的指示，在必要時，將大小超過限制的RLC SDU進行分段，然后構建UMD PDU。如上所述，發送端需要維護狀態變量TX_Next，如果構建的UMD PDU包含的是一個RLC SDU segment，則將該UMD PDU的SN設為TX_Next。如果這個segment是一個RLC SDU的最后一個分段，那么與此同時TX_Next+1。一個UMD PDU如果包含的是一個完整的RLC SDU，那么這個UMD PDU沒有SN。然后將構建好的UMD PDU送到MAC層進行傳輸。

接收端

接收端在接收UMD PDU時，通過上述接收端的三個狀態變量，維護一個reassembly window，用于接收和重組：

• RX_Next_Highest，該變量即為reassembly window的上邊界；
• UM_Window_Size，該常數為reassembly window的大小，6 bit SN時為32，12 bit SN時為2048；
• (RX_Next_Highest – UM_Window_Size)，上邊界減去窗口大小自然為reassembly window的下邊界；

即如果一個SN落在(RX_Next_Highest – UM_Window_Size) <= SN <RX_Next_Highest為reassembly window范圍內，就是落在了reassembly window內。通過接收端不斷的接收新的UMD PDU，變量RX_Next_Highest不斷更新，所以窗口上邊界被不斷拉著向前，通過不斷“PULL”這個窗口，來維持UMD PDU的接收。

具體的接收過程為，當收到UMD PDU之后，按照這個UMD PDU是一個完整的RLC SDU還是一個RLC SDU segment，以及這個segment的SN的大小，分為以下幾種情況：

如果UMD PDU沒有SN，那么說明這個UMD PDU是個完整的RLC SDU，則去掉RLC header后立馬送到PDCP。

如果UMD PDU有SN，那么說明這個PDU是一個RLC SDU segment，如果SN滿足(RX_Next_Highest – UM_Window_Size) <= SN < RX_Next_Reassembly，則說明該SN沒有落在有效的范圍內，則丟掉該UMD PDU。如上所述，變量RX_Next_Reassembly可以簡單理解為所有待重組的包中最小的SN，邏輯上講，如果收到的包的SN比所有待重組的包中最小的SN都要小，那自然要丟掉這個包。

如果UMD PDU有SN且SN落在了有效窗口范圍內，將UMD PDU放到reception buffer中。

對于放到reception buffer中的PDU，如果一個SDU的segment都收全了，則經過重組和去頭后，立馬送到PDCP，RLC無需照顧送到上層的包的順序，與此同時，進行狀態變量的更新。

對于變量RX_Next_Highest，永遠指向最大的SN+1，所以如果收到的是一個新的、更大的SN，則更新RX_Next_Highest，比如之前收到的最大的SN=5，則RX_Next_Highest=6，此時如果收到了SN=8，則更新RX_Next_Highest=9。對于SN=5和SN=8中間的包，可能是丟掉了，因為UM模式不保證正確傳輸，所以接收端不會管。

如果新包到達的速度太快，導致reassembly window被不斷往后PULL，但重組的速度又跟不上，就可能導致會有SN，甚至RX_Next_Reassembly跑到reassembly window外面，此時需要更新RX_Next_Reassembly為reassembly window內的最早的一個待重組的SN。

在數據傳輸過程中，接收端會按照具體情況啟動/重啟或停止計時器t-Reassembly，簡單來說就是，如果有了待重組的包，就啟動timer，待重組的包都組完了，就停止timer。

下面對timer啟/停條件進行具體描述。如果t-Reassembly沒在運行，滿足以下兩種情況任一種時啟動timer：

RX_Next_Highest > RX_Next_Reassembly + 1
比如上面的例子，由于收到SN=8的包，更新RX_Next_Highest=9，由于上一個包為SN=5，此時RX_Next_Reassembly=6，條件滿足，啟動timer，并更新RX_Timer_Trigger=9。

RX_Next_Highest = RX_Next_Reassembly + 1且SN = RX_Next_Reassembly的PDU還沒收全
比如上面例子中收到的包不是SN=8，而是SN=6，且還有SN=6的segment沒有接收完全，更新RX_Next_Highest=7，上一個包為SN=5，RX_Next_Reassembly=6，條件滿足，啟動timer，更新 RX_Timer_Trigger=7。

如果t-Reassembly timer正在運行，滿足以下任何條件時停止并重置timer：

RX_Timer_Trigger <= RX_Next_Reassembly
比如上例RX_Timer_Trigger=7，如果SN=6的segment收全了，重組去頭后送到了PDCP，則更新RX_Next_Reassembly=7，停止并重置timer。

RX_Timer_Trigger落在了reassembly window外且RX_Timer_Trigger ≠ RX_Next_Highest

RX_Next_Highest = RX_Next_Reassembly + 1 且SN = RX_Next_Reassembly的segment已經收全了

一旦t-Reassembly timer超時，接收端也會更新狀態變量RX_Next_Reassembly，把來不及重組的包都丟掉。之后如果滿足了timer的啟動條件就再次啟動timer。

3 AM data transfer

對于AM模式，與UM模式相同的地方是，AM RLC entity必要時也會進行分段和重組，以及加頭和去頭。

與TM和UM不同的第一點是，AM模式是雙向的，所以AM RLC entity并不分為transmitting AM RLC entity和receiving AM RLC entity，而是稱為AM RLC entity的transmitting side和receiving side。但這只是協議上叫法的不同，在一般的討論過程中，仍然可以簡單理解為發送端和接收端。

和TM/UM模式的另一點不同，也是最大的不同是，AM模式是確認模式(Acknowledge Mode)，要保證數據傳輸的正確性，所以發送端要根據接收端的接收情況，進行必要時的重傳。傳輸的data PDU叫AMD PDU，傳輸的control PDU叫STATUS PDU。接收端通過反饋STATUS PDU給發送端，從而告知發送端RLC SDU的接收情況。STATUS PDU的優先級高于AMD PDU，重傳的RLC SDU或RLC SDU segment的優先級高于新傳。其余的一些不同在于Data的傳輸過程。

發送端

AM RLC entity也需要維護一些狀態變量和計時器以及計數器，下面先列舉所有發送端的State variable，Timer和Counter：
a) TX_Next_Ack，該變量指向最小的期望收到ACK的SN。
比如SN=1，2，3的AMD PDU都收到了接收端的反饋，已經正確接收，則此時TX_Next_Ack=4，表示發送端期望收到的下一個ACK SN=4，即使發送端收到了ACK SN=5，但只要沒收到ACK SN=4，TX_Next_Ack就仍然等于4，只有確保SN=4已被正確接收，變量才會更新。
b) TX_Next，該變量指向下一個要構建的AMD PDU的SN。
比如SN=1，2，3的RLC SDU已經構建好并已發送，則TX_Next=4，為下一個構建的AMD PDU的SN。一旦SN=4的RLC SDU被發送，則更新TX_Next=5，該行為不會因為是否收到ACK SN=4而改變。每個AMD PDU都有SN=TX_Next，不論這個AMD PDU包含的是一個完整的RLC SDU還是一個RLC SDU segment。當AMD PDU包含完整RLC SDU或包含RLC SDU的最后一個segment時更新TX_Next=TX_Next+1。

c) POLL_SN，該變量為送到MAC層的所有AMD PDU中的最大SN。

說白了TX_Next就是PDU的序號，而TX_Next_Ack指示正確無誤的傳到哪兒了。發送端根據狀態變量TX_Next_Ack維護一個范圍如下的transmitting window：
TX_Next_Ack <= SN < TX_Next_Ack + AM_Window_Size
SN落在transmitting window外的AMD PDU不會被傳輸。可以看到TX_Next_Ack為發送窗口的下邊界，其依賴AMD PDU的正確無誤的傳輸而被推動，其中AM_Window_Size是窗口大小，為一個常數，在12 bit SN的情況下為2048，18 bit SN時為131072。
當發送端收到某個RLC SDU的反饋時，會向PDCP指示該RLC SDU已被正確接收，并設TX_Next_Ack為下一個希望收到Ack的SN，即這個范圍TX_Next_Ack <= SN <= TX_Next內的還沒有收到Ack的最小SN。

接收端

接收端維護下列State variable，Timer和Counter：
a) RX_Next，該變量指向已經正確收到的SN+1，即接收端期望收到的下一個最小的SN，比如已經收到了SN=1，2，3，則RX_Next=4，即使已經收到了SN=5，但只要沒收到SN=4，RX_Next就仍然等于4。
b) RX_Next_Status_Trigger，該變量指向觸發t-Reassembly的SN+1。
c) RX_Highest_Status，該變量指示的是在構建STATUS PDU時可以通過ACK_SN指示的最高可能的SN。
d) RX_Next_Highest，該變量指向所有已經收到的RLC SDU中的最大SN+1。

接收端會根據狀態變量RX_Next維護一個receiving window，下式即為receiving window范圍：
RX_Next <= SN < RX_Next + AM_Window_Size
我們可以看到和發送窗口類似，RX_Next為接收窗口的下邊界，即通過SN的正確接收來“PUSH”接收窗口的下邊界。這里和UM模式當中的reassembly window有所不同，reassembly window是依靠接收到的SN來拉動窗口的上邊界。

當收到一個AMD PDU時，AM RLC entity會視情況將其丟掉(discard)或放入reception buffer：如果SN不在接收窗口內或是一個之前收到過的重復的SN，則discard；其余情況下的包含RLC SDU segment的AMD PDU，則放入reception buffer中。

比如上面例子，已正確接收SN=0，1，2和4，RX_Next=3，window size假設為4，則receiving window范圍為[3, 7)，所以如果收到SN＜3的或者SN≥7的，discard；如果再次收到SN=4，discard；如果收到SN=3，5或6的包含RLC SDU segment的AMD PDU，則將其放入reception buffer中。

對于放入reception buffer的AMD PDU, AM RLC entity執行下列操作：

更新RX_Next_Highest (如果需要的話)；

檢查放入buffer的該SN對應的RLC SDU是否收全，如果收全了就重組、去頭，并立馬送到PDCP；

更新狀態變量RX_Highest_Status和(或)RX_Next (如果需要的話)，更新后的值為大于原來值的下一個最小的、暫未收全的SN。

比如上例中，如果收到的是SN=3且收全了，則更新RX_Next=5；

如果收到的是SN=5且收全了，則更新RX_Highest_Status=6。

AM模式中也涉及到了計時器t-Reassembly。只是啟/停條件和UM模式比起來稍有不同。
啟動條件：
a) RX_Next_Highest > RX_Next +1
b) RX_Next_Highest = RX_Next + 1且SN = RX_Next的RLC SDU還沒有收全
也就是timer的啟動只可能是因為新到了AMD PDU，導致了RX_Next_Highest的更新，從而滿足了啟動條件。
停止條件：
a) RX_Next_Status_Trigger = RX_Next
b) RX_Next_Status_Trigger = RX_Next + 1且SN = RX_Next的RLC SDU收全了
c) RX_Next_Status_Trigger掉出receiving window外且RX_Next_Status_Trigger ≠ RX_Next + AM_Window_Size
前兩個條件很好理解，就是數據包的正確接收導致了RX_Next的更新，從而滿足了停止條件，但第三個條件我很費解，為什么會出現條件中所述的情況？歡迎大家舉例子來討論。
當t-Reassembly超時：
即認為沒必要繼續等下去，更新RX_Highest_Status為滿足>= RX_Next_Status_Trigger的還沒收全的最小SN。因為在timer運行期間，RX_Next沒有被更新到可以滿足timer停止的條件，且此時認為接收失敗，所以RX_Next會被卡住，此時，更新后的RX_Highest_Status就會替代RX_Next，來判斷timer是否需要再次啟動，否則用RX_Next來判斷的話，必然會滿足timer的啟動條件。所以timer超時后的啟動條件為：
a) RX_Next_Highest> RX_Highest_Status +1
b) RX_Next_Highest = RX_Highest_Status + 1且SN = RX_Highest_Status的RLC SDU還沒有收全

三 ARQ procedures

ARQ(Automatic Repeat request)只針對AM模式，因為上面也提到了，只有AM模式下要保證數據的正確傳輸。

這里還是先列舉ARQ過程中涉及到的Counter和Timer：

Counter：
a) PDU_WITHOUT_POLL，最近一次輪詢前的新傳AMD PDU的數量，其初始值為0；
b) BYTE_WITHOUT_POLL，最近一次輪詢前的新傳AMD PDU的byte數，其初始值為0；
c) RETX_COUNT，重傳計數器，記錄著每個RLC SDU或RLC SDU segment的重傳次數，每個RLC SDU都對應著一個RETX_COUNT；

Timer：
a) t-PollRetransmit，發送側發送Polling后啟動，收到STATUS PDU后停止。
b) t-StatusProhibit，接收側發送STATUS PDU后啟動。

1 重傳(Retransmission)

根據前面的描述，我們知道當接收側沒有成功接收的時候，會發送一個negative acknowledgement給發送側。發送側通過STATUS PDU收到negative acknowledgement后，就會對接收失敗的包(RLC SDU or RLC SDU segment)進行重傳。這里重傳有個前提，就是NACK的SN要在下面范圍內：
TX_Next_Ack <= SN < = the highest SN
因為TX_Next_Ack指向下一個期望收到ACK的SN，換句話說就是，TX_Next_Ack前面的所有SN都已經收到了Ack，也就是接收側都已經成功接收了；the highest SN表示發送側目前為止發出去的最大的SN，接收側自然不可能NACK一個發送側還從來沒有發送過的包。

對于第一次重傳的RLC SDU或RLC SDU segment，設RETX_COUNT為0，不是第一次重傳，則RETX_COUNT+1，當RETX_COUNT = maxRetxThreshold，即重傳次數達到規定的最大門限時，向上匯報達到最大重傳次數。

我們知道在構建AMD PDU時，包的大小(total size of AMD PDU)要符合MAC層的指示，這個值并不是一直不變的，所以在重傳RLC SDU或RLC SDU segment時，如有必要的話，需要重新進行分段或再分段，也就是說一個segment也可以被分成更小的segment。然后基于RLC SDU或RLC SDU segment來構建新的AMD PDU，設置P域，送到MAC層進行傳輸。

2 輪詢(Polling)

發送方通過Polling，觸發接收方的狀態報告(STATUS reporting)。一旦滿足某個或某些條件，發送側就會Polling。

對于每次新傳，發送端計數器PDU_WITHOUT_POLL+1，BYTE_WITHOUT_POLL+新傳的Byte數，一旦計數器達到門限，滿足以下兩個條件之一時，發送側就會Polling：

• PDU_WITHOUT_POLL >= pollPDU
• BYTE_WITHOUT_POLL >= pollByte

當buffer滿足以下條件之一時，發送側也會Polling：

• transmission buffer和retransmission buffer都為空(不包括已經發送正在等待反饋的RLC SDU或RLC SDU segment)；
• 沒有新的RLC SDU要傳輸；

注意，如果上層還有數據要傳輸的話，那么上述第一個條件，buffer為空不應該導致不必要的輪詢。

Polling其實也是發一個AMD PDU，只不過AMD PDU中P域置1，所以發送側如果要Polling，同樣需要等待transmission opportunity，同時：

• P = 1;
• PDU_WITHOUT_POLL = 0；
• BYTE_WITHOUT_POLL = 0。
• POLL_SN = highest SN；
• 啟動或重啟計時器t-PollRetransmit。

當發送側收到了接收側發來的SN=POLL_SN的RLC SDU的STATUS report之后，不論包含的是Ack還是Nack，t-PollRetransmit都會停止并重置。一旦t-PollRetransmit超時，如果滿足上述發送Polling的條件時，傳輸側會將highest SN對應的RLC SDU以及所有沒有收到ACK的RLC SDU重傳。

3 狀態報告(Status reporting)

通過前面的描述，我們知道發送側可以通過Polling，來觸發接收側發送狀態報告，接收端發送STATUS PDU來報告RLC SDU或RLC SDU segment的接收情況：收到了? positive acknowledgement (ACK)，或沒收到 ? negative acknowledgement (NAck)。

STATUS reporting的觸發包括：
1) Polling，也可以理解為被動觸發：
上面也提到了，Polling就是用于觸發STATUS reporting的。接收側如果收到Polling，且Polling的這個AMD PDU被discard了；或該AMD PDU的SN滿足SN < RX_Highest_Status 或 SN >= RX_Next + AM_Window_Size時，則觸發STATUS report。否則暫時不觸發，一直到SN滿足條件。
2) Reception failure，也可以理解為主動觸發：
當接收端檢測到接收失敗，即當t-Reassembly超時時，也會觸發STATUS report。

STATUS reporting一旦觸發，接收側還要考慮計時器t-StatusProhibit的狀態，來決定什么時候發送STATUS PDU，即如果t-StatusProhibit沒在運行，則在MAC層指示的最近一個transmission opportunity發送STATUS PDU (STATUS PDU的優先級高于AMD PDU)；如果t-StatusProhibit正在運行，則需要等t-StatusProhibit到期后的最近一個transmission opportunity傳輸STATUS PDU。一旦發送了一個STATUS PDU，則啟動t-StatusProhibit。這樣就避免了頻繁的上報。

在構建一個STATUS PDU的時候，首先針對SN在范圍RX_Next <= SN < RX_Highest_Status內，且沒有完整接收的RLC SDU，按照SN升序，且滿足最終形成的STATUS PDU大小不超過限制的要求，構建STATUS PDU。不完整接收或者說接收失敗的情況，又細分為下面幾種。

對于沒收到任何一個segment的RLC SDU，構建STATUS PDU時，包含的是該RLC SDU的NACK_SN；

對于沒收到一些連續segment的一個不完整接收的RLC SDU，構建STATUS PDU時，包含的是該RLC SDU的NACK_SN，以及Sostart和Soend；

對于一些連續的沒收到的RLC SDU，構建STATUS PDU時，包含的是一系列的NACK_SN和NACK range，如果需要的話，還要包含一對SOstart和SOend。

而ACK_SN設置為下一個沒收到的RLC SDU的SN。

總結

以上是生活随笔為你收集整理的5G NR RLC：Data Transfer ARQ的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。