5G NR - RLC协议阅读笔记 - Overview

本文链接：https://blog.csdn.net/travel_life/article/details/123867117

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.